RFC 2692

SPKI Requirements

📅 published September 1999, from ietf

SPKI Requirements 🎀

Okay bestie, let's get into RFC 2692! 💖 It's called SPKI Requirements, written by C. Ellison from Intel, dated September 1999. It's marked Experimental 🧪, and it doesn't obsolete or update any other RFC, so it's a fresh start all on its own ✨.

Status of this Memo ✨

This memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested 💬. Distribution of this memo is unlimited 🌍.

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract 🦋

The IETF Simple Public Key Infrastructure [SPKI] Working Group is tasked with producing a certificate structure and operating procedure to meet the needs of the Internet community for trust management in as easy, simple and extensible a way as possible 🫶.

The SPKI Working Group first made a list of things one might want to do with certificates (attached at the end of this document), and then squished that list of desires into requirements. This document presents that summary of requirements 📋.

Table of Contents 📑

Charter of the SPKI working group................................2
Background.......................................................2
General Requirements.............................................3
Validity and CRLs................................................4
Implementation of Certificates...................................4
List of Certificate Uses.........................................5
Open Questions..................................................11
References......................................................12
Security Considerations.........................................12
Author's Address................................................13
Full Copyright Statement........................................14

Charter of the SPKI working group 📜

Lots of Internet protocols and apps use public key tech for security, and they need a public key infrastructure to manage those public keys 🔐.

The working group's job is to develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are supposed to be simple to understand, implement, and use. For the working group's purposes, the results are known as the Simple Public Key Infrastructure, or SPKI ✨.

SPKI is meant to support security across a wide range of Internet apps, including IPSEC protocols, encrypted electronic mail and WWW documents, payment protocols, and any other application that needs public key certificates and the ability to access them 💌. It's also meant to support a range of trust models 🌈.

Background 🕰️

The word certificate goes back to the MIT bachelor's thesis of Loren M. Kohnfelder [KOHN] 🎓. Kohnfelder was responding to an idea from Diffie and Hellman in their seminal paper [DH] 📄. Diffie and Hellman pointed out that with public key cryptography, you no longer need a secure channel to send secret keys between communicants 🔑. Instead, they suggested you could publish a modified telephone book, with public keys in place of telephone numbers 📖. You'd look up your desired communication partner, find their public key, and open a secure channel to them 🤝.

Kohnfelder took that idea and noted that an online service has the downside of being a performance bottleneck 🐌. To fix that, he proposed digitally signed directory entries, which he called certificates ✍️. Since 1978, the term certificate has often been assumed to mean a binding between a name and a key 🙈.

The SPKI team directly tackled the issue of <name,key> bindings and realized that those certificates are extremely limited for trust management 😬. A keyholder's name is just one attribute of the keyholder, and as you can see in the list of needs in this document, a person's name is rarely of security interest 🙅‍♀️. What a certificate user really needs to know is whether a given keyholder has been granted some specific authorization 🔑✨.

General Requirements 💎

We define the term KEYHOLDER of a public key to refer to the person or other entity that controls the corresponding private key 🗝️.

The main purpose of an SPKI certificate is to authorize some action, give permission, grant a capability, etc. to or for a keyholder 🎟️.

The keyholder is most directly identified by the public key itself. But for convenience or other purposes, some indirection (delayed binding) may be used. That indirection can be a collision-free hash of the public key, or a name that gets resolved into a key later 🧩.

It's up to the author of the code that uses the certificate to define the attributes or authorizations in a certificate. Creating new authorizations should not need any interaction with another person or organization. Instead, it should be under the total control of the author of the code using the certificate 👑.

SPKI certificates might carry information the keyholder doesn't want published, so we assume certificates will be sent directly from the keyholder to the verifier 📬. If the keyholder wants a global repository, like LDAP, the global PGP key server, or the DNS database, that's the keyholder's call, and it's not for the SPKI WG to specify 🌐.

SPKI certificates will carry information that, taken together across all certificates, might add up to a dossier and therefore a privacy violation 🕵️‍♀️. So each SPKI certificate should carry the minimum information needed to get the job done. An SPKI certificate should be like a single key, not a whole key ring, or a single credit card, not a whole wallet 💳. The keyholder should be able to release the least amount of information needed to prove their permission to act 🫧.

It is necessary for at least some certificates to be anonymous 🥷.

Because one use of SPKI certificates is secret balloting and similar applications, an SPKI certificate must be able to assign an attribute to a blinded signature key 🗳️.

A keyholder's name is one of their attributes. There are names the keyholder prefers to go by, and names other keyholders know them by 🏷️. An SPKI certificate must be able to bind a key to those names. The SDSI work of Rivest and Lampson did an especially good job defining and using local name spaces, so if possible, SPKI should support the SDSI name construct 🙌. [Note: SPKI and SDSI have merged.]

Validity and CRLs ⏳

An SPKI certificate, like any other, should be able to carry a validity period: the dates within which it's valid 📅. It may also be necessary to refine validity online. In previous certificate designs, this was often done with a Certificate Revocation List (CRL) 📃.

A minimal CRL contains a list of revoked certificates, each identified uniquely, plus a sequence number and a signature. Its method of transmission is not specified 📡. If a CRL encounters a certificate it lists, it annihilates that certificate 💀. If it encounters a previous CRL, as indicated by sequence number, it annihilates that previous CRL 🗑️.

This is the spicy part: such a CRL leads to non-deterministic program behavior 😱. So we take as a requirement that if SPKI uses CRLs, then the certificate that uses it must explicitly tell the verifier where to find the CRL, the CRL must carry explicit validity dates, and the dates of a sequence of CRLs must not overlap. With this set of requirements, certificate validation behaves deterministically (aside from the question of clock skew) ✅.

A CRL is a negative statement. It's the digital version of the little paper books of bad checks or bad credit cards that were handed to cashiers in the 1970s and before 📚. The retail world has mostly replaced those with positive statements, meaning online validation of a single check, ATM card, or credit card 🏧.

SPKI should support both positive and negative online validations 🙆‍♀️🙅‍♀️.

Any CRL or revalidation instrument must have its own lifetime. A lifetime of 0 isn't possible because of communication delays and clock skews. You can, however, consider an instrument whose lifetime is "one use," which is delivered only as part of a challenge/response protocol 🎯.

Implementation of Certificates 🛠️

The authorization certificates envisioned for SPKI (and needed to meet the demands of the list at the end of this document) should be generated by any keyholder empowered to grant or delegate the authorization in question 🔏. The code to generate certificates should be written by lots of different developers, often solo people working out of garages or dorm rooms 🧑‍💻. That leads to a number of constraints on the structure and encoding of certificates 🧱. SPKI certificates should also be usable in very constrained environments, like smart cards or small embedded systems 🪪. The code to process them and the memory to store them should both be as small as possible 🐜.

An SPKI certificate should be as simple as possible 🍓. There should be a bare minimum of fields needed to get the job done, and an absolute minimum of optional fields. In particular, the structure should be specific enough that the creator of a certificate is limited by the structure definition, not by complaints (or error messages) from the reader 🙃.

An SPKI certificate should be described as simply as possible, relating directly to the kinds of structures a C or PASCAL programmer would normally write 🧑‍🏫.

No library code should be required for packing or parsing SPKI certificates. In particular, ASN.1 is not to be used 🚫.

A certificate should be signed exactly as it is transmitted. There should be no reformatting in the process of checking a certificate's signature (although one might canonicalize white space during certificate input, for example, if the format is text) 📝.

For efficiency, if possible, an SPKI certificate should be encoded in an LR(0) grammar 🚀. That means neither packing nor parsing the structure should require scanning the data. Data should be read into the kind of structure a programmer would want to use without touching the incoming bytes more than once 👀.

For efficiency, if possible, an SPKI certificate should be packed and parsed without any recursion 🔁.

List of Certificate Uses 🎀

okay so this is the brainstorming list the SPKI crew collected on the mailing list, and it is WILD 💅 it's basically everything people wanted certificates for. let's go 🦋

  • I need a certificate to give me permission to write electronic checks. 💸
  • My bank would need a certificate, proving to others that it is a bank capable of cashing electronic checks and permitted to give permission to people to write electronic checks. 🏦
  • My bank would issue a certificate signing the key of a master bank certifier -- perhaps NACHA -- so that I could follow a certificate chain from a key I know (my bank's) to the key of any other bank in the US and, similarly, to any other bank in the world. 🌍
  • I might generate a certificate (a "reputation voucher") for a friend to introduce him to another friend -- in which certificate I could testify to my friend's political opinion (e.g., libertarian cypherpunk) or physical characteristics or anything else of interest. 🫶
  • I might have a certificate giving my security clearance, signed by a governmental issuing authority. 🔐
  • I want a certificate for some software I have downloaded and am considering running on my computer -- to make sure it hasn't changed and that some reputable company or person stands behind it. 🛡️
  • I need certificates to bind names to public keys: 🔑
    • [traditional certificate] binding a key to a name, implying "all the attributes of the real person having this name are transferred to this key by this certificate". This requires unique identification of a person (which is difficult in non-digital space, as it is) and someone trustworthy binding that unique name to the key in question. In this model, a key starts out naked and acquires attributes, permissions and authority from the person bound to it. 🥹
    • [direct certificate] binding a name to a key, implying "I (the person who is able to use the associated private key to make this signature) declare that I go by the name of XXXXXXX." The unique identification of the key is automatic -- from the key itself or a cryptographic hash of the key. The binding is done by the key itself -- in a self-signed certificate. In this model, a key is loaded with attributes, permissions and authority directly by other certificates, not indirectly through some person's name, and this certificate declares only a name or nickname by which the key's owner likes to be addressed. ✨
    • [personal binding] binding a key to a nickname. This kind of certificate is signed by me, signing someone else's key and binding it to a nickname by which I know that person. It is for my use only -- never given out -- and is a signed certificate to prevent tampering with my own private directory of keys. It says nothing about how I certified the binding to my own satisfaction between the key and my friend. 📒
  • I might be doing genealogy and be collecting what amounts to 3x5 cards with facts to be linked together. Some of these links would be from one content to another reference [e.g., indexing and cross-referencing]. Others might be links to the researcher who collected the fact. By rights, the fact should be signed by that researcher. Viewing only the signature on the fact and the link to the researcher, this electronic 3x5 card becomes a certificate. 🌳
  • I want to sign a contract to buy a house. What kind of certificate do I need? 🏠
  • I have found someone on the net and she sounds really nice. Things are leading up to cybersex. How do I make sure she's not really some 80-year-old man in a nursing home? 💀
  • I have met someone on the net and would like a picture of her and her height, weight and other measurements from a trustworthy source. 🙈
  • Can I have a digital marriage license? 💍
  • Can I have a digital divorce decree? 📜
  • ..a digital Voter Registration Card? 🗳️
  • There are a number of cards one carries in a typical wallet which could become certificates attached to a public key: 👛
  • health insurance card 🩺
  • prescription drug card 💊
  • driver's license (for permission to drive) 🚗
  • driver's license (for permission to buy alcohol) 🍾
  • supermarket discount card 🛒
  • supermarket check-cashing card [I know -- anachronism] 🙃
  • Blockbuster Video rental card 📼
  • ATM card 🏧
  • Credit card 💳
  • membership card in the ACLU, NRA, Republican party, Operation Rescue, NARAL, ACM, IEEE, ICAR.... 🎫
  • Red Cross blood donor card 🩸
  • Starbuck's Coffee buy-10-get-1-free card ☕
  • DC Metro fare card 🚇
  • Phone calling card 📞
  • Alumni Association card 🎓
  • REI Membership card 🏕️
  • Car insurance card 🚙
  • claim check for a suitcase 🧳
  • claim check for a pawned radio 📻
  • authorization for followup visits to a doctor, after surgery 🩹
  • Better Business Bureau [BBB] style reputation certificates [testimonies from satisfied customers] ⭐
  • BBB-style certificate that no complaints exist against a business or doctor or dentist, etc. 🦷
  • LDS Temple Recommend 🕊️
  • Stock certificate 📈
  • Stock option 💹
  • Car title 🚘
  • deed to land 🌾
  • proof of ownership of electronic equipment with an ID number 🖥️
  • time card certificate [activating a digital time clock] ⏰
  • proof of degree earned [PhD, LLD, MD, ...] 🎓
  • permission to write digitally signed prescriptions for drugs 💉
  • permission to spend up to $X of a company's money 💰
  • permission to issue nuclear launch codes ☢️
okay this one is giving high stakes and we are NOT here for it 😭
  • I'm a sysadmin, I want to carry a certificate, signed by SAGE, that says I'm good at the things sysadmins are good at. 🧑‍💻
  • I'm that same sysadmin, I want an ephemeral certificate that grants me root access to certain systems for the day, or the week, or... 🧚

Certain applications will want some form of auditing, but the audit identity should be in the domain of the particular application... For instance an "is a system administrator of this host" certificate would probably want to include an audit identity, so you can figure out which of your multiple admins screwed something up. 👀

  • I'm an amateur radio operator. I want a signed certificate that says I'm allowed to engage in amateur radio, issued by the DOC. [I currently have a paper version of one]. This would be useful in enforcing access policies to the amateur spectrum; and in tracking abuse of that same spectrum. Heck! extend this concept to all licensed spectrum users. 📡
  • I'm a purchasing agent for a large corporation. I want to posses a certificate that tells our suppliers that I'm authorized to make purchases up to $15,000. I don't want the suppliers to know my name, lest their sales people bug me too much. I don't want to have to share a single "Megacorp Purchasing Department Certificate" with others doing the same job [the private key would need to be shared--yuck!]. 🙅‍♀️
  • "This signed-key should be considered equivalent to the certifying-key until this certificate expires for the following purposes ..." 🔁 [This is desirable when you wish to reduce the exposure of long-term keys. One way to do this is to use smart cards, but those typically have slow processors and are connected through low-bandwidth links; however, if you only use the smart card at "login" time to certify a short-term key pair, you get high performance and low exposure of the long term key.

I'll note here that this flies in the face of attempts to prevent delegation of certain rights. Maybe we need a "delegation-allowed" bit -- but there's nothing to stop someone who wishes to delegate against the rules from also loaning out their private key.]

  • "I am the current legitimate owner of a particular chunk of Internet address space." [I'd like to see IPSEC eventually become usable, at least for privacy, without need for prior arrangement between sites, but I think there's a need for a "I own this address"/"I own this address range" certificate in order for IPSEC to coexist with existing ip-address-based firewalls.] 🌐
  • "I am the current legitimate owner of a this DNS name or subtree." 🏷️
  • "I am the legitimate receiver of mail sent to this rfc822 email address. [this might need to be signed by a key which itself had been certified by the appropriate "DNS name owner" certificate]." [This is in case I know someone owns a particular e-mail address but I don't know their key.] 📬
  • Encryption keys for E-mail and file encryption 🔒
  • Authentication of people or other entities 🪪
  • Digital signatures (unforgeability) ✍️
  • Timestamping / notary services ⏱️
  • Host authentication 🖧
  • Service authentication 🛎️

Other requirements:

  • Trust model must be a web (people want to choose whom they trust). People must be able to choose whom they trust or consider reliable roots (maybe with varying reliabilities). 🕸️
  • Some applications (e.g., notary services) require highly trusted keys; generation complexity is not an issue here. 🔐
  • Some applications (e.g., host authentication) require extremely light (or no) bureaucracy. Even communication with the central administrator may be a problem. 🌸
  • Especially in lower-end applications (e.g. host authentication) the people generating the keys (e.g., administrators) will change, and you will no longer want them to be able to certify. On the other hand, you will usually also not want all keys they have generated to expire. This may imply a "certification right expiration" certificate requirement, probably to be implemented together with notary services. 🔄
  • Keys will need to be cached locally to avoid long delays fetching frequently used keys. Cf. current name servers. The key infrastructure may in future get used almost as often as the name server. The caching and performance requirements are similar. 🚀
  • Reliable distribution of key revocations and other certificates (e.g., the ceasing of the right to make new certificates). May involve goals like "will have spread everywhere in 24 hours" or something like that. This interacts with caching. 📣

Open Questions ✨

okay so with certs like these, there are still some questions 🥺 and they're mostly about proving the opposite of what a cert is built to do. a certificate's definition or issuing process can't answer these alone, bestie 💅

  • Someone signed a threatening email with MY private key and sent it to president@whitehouse.gov. How do I prove I didn't write and send it? 😭 What kind of certificate feature could even help with that?

This is a non-repudiation problem, so it comes down to private key protection 🔐. users care about it a lot, but the certificate's format, contents, or issuing machinery can't guarantee that a private key stays protected, or prove whether it was stolen or misused. 💀

  • Can certificates help with a title search before buying a house? 🏡

A certificate could carry information in a tamper-proof way, sure ✨. But building the database that records every house title and every lien is a totally separate project that has nothing to do with certificate structure 🙄.

  • Can a certificate prove I'm NOT already married, so I can get a digital marriage license? 💍🙈

you can only find out an absence of attributes if every relevant record is digitized and everyone has an inescapable ID. the first one probably won't happen in our lifetimes, and the second one gets lots of political pushback 😤.

what a certificate can say is a positive attribute, like "not already married" or "not registered as a voter in any other district" 🦋. but that assumes some organization can actually figure out that fact for a given keyholder. how you determine a negative fact isn't part of the certificate definition, so it's not on the cert's plate 🫠.

  • Most certs assume the proper user protects their private key really well, so nobody else can get at their funds. BUT some certs have actual monetary value [permission to prescribe drugs, permission to buy alcohol, ...] 💸. So what stops the holder of such a cert from loaning out their private key? 👀

this is a real potential flaw in any system that handles authorization, and honestly it's an iconic topic to study 🧠. like, what stops a doctor or dentist from selling prescriptions for controlled substances to drug abusers? 😬 hard question, no cap.

References

[DH]   Diffie and Hellman, "New Directions in Cryptography", IEEE
       Transactions on Information Theory IT-22, 6 (Nov. 1976), 644-
       654.

[KOHN] Loren Kohnfelder, "Towards a Practical Public-key
       Cryptosystem", Bachelor's thesis, MIT, May, 1978.

Security Considerations 🚨

Security issues are discussed throughout this memo. 🔥 And I mean throughout, bestie. this is the kind of spec where every single section has security stakes, so please read the whole thing and don't just skim for the scary parts 😭🫶.

Author's Address 🎀

Carl M. Ellison
Intel Corporation
2111 NE 25th Ave   M/S JF3-212
Hillsboro OR 97124-5961 USA

Phone: +1-503-264-2900
Fax:   +1-503-264-6225
EMail: carl.m.ellison@intel.com
       cme@alum.mit.edu
Web:   http://www.pobox.com/~cme

Copyright (C) The Internet Society (1999). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

The legal disclaimer stays exactly as written, so here it is in full:

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. 🧚

📦 where this page comes from