idnits 2.17.1 draft-ietf-pkix-tac-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 171 has weird spacing: '...blinded sign...' == Line 335 has weird spacing: '...les the sig...' == Line 347 has weird spacing: '...a value wit...' == Line 777 has weird spacing: '...ves the use...' == Line 926 has weird spacing: '...one for enc...' == (1 more instance...) -- 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.) -- The document date (May 22, 2009) is 5452 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 1332, but not defined -- Looks like a reference, but probably isn't: 'PROFILE' on line 1096 -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 1225 == Unused Reference: '10' is defined on line 1042, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1050, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1059, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1074, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3852 (ref. '6') (Obsoleted by RFC 5652) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S.Park 2 Internet Draft H.Park 3 Intended status: Experimental Y. Won 4 Expires: November 2009 J. Lee 5 KISA 6 S.Kent 7 BBN Technologies 8 May 22, 2009 10 Traceable Anonymous Certificate 11 draft-ietf-pkix-tac-04.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on November 22, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 Public Key Infrastructure (PKI) provides a powerful means of 49 authenticating individuals, organizations, and computers(e.g., 50 web servers). However, when individuals use certificates to 51 access resources on the public Internet, there are legitimate 52 concerns about personal privacy, and thus there are increasing 53 demands for privacy enhancing techniques on the Internet. 55 In a PKI, an authorized entity such as a certification Authority 56 (CA) or a Registration Authority (RA) may be perceived, from a 57 privacy perspective, as a "big brother," even when a CA issues a 58 certificate containing a Subject name that is a pseudonym. This 59 is because such entities can always map a pseudonym in a 60 certificate they issued to the name of the real user to whom it 61 was issued. This document defines a practical architecture and 62 protocols for offering privacy for a user who requests and uses 63 an X.509 certificate containing a pseudonym, while still retaining 64 the ability to map such a certificate to the real user who 65 requested it. The architecture is compatible with IETF certificate 66 request formats such as PKCS10 [3]and CMC[4]. The architecture 67 separates the authorities involved in issuing a certificate: one 68 for verifying ownership of a private key (Blind Issuer) and the 69 other for validating the contents of a certificate (Anonymity 70 Issuer). The end-entity(EE) certificates issued under this model 71 are called Traceable Anonymous Certificates (TACs). 73 Conventions used in this document 75 In examples, "C:" and "S:" indicate lines sent by the client and 76 server respectively. 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 80 this document are to be interpreted as described in RFC-2119 [1]. 82 Table of Contents 84 1. Introduction..................................................3 85 2. General Overview..............................................5 86 3. Requirements..................................................5 87 4. Traceable Anonymous Certificate Model.........................6 88 5. Issuing a TAC.................................................7 89 5.1. Steps in issuing a TAC...................................9 90 5.2. Mapping a TAC to a User's Real Identity.................16 91 5.3. TAC Request Message Format Profile......................18 92 5.3.1. PKCS10 Profile.....................................18 93 5.3.2. CMC Profile........................................19 94 6. Security Considerations......................................20 95 7. IANA Considerations..........................................23 96 8. Acknowledgments..............................................23 97 9. References...................................................23 98 9.1. Normative References....................................23 99 9.2. Informative References..................................23 100 APPENDIX A: Traceable Anonymous Certificate ASN.1 Modules.......25 101 APPENDIX B: TAC message exchanges over Transport Layer Security.27 102 Author's Addresses..............................................32 104 1. Introduction 106 A Public Key Infrastructure (PKI) typically serves to identify the 107 holder of a private key (to the corresponding public key in a 108 certificate), in a standard fashion. The public key, identity, and 109 related information, are signed by an entity acting as a 110 Certification Authority (CA) as specified in X.509 and as profiled 111 for use in the Internet [2]. During the past decade, PKIs have been 112 widely deployed to support various types of communications and 113 transactions over the Internet. 115 However, with regard to privacy on the Internet, a PKI is generally 116 not supportive of privacy, at least in part because of the 117 following issues: 119 - A certificate typically contains, in the Subject field the 120 true identity of the user to whom it was issued. This identity is 121 disclosed to a relying party (e.g., a web site or the recipient 122 of an SMIME message [20]) whenever the certificate holder presents 123 it in a security protocol that requires a user to present a 124 certificate. In some protocols, e.g., TLS, a user's certificate 125 is sent via an unencrypted channel, prior to establishing a 126 secure communication capability. 128 - A certificate often is published by the CA, for example in a 129 directory system, which may be widely accessible. 131 - An anonymous (end entity) certificate [9] is one that 132 indicates that the holder's true identity is not represented in the 133 subject field. (Such a certificate might more accurately be called 134 pseudonymous since an X.509 certificate must contain an identifier 135 to comply with PKI format standards, and a CA must not issue 136 multiple certificates with the same Subject name to different 137 entities. However, we use the more common term "anonymous" 138 throughout this document to refer to such certificates.) 139 Issuance of anonymous certificates could enhance user privacy. 141 There is however, a need to balance privacy and accountability 142 when issuing anonymous certificates. If a CA/RA is unable to map 143 an anonymous certificate to the real user to whom it was issued, 144 the user might abuse the anonymity afforded by the certificate, 145 because there would be no recourse for relying parties. 147 A CA or RA generally would be able to map an anonymous certificate 148 to the user to whom it was issued, to avoid such problems. To do 149 so the CA/RA would initially identify the user and maintain a 150 database that relates the user's true identity to the pseudonym 151 carried in the certificate's Subject field. 153 In a traditional PKI, there is a nominal separation of functions 154 between a RA and a CA, but in practice these roles are often 155 closely coordinated. Thus either the RA or CA could, in principle, 156 unilaterally map an autonomous certificate to the real user 157 identity. 159 The architecture, syntax, and protocol conventions described in 160 this document allow anonymous certificates to be issued and used 161 in existing PKIs in a way that provides a balance between privacy 162 and a conditional ability to map an anonymous certificate to the 163 individual to whom it was issued. 165 An anonymous certificate (Traceable Anonymous Certificate) in this 166 document is issued by a pair of entities that operate in a split 167 responsibility mode: a Blind Issuer (BI) and an Anonymity Issuer (AI). 168 The conditional traceability offered by this model assumes strong 169 separation between the RA and CA roles, and employs technical means 170 (threshold cryptography and "blinded" signatures), to facilitate that 171 separation. (A blinded signature is one in which the value being 172 signed is not made visible to the signer, via cryptographic 173 means. Additional details are provided later.) 175 The AI has knowledge of the certificate issued to the user, but no 176 knowledge of the user's real identity. The BI knows the user's real 177 identity, but has no knowledge of the certificate issued to that user. 178 Only if the AI and BI collaborate can they map the TAC issued to a 179 user to the real identity of that user. 181 2. General Overview 183 This section defines the notion of a traceable anonymous 184 certificate(briefly TAC or anonymous certificate in this document). 185 It is distinguished from a conventional pseudonymous certificate 186 [8, 9] in that a TAC containing a pseudonym in the Subject 187 field will be conditionally traceable (as defined that it is not 188 trivial to design a system that issues anonymous certificates, 189 consistent with Internet PKI standards, when additional 190 constraints are imposed, as illustrated by the following scenarios. 192 - If a CA issues an anonymous certificate without verifying a 193 true identity, it is untraceable, which provides inadequate 194 recourse if the user to whom the certificate was issued abuses the 195 anonymity it provides. (Even without the ability to trace an 196 anonymous certificate to the corresponding user, the certificate 197 can always be revoked, but this may not be a sufficient response 198 to abuse.) 200 - If a CA issues an anonymous certificate but verifies the 201 real identity and maintains a record of that identity, the CA can 202 link the pseudonym in the Subject field to the real identity, hence 203 a potential "big brother" problem. 205 - If the CA issues a certificate with a certificate containing 206 a user-selected Subject name, and does not verify the user's 207 identity, the certificate is effectively untraceable. 209 - If CA issues an anonymous certificate using a blind signature 210 (see below), the CA cannot verify the contents of the certificate, 211 making the certificate untraceable and essentially forgeable. 212 (If a CA signs a certificate without examining its content, even 213 after verifying a user's identity, certificates issued by the CA 214 are essentially forgeable.) 216 To address the issues described above, we extend the simple 217 separation-of-authority concept already defined in the RA/CA PKI 218 model. First we restate the requirements in a more precise and 219 concise fashion, and introduce a basic model for achieving the 220 goals from a more general perspective. 222 3. Requirements 224 This document describes a new separation-of-authority model and 225 protocols for certificate issuance in a way that enables issuing 226 traceable anonymous certificates, while maintaining compatibility 227 with the standards used in existing PKIs. To do this, the 228 following requirements must be satisfied. 230 - The traceable anonymous certificate MUST be a syntactically 231 valid X.509 certificate in which the Subject field contains a 232 pseudonym. 234 - There must be technical means to counter a claim by a 235 malicious user who later denies having participated in the 236 activities that resulted in issuing a TAC. Specifically, when a 237 user is identified and requests issuance of a TAC, the mechanisms 238 employed MUST ensure that the user to whom the TAC is issued is the 239 one who requested the TAC (unless that user transfers the private 240 key to another party, unknown to the RA/CA). 242 - The traceability and revocation functions MUST support the 243 linkage between a user's true identity and the pseudonym in a 244 certificate issued to the user. Thus the solution MUST enable 245 determining a true identity from the anonymous certificate, upon 246 agreement among the authorities who collaborated to issue the 247 certificate. 249 4. Traceable Anonymous Certificate Model 251 A TAC is an EE certificate issued by a pair of entities that 252 operate in a split responsibility mode: a Blind Issuer (BI) and 253 an Anonymity Issuer (AI). The pair appear as a single CA to the 254 outside world, e.g., they are represented by a single CA 255 certificate. The public key in the CA certificate is used to verify 256 certificates issued by this CA in the normal fashion, 257 i.e., a relying party processes a TAC just like any other EE 258 certificates. 260 In this model the BI acts as a RA. It interacts with a user to 261 verify the user's "real" identity, just like a normal RA. 262 The BI maintains a database that can be used to map a TAC to the 263 user to whom it was issued, but only with the cooperation of the 264 AI. 266 This mapping will be initiated only if there is evidence that the 267 user to whom the TAC was issued has abused the anonymity provided 268 by the TAC. 270 The AI acts as a CA. It validates a certificate request submitted 271 by the user, using a standard certificate request format such as 272 PKCS10. The AI performs the functions common to a CA, including a 273 private key proof of possession (PoP) check, a name uniqueness 274 check among all certificates issued by it, assignment of a serial 275 number, etc. To effect issuance of the TAC, the AI interacts with 276 the BI, over a secure channel, to jointly create the signature on 277 the TAC, and sends the signed TAC to the user. 279 The AI does this without learning the user's real identity 280 (either from the user or from the BI). 282 The result of this split functionality between the BI and the AI 283 is that neither can unilaterally act to reveal the real user 284 identity. The AI has knowledge of the certificate issued to the 285 user, but no knowledge of the user's real identity. The BI knows 286 the user's real identity, but has no knowledge of the certificate 287 issued to that user. Only if the AI and BI collaborate can they 288 map the TAC issued to a user to the real identity of that user. 290 This system is not perfect. For example, it assumes that the AI 291 and BI collaborate to reveal a user's real identity only under 292 appropriate circumstances. The details of the procedural security 293 means by which this assurance is achieved are outside the scope of 294 this document. Nonetheless, there are security benefits to adopting 295 this model described in this document, based on the technical 296 approach used to enable separation of the BI and AI functions. 298 For example, the BI and AI can be operated by different 299 organizations in geographically separate facilities, and managed 300 by different staff. As a result, one can have higher confidence 301 in the anonymity offered to a user by the system, as opposed to a 302 monolithic CA operating model that relies only on procedural 303 security controls to ensure anonymity. 305 5. Issuing a TAC 307 The follow subsections describe the procedures and the protocols 308 employed to issue a TAC. To begin, BI and AI collaborate to 309 generate a public key pair (that represents the CA as seen by 310 relying parties) using a threshold signature scheme. Such schemes 311 have been defined for RSA. The details of how this is accomplished 312 depend on the algorithm in question, and thus are not described here. 313 The reader is referred to [17] where procedures for implementing RSA 314 threshold signatures are described. A DSA-based threshold signature 315 scheme will be incorporated into a future version of TAC [16]. 317 Note that this split signing model for certificate issuance is an 318 especially simple case of a threshold signature; the private key 319 used to sign a TAC is divided into exactly two shares, one held by 320 the BI and one held by the AI. Both shares must be used, serially, 321 to create a signature on a TAC. After the key pair for the (nominal) 322 CA has been generated and the private key split between the BI and 323 the AI, the public key is published, e.g., in a self-signed 324 certificate that represents the TAC CA. 326 Another public key cryptographic function that is an essential 327 part of this system is called "blind signing". To create a blind 328 signature one party encrypts a value to be signed, e.g., a hash 329 value of a certificate, and passes it to the signer. The signer 330 digitally signs the encrypted value, and returns it to the first 331 party. The first party inverts the encryption it applied with the 332 random value in the first place, to yield a signature on the 333 underlying data, e.g., a hash value. 335 This technique enables the signer to digitally sign a message, 336 without seeing the content of the message. This is the simplest 337 approach to blind signing; it requires that the public key needed 338 to invert the encryption not be available to the blind signer. 339 Other blind signing techniques avoid the need for this restriction, 340 but are more complex. 342 The tricky part of a cryptographic blinding function is that is must 343 be associative and commutative, with regard to a public key signature 344 function. Let B be a blinding function, B-INV is its inverse, and S 345 is a public key signature. The following relationship must hold: 346 B-INV( S (B (X) ) ) = B-INV( B( S (X) ) ) = S (X). RSA can be use 347 to blind a value with random value and to sign a blinded value, 348 because the modular exponentiation operation used by RSA for both 349 signature and for encryption is associative and commutative. 351 The TAC issuance process described below requires an ability for the 352 BI, the AI, and the user to employ secure communication 353 channels between one another. 355 Use of TLS [19] is one suitable means to establish such channels, 356 although other options also are acceptable. To this end, this 357 document assumes TLS as the default secure communication channel, 358 and thus requires that the BI and the AI have X.509 certificates 359 that represent them. 361 These certificates are independent of the certificate that 362 represents the CA (formed by the BI and the AI) and may be either 363 self-signed or issued by other CA(s). 365 Appendix B provides a top level description of the application of 366 TLS to these message exchanges. 368 5.1. Steps in issuing a TAC 370 Figure 1. depicts the procedures for issuing a TAC. The lines 371 represent steps in the issuance process, and the numbers refer to 372 these steps. 374 1 +---------------+ 376 +<-------->| Blind | 378 | 2 | Issuer (BI)| 380 | +---------------+ 382 +-------+ | ^ 384 | user |<------------>| 4 | 5 386 +-------+ | v 388 | 3 +----------------+ 390 +--------->| | 392 | | Anonymity | 394 | | Issuer (AI) | 396 +<-------- | | 398 6 +----------------+ 400 Figure 1. TAC issuance Procedures 402 Step 1 : A user authenticates himself to BI. This may be 403 effected via an in-person meeting or electronically. The same 404 sorts of procedures that RAs use for normal certificate issuance 405 are used here. Such procedures are not standardized, and thus 406 they are not described here in detail. For purposes of the TAC 407 architecture, we require the BI to establish a record in a 408 database for the user, and to generate a (locally) unique 409 identifier, called the UserKey, that will serve as a (database) 410 key for the record. The UserKey value MUST NOT be generated in an 411 fashion that permits any external entity (including the AI) to 412 infer a user's real identity from its value. (For example, is the 413 user's name is used as an input to a one-way hash algorithm to 414 generate the UserKey value, then additional random data must be 415 used as an input to prevent simple guessing attacks.) Associated 416 with the UserKey in this database is an expiration time. The 417 expiration time is used by BI and the AI to reject session-level 418 replay attacks in some exchanges, and to enable BI and AI to 419 garbage collect database records if a user initiates but does not 420 complete the certificate request process. 422 It is RECOMMENDED that the UserKey be a random or pseudo-random 423 value. Whenever the BI passes a UserKey to an external party, or 424 accepts the UserKey from an external party (e.g., the AI), the 425 value is embedded in digitally signed CMS object called a Token, 426 accompanied by the time stamp noted above. The signature on a 427 Token is generated by the BI. (Note that the certificate used is just 428 a certificate suitable for use with CMS, and is NOT the split-key 429 certificate used to verify TAC.) 431 The following ASN.1 syntax represents the UserKey and an expiration 432 time: 434 UserKey ::= OCTET STRING 435 Timeout ::= GeneralizedTime 437 In the context of this specification, GeneralizedTime value MUST 438 be expressed in Greenwich Mean Time (Zulu) and MUST include 439 seconds(YYYYMMDDHHMMSSZ). 441 Step 2 : BI presents to the user a data structure called a Token. 442 The Token must be conveyed to the user via a secure channel, e.g., 443 in person or via a secure communication channel. The secure channel 444 is required here to prevent a wiretapper from being able to acquire 445 the Token. For example, if the user establishes a one-way 446 authenticated TLS session to the BI in Step 1, this session could 447 be used to pass the Token back to the user. 449 The Token serves two purposes. During TAC issuance, the Token 450 is used to verify that a request to the AI has been submitted by a 451 user who is registered with the BI (and thus there is a record in 452 BI's database with the real identity of the user). This is necessary 453 to ensure that the TAC can later be traced to the user. If there is 454 a request to reveal the real identity of a user, the AI will release 455 the Token to the entity requesting that a TAC be traced, and that 456 entity will pass the Token to the BI, to enable tracing the TAC. 457 If the BI does not perform its part of the certificate issuance 458 procedure (in Step 6) before the Token expires, the BI can delete 459 the Token from the database as a means of garbage collection. The 460 timeout value in a Token is selected by the BI. 462 The Token is a ContentInfo with a contentType of id-kisa-tac-token 463 and a content that hold a SignedData of CMS SignedData object [6], 464 signed by the BI, where the eContent (EncapsulatedContentInfo) is a 465 SEQUENCE consisting of the UserKey and Timeout and eContentType MUST 466 be id-data. 468 EncapsulatedContentInfo ::= SEQUENCE { 469 eContentType ContentType, -- OBJECT IDENTIFIER : id-data 470 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 471 -- DER encoded with the input of 'SEQUENCE of the UserKey and 472 -- Timeout' 474 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 475 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 477 The signature (SignatureValue of SignerInfo) is generated using 478 the BI's private signature key, corresponding to the public key 479 present in the BI's certificate. (Note that this certificate is 480 just a certificate suitable for use with TLS, and is NOT the split- 481 key certificate used to verify a TAC.) The certificate(certificates) 482 MUST be present. Appendix A provides the ASN.1 syntax for the Token, 483 as a profiled CMS ContentInfo object. Appendix C provides the CMS 484 SignedData object profile for wrapping the Token. 486 Token ::= ContentInfo 488 Upon receipt of the Token, the user SHOULD verify the signature 489 using the BI public key and note the Timeout value to ensure that 490 the certificate request process is completed prior to that time. 492 Step 3 : The user prepares a certificate request in a standard 493 format, e.g., PKCS10 [3] or CMC[4]. The Subject field of the 494 certificate contains a pseudonym generated by the user. It is 495 anticipated that the CA (BI + AI) may provide software for users 496 to employ in constructing certificate requests. 498 If so, then this software can generate a candidate Subject name 499 to minimize the likelihood of a collision. If the user selects a 500 candidate pseudonym without such support, the likelihood of a 501 subject name collision probably will be greater, increasing the 502 likelihood that the certificate request will be rejected or that 503 the AI will have to generate a pseudonym for the user. 505 After constructing the certificate request, the user sends it, 506 along with the Token from Step 2, to the AI, via a secure channel. 507 This channel MUST be encrypted and one-way authenticated, i.e., 508 the user MUST be able to verify that it is communicating with the 509 AI, but the AI MUST NOT be able to verify the real identity of the 510 user. Typical use of TLS for secure web site access satisfies this 511 requirement. The certificate request of PKCS10 [3] or CMC[4] carries 512 the Token from Step 2. 514 The Token is carried as an attribute in a certificate request 515 (CertificationRequestInfo.attributes) where the attrType MUST be 516 id-kisa-tac below in PKCS10 format. The Token is set to 517 attrValues(Certificate Request Controls) where the attrType MUST be 518 id-kisa-tac in CMC[4] format. The TAC request message profile is 519 described in the section 5.3. 521 Step 4 : The AI, upon receipt of the certificate request 522 containing a Token, verifies that the request is consistent with 523 the processing defined for the request format (PKCS10). 524 If a Subject name is present, it verifies that the proposed 525 pseudonym is unique. The AI also verifies the signature on the 526 Token and, if it is valid, checks the Timeout value to reject a 527 replay attack based on an "timed-out" Token. 529 A Token with an old Timeout value is rejected out-of-hand by the 530 AI. (After a Token's Timeout time is reached, the AI deletes Token 531 from its cache.) Next, the AI compares the received Token against 532 a cache of recent (i.e., not "timed out"), validated Tokens. The AI 533 matches the resubmitted request to the original request, and responds 534 accordingly. For example, if a duplicate is detected, the certificate 535 request can be rejected as a replay. 537 If the Subject field contains a Subject name already issued by the 538 AI, the AI MUST either reject the certificate request, or 539 substitute a pseudonym it generates, depending on the policy of 540 the TAC CA. If the certificate request is acceptable, the AI 541 assigns a serial number and constructs a tbsCertificate (i.e., 542 the final form of the certificate payload, ready to be signed). 544 The AI then computes a hash over this data structure and blinds 545 the hash value. (The AI blinds the hash value using a key from a 546 public-key encryption pair where neither key is ever made public. 547 The other key from this pair is used by the AI in Step 6 to "un- 548 blind" the signed hash value.) 550 The AI sends the CMS ContentInfo object of TokenandBlindHash to the 551 BI, via a two-way authenticated and encrypted channel. 552 The two-way authentication and encryption is required to ensure 553 that the AI is sending these values to the BI, to allow the BI to 554 verify that the values were transmitted by the AI, and to prevent 555 a wiretapper from acquiring the Token. A TLS session in which 556 both parties employ certificates to authenticate one another is 557 the RECOMMENDED way to achieve this communication. 559 The TokenandBlindHash is a CMS ContentInfo with a contentType of id- 560 kisa-tac-tokenandblindhash and a content that hold a SignedData of 561 CMS SignedData object [6], signed by the AI, where the eContent 562 (EncapsulatedContentInfo) is a SEQUENCE consisting of the Token and 563 BlindedCertificateHash, and eContentType MUST be id-data. 565 EncapsulatedContentInfo ::= SEQUENCE { 566 eContentType ContentType, -- OBJECT IDENTIFIER : id-data 567 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 568 -- DER encoded with the input of 'SEQUENCE of the Token and 569 -- BlindedCertificateHash' 571 The signature (SignatureValue of SignerInfo) is generated using 572 the AI's private signature key, corresponding to the public key 573 present in the AI's certificate. (Note that this certificate is 574 just a certificate suitable for use with TLS, and is NOT the split- 575 key certificate used to issue a TAC.) The certificate(certificates) 576 MUST be present. 578 The following ASN.1 syntax represents the Token and 579 BlindedCertificateHash : 581 Token ::= ContentInfo 582 BlinedCertificateHash ::= OCTET STRING 584 Token is the value of ContentInfo in the certificate request message 585 (CertificationRequestInfo.attributes) from the Step 3. 587 BlindedCertificateHash is the blinded hash value for the 588 tbsCertificate. 590 Appendix A provides the ASN.1 syntax for the Token, as a profiled CMS 591 ContentInfo object. Appendix C provides the CMS SignedData object 592 profile for wrapping the Token. 594 TokenandBlindHash ::= ContentInfo 596 Step 5 : The BI receives the Token and blinded certificate 597 hash via the secure channel described above. First the BI verifies 598 the signature on the TokenandBlindHash generated by AI and then 599 verifies the signature on the Token to ensure that it is a 600 legitimate Token generated by the BI. Next, the BI checks its 601 database to ensure that the UserKey value from the Token is present 602 and that the Token has not been used to authorized issuance of a 603 certificate previously. 605 This check is performed to ensure that the BI has authenticated the 606 user and entered the user's real identity into the BI's database. 607 Each Token authorizes issuance of only one certificate, so the 608 check also ensures that the same Token is not used to authorized 609 issuance of more than one certificate. These checks ensure that 610 the certificate issued by the AI to this user will be traceable, 611 if needed. 613 The BI uses its share of the threshold private 614 signature key to sign the blinded certificate hash and returns 615 the CMS SignedData back to AI, where it has the 'SEQUENCE of Token 616 and PartiallySignedCertificateHash' in SignedData.eContent field. 618 The following ASN.1 syntax represents the Token and 619 PartiallySignedCertificateHash : 621 Token ::= ContentInfo 622 PartiallySignedCertificateHash ::= OCTET STRING 624 Token is the token value of the TokenandBlindHash(eContent in which 625 'SEQUENCE consisting of the both Token and 626 PartiallySignedCertificateHash') from the Step 4. 628 PartiallySignedCertificateHash is the signature value generated by 629 BI's share of the threshold private signature key on 630 BlindedCertificateHash from the Step 4. 632 The TokenandPartiallySignedCertificateHash is a CMS ContentInfo with 633 a contentType of id-kisa-tac-tokenandpartially and a content that 634 hold a SignedData of CMS SignedData object [6], signed by the BI, 635 where the eContent(EncapsulatedContentInfo) is a SEQUENCE consisting 636 of the Token and PartiallySignedCertificateHash, and eContentType 637 MUST be id-data. 639 EncapsulatedContentInfo ::= SEQUENCE { 640 eContentType ContentType, -- OBJECT IDENTIFIER : id-data 641 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 642 -- DER encoded with the input of 'SEQUENCE of the Token and 643 -- PartiallySignedCertificateHash' 645 The signature (SignatureValue of SignerInfo) is generated using 646 the BI's private signature key, corresponding to the public key 647 present in the BI's certificate. (Note that this certificate is 648 just a certificate suitable for use with TLS, and is NOT the split- 649 key certificate used to issue a TAC.) The certificate(certificates) 650 MUST be present. Appendix A provides the ASN.1 syntax for the Token, 651 as a profiled CMS SignedData object. Appendix C provides the CMS 652 SignedData object profile for wrapping the Token. 654 TokenandPartiallySignedCertificateHash ::= ContentInfo 656 Step 6 : Upon receipt of the TokenandPartiallySignedCertificateHash, 657 the AI verifies the signature on the PartiallySignedCertificateHash, 658 generated by BI and then matches the Token against its list of 659 outstanding requests to the BI. The AI then "un-blinds" the 660 blindHashValue, using the other key from the key pair employed Step 4. 661 This reveals the partially-signed certificate hash. The AI then 662 applies its part of the split private key to complete the signature 663 of the certificate for the user. 665 It records the certificate and the Token value in its database, to 666 enable later tracing of the certificate to the real user identity, 667 if needed. The AI transmits the completed certificate to the user, 668 via the response message from the request protocol employed by the 669 user in Step 3, PKCS10. 671 The user may now employ the certificate with any PKI-enabled 672 application or protocol that makes use of X.509 certificates 673 (consistent with the key usage, and EKU values in the certificate). 674 Note that the user should be prepared to accommodate delays in the 675 certificate issuance process. For example, a connection between the 676 user and the AI might fail sometime after the user submits a 677 certificate request at the end of Step 3 and before the AI returns 678 the certificate at the end of Step 6. If this happens, the user 679 should resubmit the request. The AI and BI retain sufficient state 680 to be able to match the resubmitted request to the original request, 681 and respond accordingly. If the process failed in steps 5 or 6, the 682 AI returns an error indication to the user. 684 5.2. Mapping a TAC to a User's Real Identity 686 If a user to whom a TAC has been issued abuses the anonymity 687 provided by the TAC, the TAC can be traced to the identity of that 688 user. Mapping a TAC to a user's real identity is a four step 689 process, described below and illustrated in Figure 2. 691 C +---------------+ 693 +<-------->| Blind | 695 | D | Issuer (BI)| 697 | +---------------+ 699 +---------+ | 701 | Relying |<---------->| 703 | Party | | 705 +---------+ | 707 | A +----------------+ 709 +<-------->| Anonymity | 711 B | Issuer (AI) | 713 +----------------+ 715 Figure 2. Revealing a TAC User's Real Identity 717 Step A: The AI verifies the assertion by an aggrieved party 718 that a TAC user has abused the anonymity provided by his TAC. 719 The procedures used by AI to verify that such abuse has occurred 720 are outside the scope of this document. No protocol is defined 721 here for the interaction between the aggrieved party and AI. 722 The only technical requirement is that the TAC of the offending 723 user be provided to the AI. If AI determines that there is 724 sufficient evidence of abuse to trace the TAC to the user, the AI 725 revokes the TAC, by listing its serial number on the next CRL 726 issued by the AI. 728 An AI unilaterally manages the CRL for a TAC. Because RFC 5280 729 implementations are not required to process indirect CRLs, 730 we create a second certificate for the CA, under the TAC CA. Revoked 731 EE certificates issued by the TAC CA are recorded on this CRL and 732 validated using this second CA certificate. 734 This CA certificate will have the cRLSign bit set in KeyUsage 735 extension, but not the keyCertSign bit. The private key for this 736 certificate will be held by the AI, so that it can issue CRLs 737 unilaterally. 739 The Subject DN will be the same in both CA certificates, which 740 reinforces the notion that the CRL issuer is the same entity as the 741 TAC issuer, and that this CRL is not an indirect CRL. Because the 742 CRL issuer does not issue any certificates itself, there is no 743 possible serial number conflict. This will be the only CA 744 certificate issued under the TAC CA certificate (and thus it will 745 be signed jointly by the BI and AI). We recommend that the CRL for 746 this CA certificate be similarly long-lived, as it too needs to be 747 signed by the BI and AI. Each EE TAC certificate MUST contain a 748 CRLDP that points to the CRL issued by this CA, to ensure that RPs 749 know to check this CRL vs. the CRL that covers only the CRL CA. 750 (If the AI uses OCSP [15] to convey the revocation status of TACs, an 751 equivalent procedure is employed.) If it is later determined that the 752 revocation was not warranted, a new TAC can be issued, to preserve 753 the anonymity of the user in future transactions. 755 Step B: The AI searches its database, e.g., based on the serial 756 number in the TAC, to locate the Token that was passed between 757 the AI and BI during the issuance process (Steps 5 and 6 above). 758 The AI passes this Token to the aggrieved party via an encrypted 759 and two-way authenticated channel. Encryption is required to 760 prevent disclosure of the Token, and two-way authentication is 761 required to ensure that the aggrieved party and the AI know that 762 they are communicating with each other. Two-way authenticated TLS 763 is the RECOMMENDED means of implementing this channel, though 764 other approaches are allowed. 766 Step C and D : The aggrieved party transits the Token to the BI, 767 via an encrypted and two-way authenticated channel. The channel 768 MUST be encrypted to prevent disclosure of the Token, and two-way 769 authentication is required to ensure that the aggrieved party and 770 the BI know that they are communicating with each other. 771 If specified by the CP for the TAC CA, the BI will independently 772 determine that there is sufficient evidence of abuse to trace the 773 TAC to the user, before proceeding. The BI verifies its signature 774 on the Token, to verify that this is a Token generated by it and 775 presumably released to the aggrieved party by the AI. Next the BI 776 searches its database using the UserKey value extracted from the 777 Token. The BI retrieves the user's real identity and provides it 778 to the aggrieved party. (By requiring the aggrieved party to 779 interact with both the AI and the BI, the BI can verify that it is 780 dealing with an aggrieved party, not with the AI acting 781 unilaterally.) 783 5.3. TAC Request Message Format Profile 785 TAC request MAY use either of PKCS10 or CMC. An AI MUST support 786 PKCS10 and MAY support CMC. 788 5.3.1. PKCS10 Profile 790 This profile refines the specification in PKCS10 [3], as it relates 791 to TAC. A Certificate Request Message object, formatted according to 792 PKCS10, is passed to the AI. 794 This profile applies the following additional constraints to fields 795 that may appear in a CertificationRequestInfo: 797 Version 798 This field is mandatory and MUST have the value 0. 800 Subject 802 This field MUST be present. If the value of this field is empty, 803 AI will generate a subject name that is unique in the context of 804 certificates issued by this issuer. If the Subject 805 field contains a Subject name already issued by the AI, the AI 806 MUST either reject the certificate request, or substitute a 807 pseudonym it generates, depending on the policy of the TAC CA. 809 SubjectPublicKeyInfo 810 This field specifies the subject's public key and the 811 algorithm with which the key is used. 813 Attributes 814 PKCS10[3] defines the attributes field as key-value pairs 815 where the key is an OID and the value's structure depends on the 816 key. The attribute field MUST include id-kisa-tac attribute, which 817 holds the Token and is defined below. The Attributes field MAY also 818 contain X509v3 Certificate Extensions and any PKCS9 [7] 819 extensionRequest attributes that the subscriber would like to have 820 included in the certificate. The profile for extensions in 821 certificate requests is specified in the RFC5280 [2]. 823 5.3.2. CMC Profile 825 This profile refines the Certificate Request messages in Certificate 826 Management over CMS in CMC [4], as it relates to TACs. 828 A Certificate Request messages, formatted according to the 829 CMC[4], is passed to the AI . 831 With the exception of the public key related fields, the CA is 832 permitted to alter any requested field when issuing a corresponding 833 certificate. 835 This profile recommends the full PKI Request of the two types of PKI 836 requests (Simple or Full PKI Request) and the PKI Request SHOULD be 837 encapsulated in SignedData with an encapsulated content type of id- 838 cct-PKIData. 840 This profile applies the following additional constraints to fields 841 that may appear in a Certificate Request Template of CRMF[5]: 843 Version 844 This field MAY be absent, or MAY specify the request of a 845 Version 3 Certificate. It SHOULD be omitted. 847 SerialNumber 848 As per CRMF [5], this field is assigned by the CA and MUST 849 be omitted in this profile. 851 SigningAlgorithm 852 As per CRMF [5], this field is assigned by the CA and MUST 853 be omitted in this profile. 855 Issuer 856 This field is assigned by the CA and MUST be omitted in 857 this profile. 859 Validity 860 This field MAY be omitted. If omitted, the AI will issue 861 a Certificate with Validity dates as determined by the TAC CA 862 policy. If specified, then the CA MAY override the requested 863 values with dates as determined by the TAC CA policy. 865 Subject 866 This field MUST be present. If the value of this 867 field is empty, in which case the AI MUST generate a 868 subject name that is unique in the context of certificates issued 869 by this issuer. If the Subject field contains a Subject name 870 already issued by the AI, the AI MUST either reject the certificate 871 request, or substitute a pseudonym it generates, depending on the 872 policy of the TAC CA. 874 PublicKey 875 This field MUST be present. 877 This profile also refines constraints that may appear in a 878 Certificate Request controls: 880 The Token is set to attrValues (CertRequest.controls) where the 881 attrType MUST be id-kisa-tac. 883 This profile also refines constraints that may appear in a 884 Certificate Request controls : The Token is set to attrValues where 885 the attrType MUST be id-kisa-tac. 887 The Certification Request Formats based on PKCS10 can be referred to 888 5.3.1 PKCS10 Profile. 890 6. Security Considerations 892 The anonymity provided by the architecture and protocols defined 893 in this document is conditional. Moreover, if the user employs 894 the same TAC for multiple transactions (with the same or different 895 parties), the transactions can be linked through the use of the 896 same TAC. Thus the anonymity guarantee is "weak" even though the 897 user's real identity is still hidden. 899 To achieve stronger anonymity, a user may acquire multiple TACs, 900 through distinct iterations of the protocol. Since each TAC is 901 generated independently, it should not be possible for a relying 902 party to discover a link between pseudonyms unless the tracing 903 feature of this scheme is invoked. If the TAC has a long validity 904 interval, this increases the probability that the identity of a 905 TAC user will be discovered, e.g., as a result of linking user 906 transactions across multiple servers. Thus we recommend that each 907 TAC CA consider carefully how long the validity for a TAC 908 certificate should be. In the course of issuing a TAC, the AI and the 909 user interact directly. Thus the AI may have access to lower layer 910 information (e.g., an IP address) that might reveal the user's 911 identity. A user concerned about this sort of possible identity 912 compromise should use appropriate measures to conceal such 913 information, e.g., a network anonymity service such as Tor [insert an 914 informative reference to Tor]. 916 This document makes no provisions for certificate renewal or rekey; 917 we recommend TAC users acquire new TACs periodically, to further 918 reduce the likelihood of linkage. It also may be possible to 919 determine the identity of a user via information carried by lower 920 level protocols, or by other, application-specific means. 921 For example, the IP address of the user might be used to identify 922 him/her. For this reason, we recommend that a TAC be used primarily 923 to access web services with anonymity. Note that the TAC 924 architecture described in this document is not capable of using 925 certificates for use with SMIME, because there is no provision to 926 issue two certificates (one for encryption and one for 927 signatures) that contain the same (anonymous) Subject name. 928 An analogous problem might arise if a user visits a site (and 929 does not conceal his/her identity), the site deposits a "cookie" 930 into the user's browser cache, and the user later visits a site and 931 employs a TAC with the presumption of anonymity. 933 The use of a TAC is a tool to help a user preserve anonymity, 934 but it is not, per se, a guarantee of anonymity. We recommend that 935 each TAC CA issue certificates with only one lifetime, in order to 936 avoid the complexity that might arise otherwise. If a TAC CA 937 offered certificates with different lifetimes, then it would need 938 to communicate this information from the BI to AI in a way that 939 does not unduly compromise the anonymity of the user. 941 This architecture uses the UserKey to link a TAC to the 942 corresponding real user identity. The UserKey is generated in a 943 fashion to ensure that it cannot be examined to determine a 944 user's real identity. UserKey values are maintained in two 945 distinct databases: the BI database maps a UserKey to a real user 946 identity, and the AI database maps a TAC to a UserKey. The UserKey 947 is always carried in a signed data object, a Token. The Token is 948 signed to allow the BI to verify its authenticity, to prevent 949 attacks based on guessing UserKey values. The Token also carries a 950 Timeout value to allow the AI and BI to reject session-level 951 replay attacks, and to facilitate garbage collection of Ai and BI 952 databases. 954 Threshold cryptography is employed to enable strong separation of 955 the BI and AI functions, and to ensure that both must cooperate to 956 issue certificates under the aegis of a TAC CA. (The AI and BI must 957 ensure that the threshold cryptographic scheme they employ does not 958 provide an advantage to either party based on the way the key 959 splitting is effected.) Blind signatures are used with threshold 960 cryptography to preserve the separation of functions, i.e., 961 to prevent the BI from learning the hash value of the TAC issued 962 by the AI. 964 Message exchanges between a user and the BI or the AI, between the 965 AI and BI, and between an aggrieved party and the AI and BI all make 966 use of secure channels. These channels are encrypted to prevent 967 disclosure of the Token value and of the pseudonym in the TAC 968 request and response and in a tracing request. The channels are 969 two-way authenticated to allow the AI and BI to verify their 970 respective identities when communication with one another, and 971 one-way authenticated to allow the user to verify their 972 identities when he communicates with them. Two-way authentication 973 is employed for communication between an aggrieved party and the 974 AI and BI, to allow all parties to verify the identity of one 975 another. 977 There is an opportunity for the AI to return the wrong UserKey to 978 an aggrieved party, which will result in tracing a certificate to 979 the wrong real user identity. This appears to be unavoidable in 980 any scheme of this sort, since the database maintained by the BI 981 is intentionally ignorant of any info relating a UserKey to a TAC. 983 A TAC CA MUST describe in its CP how long it will retain the data 984 about certificates it issued, beyond the lifetime of these 985 certificates. This will help a prospective TAC subject gauge the 986 likelihood of unauthorized of his/her identity as a result of a 987 compromise of this retained data. It also alerts relying parties 988 of the timeframe (after expiration of a certificate) in which an 989 alleged abuse must be brought to the attention of the AI and BI, 990 before the data linking a cert to the real user identity is 991 destroyed. 993 7. IANA Considerations 995 This document does not require any IANA registration. 997 8. Acknowledgments 999 Tim Polk (NIST), Stefan Santesson(ACC-sec.com), Jim Schaad (Soaring 1000 Hawk), David A. Cooper (NIST), SeokLae Lee, JongHyun Baek, SoonTae 1001 Park (KISA), Taekyoung Kwon (Sejong Univ.), JungHee Cheon (Seoul 1002 National Univ.), and YongDae Kim Minnesota Univ.) have significantly 1003 contributed to work on the concept of TAC and identified security 1004 issues. Their comments enhanced the maturity of the document. 1006 9. References 1008 9.1. Normative References 1010 [1] Bradner, S., "Key words for use in RFCs to Indicate 1011 Requirement Levels", BCP 14, RFC 2119, March 1997. 1013 [2] D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, 1014 W. Polk, "Internet X.509 Public Key Infrastructure 1015 Certificate and Certificate Revocation List (CRL) Profile," 1016 RFC 5280, May 2008. 1018 [3] M. Nystrom, B Kaliski "PKCS10 : Certificate Request Syntax 1019 Specification version 1.7", RFC 2986, November 2000. 1021 [4] J. Schaad, M. Myers, M. Nystrom, B Kaliski "Certificate 1022 Management over CMS (CMC)", RFC 5272, June 2008. 1024 [5] J. Schadd, "Internet X.509 Public Key Infrastructure 1025 Certificate Request Message Format(CRMF)", RFC 4211,September 2005. 1027 [6] R. Hously, "Cryptographic Message Syntax(CMS)", RFC 3852, July 1028 2004. 1030 [7] M. Nystrom, B. Kaliski, "PKCS #9: Selected Object Classes and 1031 Attribute Types Version 2.0", RFC 2985, November 2000 1033 9.2. Informative References 1035 [8] S. Brands, Rethinking public key infrastructures and digital 1036 certificates - Building in Privacy, PHD thesis, Eindhoven 1037 Institute of Technology, Eindhoven, The Netherlands, 1999. 1039 [9] D. Chaum, "Blind signature system," CRYPTO '83, Plenum 1040 Press, page 153, 1984. 1042 [10] J. Graaf and O. Carvalho, "Reflecting on X.509 and LDAP, or 1043 How separating identity and attributes could simplify a PKI" 1044 WSEG 2004, pp. 37-48. 1046 [11] R. Grimm and P. Aichroth, "Privacy Protection for Signed 1047 Media Files: A Separation-of-Duty Approach to the Lightweight 1048 DRM (LWDRM) System," ACM MM&Sec'04, pp. 93-99, 2004 1050 [12] R. Rivest, A. Shamir, and L. Adleman, "A method for 1051 obtaining digital signature and public-key cryptosystems," 1052 Communications of the ACM, vol. 21, no. 2, pp.120-126, 1978. 1054 [13] X.509, "Information technology - Open Systems 1055 Interconnection - The Directory: Public-key and attribute 1056 certificate frameworks," ITU-T Recommendation X.509, March 1057 2000. Also avaiable at ISO/IEC 9594-8, 2001. 1059 [14] S. Rafaeli, M. Rennhard, L. Mathy, B. Plattner, and D. 1060 Hutchison, "An Architecture for Pseudonymous e-Commerce," 1061 AISB'01 Symposium on Information Agents for Electronic 1062 Commerce, pp. 33-41, 2001. 1064 [15] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, 1065 "X.509 Internet Public Key Infrastructure Online Certificate 1066 Status Protocol - OCSP", June 1999. 1068 [16] Philip MacKenzie and Michael K. Reiter, "Two-Party Generation 1069 of DSA Signature", Crypto 2001. 1071 [17] Shaohua Tang, "Simple Threshold RSA Signature Scheme Based on 1072 Simple Secret Sharing", 2005 1074 [18] Taekyoung Kwon, Jung Hee Cheon, Yongdae Kim, Jae-Il Lee, 1075 "Privacy Protection in PKIs : A Separation of Authority 1076 Approach", 2007 1078 [19] T. Dierks, "The Transport Layer Security (TLS) Protocol Version 1079 1.2", 2008 1081 [20] B.Ramsdell, "S/MIME verson 3 Message Specification", 1999 1083 APPENDIX A: Traceable Anonymous Certificate ASN.1 Modules 1085 DEFINITIONS IMPLICIT TAGS ::= 1087 BEGIN 1089 -- EXPORTS All 1090 -- The types and values defined in this module are exported for 1091 -- use in the other ASN.1 modules. Other applications may use 1092 -- them for their own purposes. 1094 IMPORTS 1096 -- Imports from RFC 3280 [PROFILE], Appendix A.1 1097 AlgorithmIdentifier, Certificate, CertificateList, 1098 CertificateSerialNumber, Name FROM PKIX1Explicit88 1099 { iso(1) identified-organization(3) dod(6) 1100 internet(1) security(5) mechanisms(5) pkix(7) 1101 mod(0) pkix1-explicit(18) } 1103 -- Imports from CMS 1104 ContentInfo, SignedData FROM 1105 CryptographicMessageSyntax2004{ iso(1) 1106 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1107 smime(16) modules(0) cms-2004(24)} 1109 UserKey ::= OCTET STRING 1111 Timeout ::= GeneralizedTime 1113 BlinedCertificateHash ::= OCTET STRING 1115 PartiallySignedCertificateHash ::= OCTET STRING 1117 EncapsulatedContentInfo ::= SEQUENCE { 1118 eContentType ContentType, -- OBJECT IDENTIFIER : id-data 1119 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1121 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 1122 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 1124 Token ::= ContentInfo 1125 TokenandBlindHash ::= ContentInfo 1127 TokenandPartiallySignedCertificateHash ::= ContentInfo 1129 id-KISA OBJECT IDENTIFIER ::= {iso(1) member-body(2) korea(410) 1130 kisa(200004)} 1132 id-npki OBJECT IDENTIFIER ::= {id-KISA 10} 1134 id-attribute OBJECT IDENTIFIER ::= {id-npki 1} 1136 id-kisa-tac OBJECT IDENTIFIER ::= {id-attribute 1} 1138 id-kisa-tac-token OBJECT IDENTIFIER ::= { id-kisa-tac 1} 1140 id-kisa-tac-tokenandblindbash OBJECT IDENTIFIER ::= { id-kisa-tac 2} 1142 id-kisa-tac-tokenandpartially OBJECT IDENTIFIER ::= { id-kisa-tac 3} 1144 END 1146 APPENDIX B: TAC message exchanges over Transport Layer Security 1148 TAC message exchanges between a user and the BI or the AI, between 1149 the AI and BI, and between an aggrieved party and the AI and BI 1150 all make use of secure channels to prevent disclosure of the Token 1151 value and of the pseudonym in the TAC request and response and in a 1152 tracing request. The Transport Layer Security Protocol v1.2 [19] 1153 (TLS) is a suitable security protocol to protect these message 1154 exchanges and this document recommends use of TLS to protect these 1155 exchanges. The following text describes how the handshake part of TLS 1156 should be employed to protect each type of exchange. Note that no 1157 specific cipher suites are specified for use here; the choice of 1158 suites is up to the client and servers, as is commonly the case. 1160 B.1. Message exchanges between a User and the BI or the AI 1162 The channels between a User and the BI or the AI are one-way 1163 authenticated to allow the user to verify their identities when he 1164 communicates with them. 1166 User BI or AI 1168 ClientHello --------> 1170 ServerHello 1171 Certificate 1172 <-------- ServerHelloDone 1173 ClientKeyExchange 1174 [ChangeCipherSpec] 1175 Finished --------> 1176 [ChangeCipherSpec] 1177 <--------- Finished 1178 TAC Message <---------> TAC Message 1180 Figure 3. TAC Message exchanges between a User and the BI or the AI 1182 B.2. Message exchanges between the BI and the AI 1184 The channels between the BI and the AI are two-way authenticated to 1185 allow the AI and BI to verify their respective identities when 1186 communication with one another. 1188 BI AI 1190 ClientHello --------> 1191 ServerHello 1192 Certificate 1193 CertificateRequest 1194 <-------- ServerHelloDone 1195 Certificate 1196 ClientKeyExchange 1197 CertificateVerify 1198 [ChangeCipherSpec] 1199 Finished --------> 1200 [ChangeCipherSpec] 1201 <--------- Finished 1202 TAC Message <---------> TAC Message 1204 Figure 4. TAC Message exchanges between BI and AI 1206 B.3. Message exchanges between the aggrieved party and the AI and or 1207 the BI 1209 The channels between a User and the BI or the AI are two-way 1210 authenticated, to allow both parties to verify the identity of one 1211 another. 1213 User BI or AI 1215 ClientHello --------> 1216 ServerHello 1217 Certificate 1218 CertificateRequest 1219 <-------- ServerHelloDone 1220 Certificate 1221 ClientKeyExchange 1222 CertificateVerify 1223 [ChangeCipherSpec] 1224 Finished --------> 1225 [ChangeCipherSpec] 1226 <--------- Finished 1227 TAC Message <---------> TAC Message 1229 Figure 5. TAC Message exchanges between a aggrieved party and the 1230 BI or the AI 1232 APPENDIX C: Cryptographic Message Syntax Profile for TAC Token. 1234 Using the Cryptographic Message Syntax(CMS)[6], TAC Token is a type 1235 of signed-data object. The general format of a CMS object is : 1237 ContentInfo ::= SEQUENCE { 1238 contentType ContentType, 1239 content [0] EXPLICIT ANY DEFINED BY contentType } 1241 ContentType ::= OBJECT IDENTIFIER 1243 As a TAC is a signed-data object, it uses the corresponding OID, 1244 1.2.840.113549.1.1.2. 1246 C.1. Signed-Data Content Type 1248 According to the CMS specification, the signed-data content type 1249 shall have ASN.1 type SignedData: 1251 SignedData ::= SEQUENCE { 1252 version CMSVersion, 1253 digestAlgorithms DigestAlgorithmIdentifiers, 1254 encapContentInfo EncapsulatedContentInfo, 1255 certificates [0] IMPLICIT CertificateSet OPTIONAL, 1256 crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, 1257 signerInfos SignerInfos } 1259 DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier 1261 SignerInfos ::= SET OF SignerInfo 1263 The elements of the signed-data content type are as follows: 1265 Version 1266 The version is the syntax version number. It MUST be 3, 1267 corresponding to the signerInfo structure having version number 3. 1269 digestAlgorithms 1270 This field specifies digest Algorithms. 1272 encapContentInfo 1273 This element is defined in Appendix C.1.1. 1275 certificates 1276 The certificates element MUST be included and MUST 1277 contain only the single PKI EE certificate needed to validate this 1278 CMS Object. The CertificateSet type is defined in section 10 of 1279 RFC3852 [6]. 1281 crls 1282 The crls element MUST be omitted. 1284 signerInfos 1285 This element is defined in Appendix C.1.2. 1287 C.1.1. encapContentInfo 1289 encapContentInfo is the signed content, consisting of a content type 1290 identifier and the content itself. 1292 EncapsulatedContentInfo ::= SEQUENCE{ 1293 eContentType ContentType, 1294 eContent [0] EXPLICIT OCTET STRING OPTIONAL } 1296 ContentType ::= OBJECT IDENTIFIER 1298 The elements of this signed content type are as follows: 1300 eContentType 1301 The ContentType for an TAC Token is id-data and has the 1302 numerical value of 1.2.840.113549.1.7.1. 1304 eContent 1305 The content of an TAC Token is the DER encoded with the 1306 input of 'SEQUENCE of UserKey and Timeout'. 1308 C.1.2. signerInfos 1310 SignerInfo is defined under CMS as: 1312 SignerInfo ::= SEQUENCE { 1313 version CMSVersion, 1314 sid SignerIdentifier, 1315 digestAlgorithm DigestAlgorithmIdentifier, 1316 signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, 1317 signatureAlgorithm SignatureAlgorithmIdentifier, 1318 signature SignatureValue, 1319 unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } 1321 The content of the SignerInfo element are as follows: 1323 Version 1324 The version number MUST be 3, corresponding with the 1325 choice of SubjectKeyIdentifier for the sid. 1327 Sid 1328 The sid is defined as: 1330 SignerIdentifier ::= CHOICE { 1331 issuerAndSerialNumber IssuerAndSerialNumber, 1332 subjectKeyIdentifier [0] SubjectKeyIdentifier } 1333 For a TAC Token, the sid MUST be a SubjectKeyIdentifier. 1335 digestAlgorithm 1336 This field specifies digest Algorithms. 1338 signedAttrs 1339 The signedAttr element MUST be omitted. 1341 SignatureAlgorithm 1342 This field specifies the signature Algorithm. 1344 Signature 1345 The signature value is defined as: 1347 SignatureValue ::= OCTET STRING 1349 The signature characteristics are defined by the digest 1350 and signature algorithms. 1352 UnsignedAttrs 1353 unsignedAttrs MUST be omitted. 1355 Author's Addresses 1357 SangHwan Park 1358 Korea Information Security Agency 1359 78, Garak-Dong, Songpa-Gu, Seoul, Korea 1360 Email: shpark@kisa.or.kr 1362 Haeryong Park 1363 Korea Information Security Agency 1364 78, Garak-Dong, Songpa-Gu, Seoul, Korea 1365 Email: hrpark@kisa.or.kr 1367 YooJae Won 1368 Korea Information Security Agency 1369 78, Garak-Dong, Songpa-Gu, Seoul, Korea 1370 Email: yjwon@kisa.or.kr 1372 JaeIl Lee 1373 Korea Information Security Agency 1374 78, Garak-Dong, Songpa-Gu, Seoul, Korea 1375 Email: jilee@kisa.or.kr 1377 Stephen Kent 1378 BBN Technologies 1379 10 Moulton Street Cambridge, MA 02138 1380 Email: kent@bbn.com