idnits 2.17.1 draft-raghu-atomic-certificates-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 409 has weird spacing: '...hey can co-ex...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '0' on line 298 looks like a reference -- Missing reference section? '3' on line 305 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Narayan Raghu 2 IBM Global Services India ltd. 3 Expires in 6 months Sept. 1998 5 ATOMIC CERTIFICATES 6 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), 25 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), 26 or ftp.isi.edu (US West Coast). 28 ABSTRACT 30 The existing PKI has a few inherent limitations like: 32 1. It is implicitly assumed that the two trading parties have ONE 33 mutually trusted third party that can attest ALL of each 34 party's attributes. It provides no mechanism to separate out the 35 fields in a certificate for attestation by different Certification 36 Authorities. 38 2. This standard in no way gives the flexibility to expose only 39 certain fields of a certificate to the other party. 41 This memo proposes a model which, while working well within the 42 X.509v3 framework, overcomes these limitations by 43 breaking up a certificate into pre-signed "unit attestations" 44 referred to as "Atomic Certificates" and packaging them in the 45 X.509v3 format only at the time of sending the certificate to the 46 other party. 48 1. INTRODUCTION 50 The X.509 certificates and the PKI as described in RFC 1422 are 51 aimed at IDENTIFYING an entity, rather than ATTESTING TO AN ATTRIBUTE 52 OF an entity. This view of the PKI was taken, since RFC 1422 relies 53 heavily on the "Distinguished Name" concept, as defined in the 54 directory system (X.500). For most parts of on-line 55 commerce however, what is really needed is an attested attribute of an 56 entity quite often not even leading to the complete "identification" 57 of the entity as we know it. 59 However, moving away from the X.509 standard would mean huge effort 60 in terms of re-coding large parts of existing software, and would 61 certainly be unacceptable. 63 This memo describes a system that eliminates the inherent 64 disadvantages of the X.509 certificates and the existing PKI, while at 65 the same time sticking to the standards so that little changes are 66 required in the existing software. 68 1.1 ORGANIZATION OF THIS MEMO 70 This memo starts with identifying the underlying problems in the 71 existing PKI, and goes into the root of those problems. 72 It then defines the various terms to be used in the Memo, in section 73 3. Section 4 explains the concept of Atomic Certificates. 74 Section 5 gives implementation details. The draft closes with section 75 6, listing out some of the advantages of this system, and section 7 76 touching upon compatibility issues. 78 2. LIMITATIONS OF THE EXISTING PKI 80 The inherent limitations of the existing PKI are : 82 1. It is implicitly assumed that the two trading parties have ONE 83 mutually trusted third party that can attest ALL of each 84 party's attributes. It provides no mechanism to separate out the 85 fields in a certificate for attestation by different Certification 86 Authorities. It does NOT acknowledge the fact that TRUST is always 87 WITH RESPECT TO something. 88 In short, there is no means to associate a CA with an attribute, and 89 designate that CA as the Root ONLY for THAT attribute. 91 2. This standard in no way gives the flexibility to expose only 92 certain fields of a certificate to the other party. 94 3. Going by the existing setup encourages the client to 95 maintain a disproportionately large number of certificates, 96 and considering that certain implementations force the use of a 97 new key pair for each new certificate, the client is forced to 98 maintain multiple key-pairs in addition to multiple certificates. 100 4. This standard almost implicitly imposes the usage of a sort of 101 globally managed system in X.500 directories for storage of 102 certificates. 104 2.1 Root Cause of these limitations: A question of Perspective 106 The current view of a certificate is that it is primarily an 107 identifying document which can also be used to attest to a few 108 attributes of the entity if so desired. 110 - Since it's all about identification, no methods were built in to get 111 different CAs to attest to different attributes, since Attributes 112 are, really work-arounds to make Attribute-Assertions to an already 113 existing concept of identification. This leads to the first problem. 115 - Certificates are about Identification. Internet users require a 116 degree of Anonymity. But certificates are to be Published. 117 This is really a paradox, since the requirement of Anonymity clashes 118 with the requirement for identification imposed by certificates. 119 This leads directly to the second problem listed. 121 The Certification management described in RFC 1422 relies heavily on 122 the Directory System, which really forces identification of the 123 entity. The introduction of v3 extensions, and options to include only 124 certain RDNs and exclude the others are really a desperate attempt to 125 solve the problems that wouldn't have been there in the first place if 126 the PKI had been designed around ATTRIBUTE-ASSERTIONS rather than 127 IDENTIFICATION. 129 This Memo sees Certificates as a collection of Attribute-Assertions, 130 which may or may not aid in identifying the entity that has been 131 certified. 133 This view is really more general, since the "Distinguished Name" is 134 also an attribute of the entity, along with other attributes it might 135 have. So, in that one sense, the PKI as we know today is in effect 136 a special case of the more general case of Atomic Certificates. 138 3. DEFINITION OF TERMS 140 Certificate Holder - An entity which applies for and gets an 141 Atomic Certificate from a Certification Authority 143 Certificate Verifier - An entity that needs to know, with certainty, 144 the Attribute-Values of another entity. 146 Attribute - Information of a particular type. 148 Certification Authority (CA) - An authority trusted by one or more 149 Certificate Verifiers to attest to the Value of a particular attribute 150 of a Certificate Holder. 152 Atomic Certificate - The public key of a Certificate Holder, together 153 with one attribute-value pair rendered unforgeable by encipherment 154 with the private key of the Certification Authority which issued it. 156 Certificate - a collection of (one or more) Atomic Certificates. 158 4. ATOMIC CERTIFICATES 160 This concept proposes to break up the Certificate into chunks of 161 Unit Attestations, and then put them together whenever required, in 162 any combination required. These Unit Attestations are referred to here 163 as "Atomic Certificates", since they cannot be broken down further. 164 Each attestation can be made by a different Certification Authority, 165 as required by the Certificate Verifier. The Certificate Holder can 166 have chunks of unit attestations on his client machine, which he can 167 mix-n-match before sending to the Certificate Verifier. 169 On the Certificate Holder's machine, this is what the scenario would 170 look like: 172 PubKey1 -- "ColorOfHair=Black" -- attests CA1 173 PubKey1 -- "emailID=r1naray@in.ibm.com" -- attests CA2 174 PubKey1 -- "CityOfResidence=Bangalore" -- attests CA3 175 PubKey1 -- "Employer=IBM" -- attests CA4 177 Pubkey2 -- "ShoeSize=9" -- attests CA5 178 pubkey2 -- "DateOfBirth=31101974" -- attests CA6 180 The Certificate Holder can use the first four certificates in any 181 combination, but will not be able to use them alongside the last 182 two, for implementation reasons. The Certificate Holder can mix and 183 match the first four, and also add more attestations to the PubKey1, 184 in order to increase the number of combinations that can be made. This 185 in effect encourages having a single key-pair but multiple 186 attestations associated with a person. 188 5. IMPLEMENTATION OF ATOMIC CERTIFICATES 190 5.1 High level description 192 The Atomic Certificate can be realized by constructing an 193 X.509v3 certificate with the "Subject Name" field blank and adding 194 exactly one extension, with criticality bit set to TRUE. 196 All other aspects of the X.509v3 certificate including the CA Name 197 can remain as it is. Chaining can be implemented if required. 199 These Atomic Certificates can be put into a "Packaging Certificate". 200 The Packaging Certificate is essentially a SELF SIGNED X.509v3 201 Certificate that contains NO CA Name OR Subject Name and that 202 contains all the Atomic Certificates as v3 extensions. Since the 203 Packaging Certificate is self signed, the Certificate Holder can 204 prepare it just before sending it to the Certificate Verifier, 205 depending upon which attributes the Certificate Verifier requires, 206 and which root CAs he trusts. 208 The verifier can verify the signature on the Packaging Certificate, 209 and then attempt to verify each of the Atomic Certificates 210 by traversing up to each of their trusted roots separately. 211 If all of them are OK, the Verifier can then proceed with the 212 transaction. 214 Note that the negotiation as to which atomic certificates are needed 215 by the verifier is the responsibility of the hand-shaking part of the 216 protocol that uses these certificates, and hence is outside the scope 217 of this memo. 219 PACKAGING Certificate 220 (X.509v3 self signed certificate) 221 _______________________________________ 222 | _____________________________ | 223 | | | | 224 | | Cert Num, Date, etc. | | 225 | |_____________________________| | 226 | | 227 | v3 Extensions: | 228 | _____________________________ | 229 | | | | 230 | | AtomicCert1 (X.509v3) | | 231 | | AtomicCert2 (X.509v3) | | 232 | | AtomicCert3 (X.509v3) | | 233 | | AtomicCert4 (X.509v3) | | 234 | |_____________________________| | 235 | | 236 |_______________________________________| 238 5.2 ASN.1 formats 240 ASN.1 Structure of Atomic Certificates and the Packaging Certificate 241 Attention is drawn to the differences between Atomic Certificates and 242 normal X.509v3 certificates by a "--note". 244 IMPORTS 246 -- Directory Authentication Framework (X.509) 247 Certificate, AlgorithmIdentifier, GeneralizedTime, Name 248 FROM AuthenticationFramework { joint-iso-itu-t ds(5) 249 module(1) authenticationFramework(7) 3 } 251 AtomicCertificate ::= SEQUENCE{ 252 tbsCertificate TBSAtomicCertificate, 253 signatureAlgorithm AlgorithmIdentifier, 254 signature BIT STRING } 256 TBSAtomicCertificate ::= SEQUENCE { 257 version [0] EXPLICIT Version3 -- note 258 serialNumber CertificateSerialNumber, 259 signature AlgorithmIdentifier, 260 issuer Name, 261 validity Validity, 262 subject NoName, -- note 263 subjectPublicKeyInfo SubjectPublicKeyInfo, 264 extension [3] EXPLICIT Extensions -- note 265 } 267 Version3 ::= INTEGER {2} -- note 269 CertificateSerialNumber ::= INTEGER 271 Validity ::= SEQUENCE { 272 NotBeforeTime Time 273 NotAfterTime Time } 275 Time ::= CHOICE { 276 utcTime UTCTime, 277 generalTime GeneralizedTime } 279 NoName ::=SEQUENCE{} 281 subjectPublicKeyInfo ::= SEQUENCE{ 282 algorithm AlgorithmIdentifier 283 subjectPublicKey BitString } 285 Extensions ::= SEQUENCE SIZE(1) OF EXTENSION -- note 287 Extension ::= SEQUENCE { 288 extnID OBJECT IDENTIFIER, 289 critical BOOLEAN TRUE -- note 290 extnValue OCTET STRING } 292 PackagingCertificate ::= SEQUENCE{ 293 tbsCertsPackage TBSCertsPackage, 294 signatureAlgorithm AlgorithmIdentifier, 295 signature BIT STRING } 297 TBSCertsPackage ::= SEQUENCE { 298 version [0] EXPLICIT Version -- note 299 serialNumber CertificateSerialNumber, 300 signature AlgorithmIdentifier, 301 issuer NoName, 302 validity Validity, 303 subject NoName, -- note 304 subjectPublicKeyInfo SubjectPublicKeyInfo, 305 extension [3] EXPLICIT Package -- note 306 } 308 Package ::= SEQUENCE{ 309 number NumberExtension 310 SIZE (1..MAX) OF AttributeExtension 311 SIZE (1..MAX) OF ACertExtension 312 } 314 NumberExtension ::= SEQUENCE{ 315 extnID NumberOfAttributesCertified, 316 critical IsCritical, 317 extnValue OCTET STRING } -- integer value 319 NumberOfAttributesCertified ::= OID 321 AttributeExtension ::= SEQUENCE{ 322 extnID UnitAttribute, 323 critical IsCritical, 324 extnValue OCTET STRING } -- Attribute Name 326 UnitAttribute ::= OID 328 ACertExtension ::= SEQUENCE{ 329 extnID AtomicCertificate, 330 critical IsCritical, 331 extnValue OCTET STRING } -- The Atomic Certificate 333 AtomicCertificate ::= OID 335 IsCritical ::= BOOLEAN (TRUE) 337 6. ADVANTAGES OF ATOMIC CERTIFICATES 339 6.1 Only the relevant attestations are exchanged, thus reducing the 340 transmission overhead. In the existing setup, a large record 341 consisting of both relevant and irrelevant information is retrieved 342 and transmitted. Further Atomic Certificates would keep information on 343 a need-to-know basis. 345 6.2 The applications are more scaleable on the client side - one can 346 easily add and delete Atomic Certificates to one's collection 347 at the client end, and send any combination of them as necessary to 348 the other party. This by default permits the client to "hide" 349 certain fields of the certificate, in the sense that the client can 350 simply omit to send the information over. Also, this system 351 eliminates the need to manage multiple key-pairs. 353 6.3 The applications are more scaleable on the Server side - if the 354 server's policy changes, and a new attestation is required, or an 355 an existing attestation is to be dropped, the clients do not need to 356 be issued new certificates. Just the newly required attestation 357 can be made as an atomic certificate, and be integrated with the 358 system. 360 6.4 Servers can be configured to trust different CAs for different 361 Attributes - making trust attribute specific. 363 6.5 In several cases, more than one attribute about a person might be 364 required to be attested, and the same Certification Authority might 365 not be in a position to certify both these attributes. In such cases, 366 normal X.509v3 certificates fail miserably, and Packaged Atomic 367 Certificates are the only way out. 369 6.6 The concept of Atomic Certificates drastically reduce the number 370 of Certificates that need to be issued and maintained. If an entity 371 has "n" attributes that need to be attested, and if information is to 372 be kept on a need-to-know basis, the entity has to store one 373 certificate containing each of the possible combinations of these 374 attributes. 376 This number would be : 377 __ 378 num_of_certs = \ { n!/(n-r)! r!} 379 /_ 380 r=1 to n 382 = { n!/(1)! (n-1)!} + { n!/(2)! (n-2)!} + { n!/(3)! (n-3)!} 383 ..... .. { n!/(n-1)! 1!} 385 In case of Atomic Certificates, the number would be "n" (plus, 386 ofcourse the self-signed packaging certificate that is generated 387 on the fly, and needn't be stored) 389 For a simple case of n = 3, 390 The number of Certificates that need to be issued and maintained 391 with the existing system = 7, 392 and the number with Atomic Certificates = 3. 394 6.7 Related chunks of information can be stored in databases 395 registered with each other. This could help the growth of a setup 396 akin to the DNS. The databases could query each other and cache each 397 other's information to give the client the required information in the 398 most efficient manner. For instance, all the servers maintaining 399 attestations of "emailID" could query each other to get the 400 information to the client that queries any one of these servers. 401 Similar setup could be maintained for other "domains". 402 Given the rate at which the net is growing, it is not too difficult to 403 see that distributed systems like the DNS are proving to be better 404 bets than single, centralized servers. 406 7 COMPATIBILITY ISSUES 408 Since Atomic Certificates are mearly a different 409 implementation of the same standard, they can co-exist with the 410 Directory Certificates, and needn't replace them in toto. 411 Software that work with X.509 Certificate can be modified to use 412 Atomic Certificates along with the Directory Certificates. 414 Hence, implementing this will cause no disruption to the current 415 systems, but will open up several other possibilities that could 416 not have been possible with just the Directory Certificates. Further, 417 the crucial overlap time can be provided, when software's need to 418 implement both the old and the new standard for the sake of 419 compatibility. 421 8. Security Considerations 422 The entire document is about security 424 9. Author's Address: 426 Narayan Raghu 427 IBM Global Services India ltd. 428 3rd Floor, Golden Enclave 429 Airport Road, Bangalore 430 India 560 017 432 Email : r1naray@in.ibm.com