Internet Draft Narayan Raghu IBM Global Services India ltd. Expires in 6 months Sept. 1998 ATOMIC CERTIFICATES Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). ABSTRACT The existing PKI has a few inherent limitations like: 1. It is implicitly assumed that the two trading parties have ONE mutually trusted third party that can attest ALL of each party's attributes. It provides no mechanism to separate out the fields in a certificate for attestation by different Certification Authorities. 2. This standard in no way gives the flexibility to expose only certain fields of a certificate to the other party. Narayan Raghu [Page 01] INTERNET-DRAFT Atomic Certificates Sep 1998 This memo proposes a model which, while working well within the X.509v3 framework, overcomes these limitations by breaking up a certificate into pre-signed "unit attestations" referred to as "Atomic Certificates" and packaging them in the X.509v3 format only at the time of sending the certificate to the other party. 1. INTRODUCTION The X.509 certificates and the PKI as described in RFC 1422 are aimed at IDENTIFYING an entity, rather than ATTESTING TO AN ATTRIBUTE OF an entity. This view of the PKI was taken, since RFC 1422 relies heavily on the "Distinguished Name" concept, as defined in the directory system (X.500). For most parts of on-line commerce however, what is really needed is an attested attribute of an entity quite often not even leading to the complete "identification" of the entity as we know it. However, moving away from the X.509 standard would mean huge effort in terms of re-coding large parts of existing software, and would certainly be unacceptable. This memo describes a system that eliminates the inherent disadvantages of the X.509 certificates and the existing PKI, while at the same time sticking to the standards so that little changes are required in the existing software. 1.1 ORGANIZATION OF THIS MEMO This memo starts with identifying the underlying problems in the existing PKI, and goes into the root of those problems. It then defines the various terms to be used in the Memo, in section 3. Section 4 explains the concept of Atomic Certificates. Section 5 gives implementation details. The draft closes with section 6, listing out some of the advantages of this system, and section 7 touching upon compatibility issues. 2. LIMITATIONS OF THE EXISTING PKI The inherent limitations of the existing PKI are : 1. It is implicitly assumed that the two trading parties have ONE mutually trusted third party that can attest ALL of each party's attributes. It provides no mechanism to separate out the fields in a certificate for attestation by different Certification Authorities. It does NOT acknowledge the fact that TRUST is always Narayan Raghu [Page 02] INTERNET-DRAFT Atomic Certificates Sep 1998 WITH RESPECT TO something. In short, there is no means to associate a CA with an attribute, and designate that CA as the Root ONLY for THAT attribute. 2. This standard in no way gives the flexibility to expose only certain fields of a certificate to the other party. 3. Going by the existing setup encourages the client to maintain a disproportionately large number of certificates, and considering that certain implementations force the use of a new key pair for each new certificate, the client is forced to maintain multiple key-pairs in addition to multiple certificates. 4. This standard almost implicitly imposes the usage of a sort of globally managed system in X.500 directories for storage of certificates. 2.1 Root Cause of these limitations: A question of Perspective The current view of a certificate is that it is primarily an identifying document which can also be used to attest to a few attributes of the entity if so desired. - Since it's all about identification, no methods were built in to get different CAs to attest to different attributes, since Attributes are, really work-arounds to make Attribute-Assertions to an already existing concept of identification. This leads to the first problem. - Certificates are about Identification. Internet users require a degree of Anonymity. But certificates are to be Published. This is really a paradox, since the requirement of Anonymity clashes with the requirement for identification imposed by certificates. This leads directly to the second problem listed. The Certification management described in RFC 1422 relies heavily on the Directory System, which really forces identification of the entity. The introduction of v3 extensions, and options to include only certain RDNs and exclude the others are really a desperate attempt to solve the problems that wouldn't have been there in the first place if the PKI had been designed around ATTRIBUTE-ASSERTIONS rather than IDENTIFICATION. This Memo sees Certificates as a collection of Attribute-Assertions, which may or may not aid in identifying the entity that has been certified. Narayan Raghu [Page 03] INTERNET-DRAFT Atomic Certificates Sep 1998 This view is really more general, since the "Distinguished Name" is also an attribute of the entity, along with other attributes it might have. So, in that one sense, the PKI as we know today is in effect a special case of the more general case of Atomic Certificates. 3. DEFINITION OF TERMS Certificate Holder - An entity which applies for and gets an Atomic Certificate from a Certification Authority Certificate Verifier - An entity that needs to know, with certainty, the Attribute-Values of another entity. Attribute - Information of a particular type. Certification Authority (CA) - An authority trusted by one or more Certificate Verifiers to attest to the Value of a particular attribute of a Certificate Holder. Atomic Certificate - The public key of a Certificate Holder, together with one attribute-value pair rendered unforgeable by encipherment with the private key of the Certification Authority which issued it. Certificate - a collection of (one or more) Atomic Certificates. 4. ATOMIC CERTIFICATES This concept proposes to break up the Certificate into chunks of Unit Attestations, and then put them together whenever required, in any combination required. These Unit Attestations are referred to here as "Atomic Certificates", since they cannot be broken down further. Each attestation can be made by a different Certification Authority, as required by the Certificate Verifier. The Certificate Holder can have chunks of unit attestations on his client machine, which he can mix-n-match before sending to the Certificate Verifier. On the Certificate Holder's machine, this is what the scenario would look like: PubKey1 -- "ColorOfHair=Black" -- attests CA1 PubKey1 -- "emailID=r1naray@in.ibm.com" -- attests CA2 PubKey1 -- "CityOfResidence=Bangalore" -- attests CA3 Narayan Raghu [Page 04] INTERNET-DRAFT Atomic Certificates Sep 1998 PubKey1 -- "Employer=IBM" -- attests CA4 Pubkey2 -- "ShoeSize=9" -- attests CA5 pubkey2 -- "DateOfBirth=31101974" -- attests CA6 The Certificate Holder can use the first four certificates in any combination, but will not be able to use them alongside the last two, for implementation reasons. The Certificate Holder can mix and match the first four, and also add more attestations to the PubKey1, in order to increase the number of combinations that can be made. This in effect encourages having a single key-pair but multiple attestations associated with a person. 5. IMPLEMENTATION OF ATOMIC CERTIFICATES 5.1 High level description The Atomic Certificate can be realized by constructing an X.509v3 certificate with the "Subject Name" field blank and adding exactly one extension, with criticality bit set to TRUE. All other aspects of the X.509v3 certificate including the CA Name can remain as it is. Chaining can be implemented if required. These Atomic Certificates can be put into a "Packaging Certificate". The Packaging Certificate is essentially a SELF SIGNED X.509v3 Certificate that contains NO CA Name OR Subject Name and that contains all the Atomic Certificates as v3 extensions. Since the Packaging Certificate is self signed, the Certificate Holder can prepare it just before sending it to the Certificate Verifier, depending upon which attributes the Certificate Verifier requires, and which root CAs he trusts. The verifier can verify the signature on the Packaging Certificate, and then attempt to verify each of the Atomic Certificates by traversing up to each of their trusted roots separately. If all of them are OK, the Verifier can then proceed with the transaction. Note that the negotiation as to which atomic certificates are needed by the verifier is the responsibility of the hand-shaking part of the protocol that uses these certificates, and hence is outside the scope of this memo. Narayan Raghu [Page 05] INTERNET-DRAFT Atomic Certificates Sep 1998 PACKAGING Certificate (X.509v3 self signed certificate) _______________________________________ | _____________________________ | | | | | | | Cert Num, Date, etc. | | | |_____________________________| | | | | v3 Extensions: | | _____________________________ | | | | | | | AtomicCert1 (X.509v3) | | | | AtomicCert2 (X.509v3) | | | | AtomicCert3 (X.509v3) | | | | AtomicCert4 (X.509v3) | | | |_____________________________| | | | |_______________________________________| 5.2 ASN.1 formats ASN.1 Structure of Atomic Certificates and the Packaging Certificate Attention is drawn to the differences between Atomic Certificates and normal X.509v3 certificates by a "--note". IMPORTS -- Directory Authentication Framework (X.509) Certificate, AlgorithmIdentifier, GeneralizedTime, Name FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 } AtomicCertificate ::= SEQUENCE{ tbsCertificate TBSAtomicCertificate, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING } TBSAtomicCertificate ::= SEQUENCE { version [0] EXPLICIT Version3 -- note serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, Narayan Raghu [Page 06] INTERNET-DRAFT Atomic Certificates Sep 1998 validity Validity, subject NoName, -- note subjectPublicKeyInfo SubjectPublicKeyInfo, extension [3] EXPLICIT Extensions -- note } Version3 ::= INTEGER {2} -- note CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { NotBeforeTime Time NotAfterTime Time } Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } NoName ::=SEQUENCE{} subjectPublicKeyInfo ::= SEQUENCE{ algorithm AlgorithmIdentifier subjectPublicKey BitString } Extensions ::= SEQUENCE SIZE(1) OF EXTENSION -- note Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN TRUE -- note extnValue OCTET STRING } PackagingCertificate ::= SEQUENCE{ tbsCertsPackage TBSCertsPackage, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING } TBSCertsPackage ::= SEQUENCE { version [0] EXPLICIT Version -- note serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer NoName, validity Validity, subject NoName, -- note subjectPublicKeyInfo SubjectPublicKeyInfo, Narayan Raghu [Page 07] INTERNET-DRAFT Atomic Certificates Sep 1998 extension [3] EXPLICIT Package -- note } Package ::= SEQUENCE{ number NumberExtension SIZE (1..MAX) OF AttributeExtension SIZE (1..MAX) OF ACertExtension } NumberExtension ::= SEQUENCE{ extnID NumberOfAttributesCertified, critical IsCritical, extnValue OCTET STRING } -- integer value NumberOfAttributesCertified ::= OID AttributeExtension ::= SEQUENCE{ extnID UnitAttribute, critical IsCritical, extnValue OCTET STRING } -- Attribute Name UnitAttribute ::= OID ACertExtension ::= SEQUENCE{ extnID AtomicCertificate, critical IsCritical, extnValue OCTET STRING } -- The Atomic Certificate AtomicCertificate ::= OID IsCritical ::= BOOLEAN (TRUE) 6. ADVANTAGES OF ATOMIC CERTIFICATES 6.1 Only the relevant attestations are exchanged, thus reducing the transmission overhead. In the existing setup, a large record consisting of both relevant and irrelevant information is retrieved and transmitted. Further Atomic Certificates would keep information on a need-to-know basis. 6.2 The applications are more scaleable on the client side - one can easily add and delete Atomic Certificates to one's collection at the client end, and send any combination of them as necessary to Narayan Raghu [Page 08] INTERNET-DRAFT Atomic Certificates Sep 1998 the other party. This by default permits the client to "hide" certain fields of the certificate, in the sense that the client can simply omit to send the information over. Also, this system eliminates the need to manage multiple key-pairs. 6.3 The applications are more scaleable on the Server side - if the server's policy changes, and a new attestation is required, or an an existing attestation is to be dropped, the clients do not need to be issued new certificates. Just the newly required attestation can be made as an atomic certificate, and be integrated with the system. 6.4 Servers can be configured to trust different CAs for different Attributes - making trust attribute specific. 6.5 In several cases, more than one attribute about a person might be required to be attested, and the same Certification Authority might not be in a position to certify both these attributes. In such cases, normal X.509v3 certificates fail miserably, and Packaged Atomic Certificates are the only way out. 6.6 The concept of Atomic Certificates drastically reduce the number of Certificates that need to be issued and maintained. If an entity has "n" attributes that need to be attested, and if information is to be kept on a need-to-know basis, the entity has to store one certificate containing each of the possible combinations of these attributes. This number would be : __ num_of_certs = \ { n!/(n-r)! r!} /_ r=1 to n = { n!/(1)! (n-1)!} + { n!/(2)! (n-2)!} + { n!/(3)! (n-3)!} ..... .. { n!/(n-1)! 1!} In case of Atomic Certificates, the number would be "n" (plus, ofcourse the self-signed packaging certificate that is generated on the fly, and needn't be stored) For a simple case of n = 3, The number of Certificates that need to be issued and maintained with the existing system = 7, and the number with Atomic Certificates = 3. Narayan Raghu [Page 09] INTERNET-DRAFT Atomic Certificates Sep 1998 6.7 Related chunks of information can be stored in databases registered with each other. This could help the growth of a setup akin to the DNS. The databases could query each other and cache each other's information to give the client the required information in the most efficient manner. For instance, all the servers maintaining attestations of "emailID" could query each other to get the information to the client that queries any one of these servers. Similar setup could be maintained for other "domains". Given the rate at which the net is growing, it is not too difficult to see that distributed systems like the DNS are proving to be better bets than single, centralized servers. 7 COMPATIBILITY ISSUES Since Atomic Certificates are mearly a different implementation of the same standard, they can co-exist with the Directory Certificates, and needn't replace them in toto. Software that work with X.509 Certificate can be modified to use Atomic Certificates along with the Directory Certificates. Hence, implementing this will cause no disruption to the current systems, but will open up several other possibilities that could not have been possible with just the Directory Certificates. Further, the crucial overlap time can be provided, when software's need to implement both the old and the new standard for the sake of compatibility. 8. Security Considerations The entire document is about security 9. Author's Address: Narayan Raghu IBM Global Services India ltd. 3rd Floor, Golden Enclave Airport Road, Bangalore India 560 017 Email : r1naray@in.ibm.com Narayan Raghu [Page 10] INTERNET-DRAFT Atomic Certificates Sep 1998