[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 RFC 5636

Network Working Group                                            S.Park
Internet Draft                                                   H.Park
Intended status: Experimental                                    Y. Won
Expires: November 2009                                           J. Lee
                                                                   KISA
                                                                 S.Kent
                                                       BBN Technologies
                                                          May 22, 2009

                      Traceable Anonymous Certificate
                        draft-ietf-pkix-tac-04.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 22, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Park                  Expires November 22, 2009               [Page 1]

Internet-Draft     Traceable Anonymous Certificate            May 2009


Abstract

   Public Key Infrastructure (PKI) provides a powerful means of
   authenticating individuals, organizations, and computers(e.g.,
   web servers). However, when individuals use certificates to
   access resources on the public Internet, there are legitimate
   concerns about personal privacy, and thus there are increasing
   demands for privacy enhancing techniques on the Internet.

   In a PKI, an authorized entity such as a certification Authority
   (CA) or a Registration Authority (RA) may be perceived, from a
   privacy perspective, as a "big brother," even when a CA issues a
   certificate containing a Subject name that is a pseudonym. This
   is because such entities can always map a pseudonym in a
   certificate they issued to the name of the real user to whom it
   was issued. This document defines a practical architecture and
   protocols for offering privacy for a user who requests and uses
   an X.509 certificate containing a pseudonym, while still retaining
   the ability to map such a certificate to the real user who
   requested it. The architecture is compatible with IETF certificate
   request formats such as PKCS10 [3]and CMC[4]. The architecture
   separates the authorities involved in issuing a certificate: one
   for verifying ownership of a private key (Blind Issuer) and the
   other for validating the contents of a certificate (Anonymity
   Issuer). The end-entity(EE) certificates issued under this model
   are called Traceable Anonymous Certificates (TACs).



Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [1].



Table of Contents

   1. Introduction..................................................3
   2. General Overview..............................................5
   3. Requirements..................................................5
   4. Traceable Anonymous Certificate Model.........................6
   5. Issuing a TAC.................................................7


Park                  Expires November 22, 2009               [Page 2]

Internet-Draft     Traceable Anonymous Certificate            May 2009


      5.1. Steps in issuing a TAC...................................9
      5.2. Mapping a TAC to a User's Real Identity.................16
      5.3. TAC Request Message Format Profile......................18
         5.3.1. PKCS10 Profile.....................................18
         5.3.2. CMC Profile........................................19
   6. Security Considerations......................................20
   7. IANA Considerations..........................................23
   8. Acknowledgments..............................................23
   9. References...................................................23
      9.1. Normative References....................................23
      9.2. Informative References..................................23
   APPENDIX A: Traceable Anonymous Certificate ASN.1 Modules.......25
   APPENDIX B: TAC message exchanges over Transport Layer Security.27
   Author's Addresses..............................................32



1. Introduction

   A Public Key Infrastructure (PKI) typically serves to identify the
   holder of a private key (to the corresponding public key in a
   certificate), in a standard fashion. The public key, identity, and
   related information, are signed by an entity acting as a
   Certification Authority (CA) as specified in X.509 and as profiled
   for use in the Internet [2]. During the past decade, PKIs have been
   widely deployed to support various types of communications and
   transactions over the Internet.

   However, with regard to privacy on the Internet, a PKI is generally
   not supportive of privacy, at least in part because of the
   following issues:

       - A certificate typically contains, in the Subject field the
   true identity of the user to whom it was issued. This identity is
   disclosed to a relying party (e.g., a web site or the recipient
   of an SMIME message [20]) whenever the certificate holder presents
   it in a security protocol that requires a user to present a
   certificate. In some protocols, e.g., TLS, a user's certificate
   is sent via an unencrypted channel, prior to establishing a
   secure communication capability.

       - A certificate often is published by the CA, for example in a
   directory system, which may be widely accessible.

       - An anonymous (end entity) certificate [9] is one that
   indicates that the holder's true identity is not represented in the
   subject field. (Such a certificate might more accurately be called


Park                  Expires November 22, 2009               [Page 3]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   pseudonymous since an X.509 certificate must contain an identifier
   to comply with PKI format standards, and a CA must not issue
   multiple certificates with the same Subject name to different
   entities. However, we use the more common term "anonymous"
   throughout this document to refer to such certificates.)
   Issuance of anonymous certificates could enhance user privacy.

   There is however, a need to balance privacy and accountability
   when issuing anonymous certificates. If a CA/RA is unable to map
   an anonymous certificate to the real user to whom it was issued,
   the user might abuse the anonymity afforded by the certificate,
   because there would be no recourse for relying parties.

   A CA or RA generally would be able to map an anonymous certificate
   to the user to whom it was issued, to avoid such problems. To do
   so the CA/RA would initially identify the user and maintain a
   database that relates the user's true identity to the pseudonym
   carried in the certificate's Subject field.

   In a traditional PKI, there is a nominal separation of functions
   between a RA and a CA, but in practice these roles are often
   closely coordinated. Thus either the RA or CA could, in principle,
   unilaterally map an autonomous certificate to the real user
   identity.

   The architecture, syntax, and protocol conventions described in
   this document allow anonymous certificates to be issued and used
   in existing PKIs in a way that provides a balance between privacy
   and a conditional ability to map an anonymous certificate to the
   individual to whom it was issued.

   An anonymous certificate (Traceable Anonymous Certificate) in this
   document is issued by a pair of entities that operate in a split
   responsibility mode: a Blind Issuer (BI) and an Anonymity Issuer (AI).
   The conditional traceability offered by this model assumes strong
   separation between the RA and CA roles, and employs technical means
   (threshold cryptography and "blinded" signatures), to facilitate that
   separation. (A blinded   signature is one in which the value being
   signed is not made visible to the signer, via cryptographic
   means. Additional details are provided later.)

   The AI has knowledge of the certificate issued to the user, but no
   knowledge of the user's real identity. The BI knows the user's real
   identity, but has no knowledge of the certificate issued to that user.
   Only if the AI and BI collaborate can they map the TAC issued to a
   user to the real identity of that user.



Park                  Expires November 22, 2009               [Page 4]

Internet-Draft     Traceable Anonymous Certificate            May 2009


2. General Overview

   This section defines the notion of a traceable anonymous
   certificate(briefly TAC or anonymous certificate in this document).
   It is distinguished from a conventional pseudonymous certificate
   [8, 9] in that a TAC containing a pseudonym in the Subject
   field will be conditionally traceable (as defined that it is not
   trivial to design a system that issues anonymous certificates,
   consistent with Internet PKI standards, when additional
   constraints are imposed, as illustrated by the following scenarios.

        - If a CA issues an anonymous certificate without verifying a
   true identity, it is untraceable, which provides inadequate
   recourse if the user to whom the certificate was issued abuses the
   anonymity it provides. (Even without the ability to trace an
   anonymous certificate to the corresponding user, the certificate
   can always be revoked, but this may not be a sufficient response
   to abuse.)

       - If a CA issues an anonymous certificate but verifies the
   real identity and maintains a record of that identity, the CA can
   link the pseudonym in the Subject field to the real identity, hence
   a potential "big brother" problem.

       - If the CA issues a certificate with a certificate containing
   a user-selected Subject name, and does not verify the user's
   identity, the certificate is effectively untraceable.

       - If CA issues an anonymous certificate using a blind signature
   (see below), the CA cannot verify the contents of the certificate,
   making the certificate untraceable and essentially forgeable.
   (If a CA signs a certificate without examining its content, even
   after verifying a user's identity, certificates issued by the CA
   are essentially forgeable.)

      To address the issues described above, we extend the simple
   separation-of-authority concept already defined in the RA/CA PKI
   model. First we restate the requirements in a more precise and
   concise fashion, and introduce a basic model for achieving the
   goals from a more general perspective.



3. Requirements

   This document describes a new separation-of-authority model and
   protocols for certificate issuance in a way that enables issuing


Park                  Expires November 22, 2009               [Page 5]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   traceable anonymous certificates, while maintaining compatibility
   with the standards used in existing PKIs. To do this, the
   following requirements must be satisfied.

       - The traceable anonymous certificate MUST be a syntactically
   valid X.509 certificate in which the Subject field contains a
   pseudonym.

      - There must be technical means to counter a claim by a
   malicious user who later denies having participated in the
   activities that resulted in issuing a TAC. Specifically, when a
   user is identified and requests issuance of a TAC, the mechanisms
   employed MUST ensure that the user to whom the TAC is issued is the
   one who requested the TAC (unless that user transfers the private
   key to another party, unknown to the RA/CA).

       - The traceability and revocation functions MUST support the
   linkage between a user's true identity and the pseudonym in a
   certificate issued to the user. Thus the solution MUST enable
   determining a true identity from the anonymous certificate, upon
   agreement among the authorities who collaborated to issue the
   certificate.



4. Traceable Anonymous Certificate Model

   A TAC is an EE certificate issued by a pair of entities that
   operate in a split responsibility mode: a Blind Issuer (BI) and
   an Anonymity Issuer (AI). The pair appear as a single CA to the
   outside world, e.g., they are represented by a single CA
   certificate. The public key in the CA certificate is used to verify
   certificates issued by this CA in the normal fashion,
   i.e., a relying party processes a TAC just like any other EE
   certificates.

   In this model the BI acts as a RA. It interacts with a user to
   verify the user's "real" identity, just like a normal RA.
   The BI maintains a database that can be used to map a TAC to the
   user to whom it was issued, but only with the cooperation of the
   AI.

   This mapping will be initiated only if there is evidence that the
   user to whom the TAC was issued has abused the anonymity provided
   by the TAC.




Park                  Expires November 22, 2009               [Page 6]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   The AI acts as a CA. It validates a certificate request submitted
   by the user, using a standard certificate request format such as
   PKCS10. The AI performs the functions common to a CA, including a
   private key proof of possession (PoP) check, a name uniqueness
   check among all certificates issued by it, assignment of a serial
   number, etc. To effect issuance of the TAC, the AI interacts with
   the BI, over a secure channel, to jointly create the signature on
   the TAC, and sends the signed TAC to the user.

   The AI does this without learning the user's real identity
   (either from the user or from the BI).

   The result of this split functionality between the BI and the AI
   is that neither can unilaterally act to reveal the real user
   identity. The AI has knowledge of the certificate issued to the
   user, but no knowledge of the user's real identity. The BI knows
   the user's real identity, but has no knowledge of the certificate
   issued to that user. Only if the AI and BI collaborate can they
   map the TAC issued to a user to the real identity of that user.

   This system is not perfect. For example, it assumes that the AI
   and BI collaborate to reveal a user's real identity only under
   appropriate circumstances. The details of the procedural security
   means by which this assurance is achieved are outside the scope of
   this document. Nonetheless, there are security benefits to adopting
   this model described in this document, based on the technical
   approach used to enable separation of the BI and AI functions.

   For example, the BI and AI can be operated by different
   organizations in geographically separate facilities, and managed
   by different staff. As a result, one can have higher confidence
   in the anonymity offered to a user by the system, as opposed to a
   monolithic CA operating model that relies only on procedural
   security controls to ensure anonymity.



5. Issuing a TAC

   The follow subsections describe the procedures and the protocols
   employed to issue a TAC. To begin, BI and AI collaborate to
   generate a public key pair (that represents the CA as seen by
   relying parties) using a threshold signature scheme. Such schemes
   have been defined for RSA. The details of how this is accomplished
   depend on the algorithm in question, and thus are not described here.
   The reader is referred to [17] where procedures for implementing RSA



Park                  Expires November 22, 2009               [Page 7]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   threshold signatures are described. A DSA-based threshold signature
   scheme will be incorporated into a future version of TAC [16].

   Note that this split signing model for certificate issuance is an
   especially simple case of a threshold signature; the private key
   used to sign a TAC is divided into exactly two shares, one held by
   the BI and one held by the AI. Both shares must be used, serially,
   to create a signature on a TAC. After the key pair for the (nominal)
   CA has been generated and the private key split between the BI and
   the AI, the public key is published, e.g., in a self-signed
   certificate that represents the TAC CA.

   Another public key cryptographic function that is an essential
   part of this system is called "blind signing". To create a blind
   signature one party encrypts a value to be signed, e.g., a hash
   value of a certificate, and passes it to the signer. The signer
   digitally signs the encrypted value, and returns it to the first
   party. The first party inverts the encryption it applied with the
   random value in the first place, to yield a signature on the
   underlying data, e.g., a hash value.

   This technique enables the    signer to digitally sign a message,
   without seeing the content of the message. This is the simplest
   approach to blind signing; it requires that the public key needed
   to invert the encryption not be available to the blind signer.
   Other blind signing techniques avoid the need for this restriction,
   but are more complex.

   The tricky part of a cryptographic blinding function is that is must
   be associative and commutative, with regard to a public key signature
   function. Let B be a blinding function, B-INV is its inverse, and S
   is a public key signature. The following relationship must hold:
   B-INV( S (B (X) ) ) = B-INV( B( S (X) ) ) = S (X). RSA can be use
   to blind a value    with random value and to sign a blinded value,
   because the modular exponentiation operation used by RSA for both
   signature and for encryption is associative and commutative.

   The TAC issuance process described below requires an ability for the
   BI, the AI, and the user to employ secure communication
   channels between one another.

   Use of TLS [19] is one suitable means to establish such channels,
   although other options also are acceptable. To this end, this
   document assumes TLS as the default secure communication channel,
   and thus requires that the BI and the AI have X.509 certificates
   that represent them.



Park                  Expires November 22, 2009               [Page 8]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   These certificates are independent of the certificate that
   represents the CA (formed by the BI and the AI) and may be either
   self-signed or issued by other CA(s).

   Appendix B provides a top level description of the application of
   TLS to these message exchanges.

5.1. Steps in issuing a TAC

   Figure 1. depicts the procedures for issuing a TAC. The lines
   represent steps in the issuance process, and the numbers refer to
   these steps.

                                        1     +---------------+

                                   +<-------->|    Blind      |

                                   |     2    |    Issuer (BI)|

                                   |          +---------------+

            +-------+              |                   ^

            | user  |<------------>|                 4 | 5

            +-------+              |                   v

                                   |    3     +----------------+

                                   +--------->|                |

                                   |          |    Anonymity   |

                                   |          |   Issuer (AI)  |

                                   +<-------- |                |

                                        6     +----------------+

                            Figure 1. TAC issuance Procedures

      Step 1 : A user authenticates himself to BI. This may be
   effected via an in-person meeting or electronically. The same
   sorts of procedures that RAs use for normal certificate issuance
   are used here. Such procedures are not standardized, and thus
   they are not described here in detail. For purposes of the TAC
   architecture, we require the BI to establish a record in a


Park                  Expires November 22, 2009               [Page 9]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   database for the user, and to generate a (locally) unique
   identifier, called the UserKey, that will serve as a (database)
   key for the record. The UserKey value MUST NOT be generated in an
   fashion that permits any external entity (including the AI) to
   infer a user's real identity from its value. (For example, is the
   user's name is used as an input to a one-way hash algorithm to
   generate the UserKey value, then additional random data must be
   used as an input to prevent simple guessing attacks.) Associated
   with the UserKey in this database is an expiration time. The
   expiration time is used by BI and the AI to reject session-level
   replay attacks in some exchanges, and to enable BI and AI to
   garbage collect database records if a user initiates but does not
   complete the certificate request process.

   It is RECOMMENDED that the UserKey be a random or pseudo-random
   value. Whenever the BI passes a UserKey to an external party, or
   accepts the UserKey from an external party (e.g., the AI), the
   value is embedded in digitally signed CMS object called a Token,
   accompanied by the time stamp noted above. The signature on a
   Token is generated by the BI. (Note that the certificate used is just
   a certificate suitable for use with CMS, and is NOT the split-key
   certificate used to verify TAC.)

   The following ASN.1 syntax represents the UserKey and an expiration
   time:

       UserKey ::= OCTET STRING
       Timeout ::= GeneralizedTime

      In the context of this specification, GeneralizedTime value MUST
   be expressed in Greenwich Mean Time (Zulu) and MUST include
   seconds(YYYYMMDDHHMMSSZ).



      Step 2 : BI presents to the user a data structure called a Token.
   The Token must be conveyed to the user via a secure channel, e.g.,
   in person or via a secure communication channel. The secure channel
   is required here to prevent a wiretapper from being able to acquire
   the Token. For example, if the user establishes a one-way
   authenticated TLS session to the BI in Step 1, this session could
   be used to pass the Token back to the user.

      The Token serves two purposes. During TAC issuance, the Token
   is used to verify that a request to the AI has been submitted by a
   user who is registered with the BI (and thus there is a record in
   BI's database with the real identity of the user). This is necessary


Park                  Expires November 22, 2009              [Page 10]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   to ensure that the TAC can later be traced to the user. If there is
   a request to reveal the real identity of a user, the AI will release
   the Token to the entity requesting that a TAC be traced, and that
   entity will pass the Token to the BI, to enable tracing the TAC.
   If the BI does not perform its part of the certificate issuance
   procedure (in Step 6) before the Token expires, the BI can delete
   the Token from the database as a means of garbage collection. The
   timeout value in a Token is selected by the BI.

      The Token is a ContentInfo with a contentType of id-kisa-tac-token
   and a content that hold a SignedData of CMS SignedData object [6],
   signed by the BI, where the eContent (EncapsulatedContentInfo) is a
   SEQUENCE consisting of the UserKey and Timeout and eContentType MUST
   be id-data.

   EncapsulatedContentInfo ::= SEQUENCE {
      eContentType ContentType, -- OBJECT IDENTIFIER : id-data
      eContent [0] EXPLICIT OCTET STRING OPTIONAL }
   -- DER encoded with the input of 'SEQUENCE of the UserKey and
   -- Timeout'

   id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
   rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   The signature (SignatureValue of SignerInfo) is generated using
   the BI's private signature key, corresponding to the public key
   present in the BI's certificate. (Note that this certificate is
   just a certificate suitable for use with TLS, and is NOT the split-
   key certificate used to verify a TAC.) The certificate(certificates)
   MUST be present. Appendix A provides the ASN.1 syntax for the Token,
   as a profiled CMS ContentInfo object. Appendix C provides the CMS
   SignedData object profile for wrapping the Token.

   Token ::= ContentInfo

   Upon receipt of the Token, the user SHOULD verify the signature
   using the BI public key and note the Timeout value to ensure that
   the certificate request process is completed prior to that time.



      Step 3 : The user prepares a certificate request in a standard
   format, e.g., PKCS10 [3] or CMC[4]. The Subject field of the
   certificate contains a pseudonym generated by the user. It is
   anticipated that the CA (BI + AI) may provide software for users
   to employ in constructing certificate requests.



Park                  Expires November 22, 2009              [Page 11]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   If so, then this software can generate a candidate Subject name
   to minimize the likelihood of a collision. If the user selects a
   candidate pseudonym without such support, the likelihood of a
   subject name collision probably will be greater, increasing the
   likelihood that the certificate request will be rejected or that
   the AI will have to generate a pseudonym for the user.

   After constructing the certificate request, the user sends it,
   along with the Token from Step 2, to the AI, via a secure channel.
   This channel MUST be encrypted and one-way authenticated, i.e.,
   the user MUST be able to verify that it is communicating with the
   AI, but the AI MUST NOT be able to verify the real identity of the
   user. Typical use of TLS for secure web site access satisfies this
   requirement. The certificate request of PKCS10 [3] or CMC[4] carries
   the Token from Step 2.

   The Token is carried as an attribute in a certificate request
   (CertificationRequestInfo.attributes) where the attrType MUST be
   id-kisa-tac below in PKCS10 format. The Token is set to
   attrValues(Certificate Request Controls) where the attrType MUST be
   id-kisa-tac in CMC[4] format. The TAC request message profile is
   described in the section 5.3.



      Step 4 : The AI, upon receipt of the certificate request
   containing a Token, verifies that the request is consistent with
   the processing defined for the request format (PKCS10).
   If a Subject name is present, it verifies that the proposed
   pseudonym is unique. The AI also verifies the signature on the
   Token and, if it is valid, checks the Timeout value to reject a
   replay attack based on an "timed-out" Token.

   A Token with an old Timeout value is rejected out-of-hand by the
   AI. (After a Token's Timeout time is reached, the AI deletes Token
   from its cache.) Next, the AI compares the received Token against
   a cache of recent (i.e., not "timed out"), validated Tokens. The AI
   matches the resubmitted request to the original request, and responds
   accordingly. For example, if a duplicate is detected, the certificate
   request can be rejected as a replay.

   If the Subject field contains a Subject name already issued by the
   AI, the AI MUST either reject the certificate request, or
   substitute a pseudonym it generates, depending on the policy of
   the TAC CA. If the certificate request is acceptable, the AI
   assigns a serial number and constructs a tbsCertificate (i.e.,
   the final form of the certificate payload, ready to be signed).


Park                  Expires November 22, 2009              [Page 12]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   The AI then computes a hash over this data structure and blinds
   the hash value. (The AI blinds the hash value using a key from a
   public-key encryption pair where neither key is ever made public.
   The other key from this pair is used by the AI in Step 6 to "un-
   blind" the signed hash value.)

   The AI sends the CMS ContentInfo object of TokenandBlindHash to the
   BI, via a two-way authenticated and encrypted channel.
   The two-way authentication and encryption is required to ensure
   that the AI is sending these values to the BI, to allow the BI to
   verify that the values were transmitted by the AI, and to prevent
   a wiretapper from acquiring the Token. A TLS session in which
   both parties employ certificates to authenticate one another is
   the RECOMMENDED way to achieve this communication.

   The TokenandBlindHash is a CMS ContentInfo with a contentType of id-
   kisa-tac-tokenandblindhash and a content that hold a SignedData of
   CMS SignedData object [6], signed by the AI, where the eContent
   (EncapsulatedContentInfo) is a SEQUENCE consisting of the Token and
   BlindedCertificateHash, and eContentType MUST be id-data.

   EncapsulatedContentInfo ::= SEQUENCE {
      eContentType ContentType, -- OBJECT IDENTIFIER : id-data
      eContent [0] EXPLICIT OCTET STRING OPTIONAL }
   -- DER encoded with the input of 'SEQUENCE of the Token and
   -- BlindedCertificateHash'

   The signature (SignatureValue of SignerInfo) is generated using
   the AI's private signature key, corresponding to the public key
   present in the AI's certificate. (Note that this certificate is
   just a certificate suitable for use with TLS, and is NOT the split-
   key certificate used to issue a TAC.) The certificate(certificates)
   MUST be present.

   The following ASN.1 syntax represents the Token and
   BlindedCertificateHash :

       Token ::= ContentInfo
       BlinedCertificateHash ::= OCTET STRING

   Token is the value of ContentInfo in the certificate request message
   (CertificationRequestInfo.attributes) from the Step 3.

   BlindedCertificateHash is the blinded hash value for the
   tbsCertificate.




Park                  Expires November 22, 2009              [Page 13]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   Appendix A provides the ASN.1 syntax for the Token, as a profiled CMS
   ContentInfo object. Appendix C provides the CMS SignedData object
   profile for wrapping the Token.

      TokenandBlindHash ::= ContentInfo



      Step 5 : The BI receives the Token and blinded certificate
   hash via the secure channel described above. First the BI verifies
   the signature on the TokenandBlindHash generated by AI and then
   verifies the signature on the Token to ensure that it is a
   legitimate Token generated by the BI. Next, the BI checks its
   database to ensure that the UserKey value from the Token is present
   and that the Token has not been used to authorized issuance of a
   certificate previously.

   This check is performed to ensure that the BI has authenticated the
   user and entered the user's real identity into the BI's database.
   Each Token authorizes issuance of only one certificate, so the
   check also ensures that the same Token is not used to authorized
   issuance of more than one certificate. These checks ensure that
   the certificate issued by the AI to this user will be traceable,
   if needed.

   The BI uses its share of the threshold private
   signature key to sign the blinded certificate hash and returns
   the CMS SignedData back to AI, where it has the 'SEQUENCE of Token
   and PartiallySignedCertificateHash' in SignedData.eContent field.

   The following ASN.1 syntax represents the Token and
   PartiallySignedCertificateHash :

       Token ::= ContentInfo
       PartiallySignedCertificateHash ::= OCTET STRING

   Token is the token value of the TokenandBlindHash(eContent in which
   'SEQUENCE consisting of the both Token and
   PartiallySignedCertificateHash') from the Step 4.

   PartiallySignedCertificateHash is the signature value generated by
   BI's share of the threshold private signature key on
   BlindedCertificateHash from the Step 4.

   The TokenandPartiallySignedCertificateHash is a CMS ContentInfo with
   a contentType of id-kisa-tac-tokenandpartially and a content that
   hold a SignedData of CMS SignedData object [6], signed by the BI,


Park                  Expires November 22, 2009              [Page 14]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   where the eContent(EncapsulatedContentInfo) is a SEQUENCE consisting
   of the Token and PartiallySignedCertificateHash, and eContentType
   MUST be id-data.

   EncapsulatedContentInfo ::= SEQUENCE {
      eContentType ContentType, -- OBJECT IDENTIFIER : id-data
      eContent [0] EXPLICIT OCTET STRING OPTIONAL }
   -- DER encoded with the input of 'SEQUENCE of the Token and
   -- PartiallySignedCertificateHash'

   The signature (SignatureValue of SignerInfo) is generated using
   the BI's private signature key, corresponding to the public key
   present in the BI's certificate. (Note that this certificate is
   just a certificate suitable for use with TLS, and is NOT the split-
   key certificate used to issue a TAC.) The certificate(certificates)
   MUST be present. Appendix A provides the ASN.1 syntax for the Token,
   as a profiled CMS SignedData object. Appendix C provides the CMS
   SignedData object profile for wrapping the Token.

      TokenandPartiallySignedCertificateHash ::= ContentInfo



    Step 6 : Upon receipt of the TokenandPartiallySignedCertificateHash,
   the AI verifies the signature on the PartiallySignedCertificateHash,
   generated by BI and then matches the Token against its list of
   outstanding requests to the BI. The AI then "un-blinds" the
   blindHashValue, using the other key from the key pair employed Step 4.
   This reveals the partially-signed certificate hash. The AI then
   applies its part of the split private key to complete the signature
   of the certificate for the user.

   It records the certificate and the Token value in its database, to
   enable later tracing of the certificate to the real user identity,
   if needed. The AI transmits the completed certificate to the user,
   via the response message from the request protocol employed by the
   user in Step 3, PKCS10.

   The user may now employ the certificate with any PKI-enabled
   application or protocol that makes use of X.509 certificates
   (consistent with the key usage, and EKU values in the certificate).
   Note that the user should be prepared to accommodate delays in the
   certificate issuance process. For example, a connection between the
   user and the AI might fail sometime after the user submits a
   certificate request at the end of Step 3 and before the AI returns
   the certificate at the end of Step 6. If this happens, the user
   should resubmit the request. The AI and BI retain sufficient state


Park                  Expires November 22, 2009              [Page 15]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   to be able to match the resubmitted request to the original request,
   and respond accordingly. If the process failed in steps 5 or 6, the
   AI returns an error indication to the user.



5.2. Mapping a TAC to a User's Real Identity

   If a user to whom a TAC has been issued abuses the anonymity
   provided by the TAC, the TAC can be traced to the identity of that
   user. Mapping a TAC to a user's real identity is a four step
   process, described below and illustrated in Figure 2.



                                        C    +---------------+

                                  +<-------->|    Blind      |

                                  |     D    |    Issuer (BI)|

                                  |          +---------------+

           +---------+            |

           | Relying |<---------->|

           | Party   |            |

           +---------+            |

                                  |    A     +----------------+

                                  +<-------->|    Anonymity   |

                                       B     |   Issuer (AI)  |

                                             +----------------+

                 Figure 2. Revealing a TAC User's Real Identity

       Step A: The AI verifies the assertion by an aggrieved party
   that a TAC user has abused the anonymity provided by his TAC.
   The procedures used by AI to verify that such abuse has occurred
   are outside the scope of this document. No protocol is defined
   here for the interaction between the aggrieved party and AI.
   The only technical requirement is that the TAC of the offending


Park                  Expires November 22, 2009              [Page 16]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   user be provided to the AI. If AI determines that there is
   sufficient evidence of abuse to trace the TAC to the user, the AI
   revokes the TAC, by listing its serial number on the next CRL
   issued by the AI.

   An AI unilaterally manages the CRL for a TAC. Because RFC 5280
   implementations are not required to process indirect CRLs,
   we create a second certificate for the CA, under the TAC CA. Revoked
   EE certificates issued by the TAC CA are recorded on this CRL and
   validated using this second CA certificate.

   This CA certificate will have the cRLSign bit set in KeyUsage
   extension, but not the keyCertSign bit. The private key for this
   certificate will be held by the AI, so that it can issue CRLs
   unilaterally.

   The Subject DN will be the same in both CA certificates, which
   reinforces the notion that the CRL issuer is the same entity as the
   TAC issuer, and that this CRL is not an indirect CRL. Because the
   CRL issuer does not issue any certificates itself, there is no
   possible serial number conflict. This will be the only CA
   certificate issued under the TAC CA certificate (and thus it will
   be signed jointly by the BI and AI). We recommend that the CRL for
   this CA certificate be similarly long-lived, as it too needs to be
   signed by the BI and AI. Each EE TAC certificate MUST contain a
   CRLDP that points to the CRL issued by this CA, to ensure that RPs
   know to check this CRL vs. the CRL that covers only the CRL CA.
   (If the AI uses OCSP [15] to convey the revocation status of TACs, an
   equivalent procedure is employed.) If it is later determined that the
   revocation was not warranted, a new TAC can be issued, to preserve
   the anonymity of the user in future transactions.



      Step B: The AI searches its database, e.g., based on the serial
   number in the TAC, to locate the Token that was passed between
   the AI and BI during the issuance process (Steps 5 and 6 above).
   The AI passes this Token to the aggrieved party via an encrypted
   and two-way authenticated channel. Encryption is required to
   prevent disclosure of the Token, and two-way authentication is
   required to ensure that the aggrieved party and the AI know that
   they are communicating with each other. Two-way authenticated TLS
   is the RECOMMENDED means of implementing this channel, though
   other approaches are allowed.





Park                  Expires November 22, 2009              [Page 17]

Internet-Draft     Traceable Anonymous Certificate            May 2009


      Step C and D : The aggrieved party transits the Token to the BI,
   via an encrypted and two-way authenticated channel. The channel
   MUST be encrypted to prevent disclosure of the Token, and two-way
   authentication is required to ensure that the aggrieved party and
   the BI know that they are communicating with each other.
   If specified by the CP for the TAC CA, the BI will independently
   determine that there is sufficient evidence of abuse to trace the
   TAC to the user, before proceeding. The BI verifies its signature
   on the Token, to verify that this is a Token generated by it and
   presumably released to the aggrieved party by the AI. Next the BI
   searches its database using the UserKey value extracted from the
   Token. The BI retrieves the    user's real identity and provides it
   to the aggrieved party. (By requiring the aggrieved party to
   interact with both the AI and the BI, the BI can verify that it is
   dealing with an aggrieved party, not with the AI acting
   unilaterally.)



5.3. TAC Request Message Format Profile

   TAC request MAY use either of PKCS10 or CMC.  An AI MUST support
   PKCS10 and MAY support CMC.

5.3.1. PKCS10 Profile

   This profile refines the specification in PKCS10 [3], as it relates
   to TAC. A Certificate Request Message object, formatted according to
   PKCS10, is passed to the AI.

   This profile applies the following additional constraints to fields
   that may appear in a CertificationRequestInfo:

       Version
          This field is mandatory and MUST have the value 0.

       Subject

         This field MUST be present. If the value of this field is empty,
     AI will generate a subject name that is unique in the context of
     certificates issued by this issuer. If the Subject
     field contains a Subject name already issued by the AI, the AI
     MUST either reject the certificate request, or substitute a
     pseudonym it generates, depending on the policy of the TAC CA.





Park                  Expires November 22, 2009              [Page 18]

Internet-Draft     Traceable Anonymous Certificate            May 2009


       SubjectPublicKeyInfo
        This field specifies the subject's public key and the
   algorithm with which the key is used.

       Attributes
        PKCS10[3] defines the attributes field as key-value pairs
   where the key is an OID and the value's structure depends on the
   key. The attribute field MUST include id-kisa-tac attribute, which
   holds the Token and is defined below. The Attributes field MAY also
   contain X509v3 Certificate Extensions and any PKCS9 [7]
   extensionRequest attributes that the subscriber would like to have
   included in the certificate. The profile for extensions in
   certificate requests is specified in the RFC5280 [2].



5.3.2. CMC Profile

   This profile refines the Certificate Request messages in Certificate
   Management over CMS in CMC [4], as it relates to TACs.

   A Certificate Request messages, formatted according to the
   CMC[4], is passed to the AI .

   With the exception of the public key related fields, the CA is
   permitted to alter any requested field when issuing a corresponding
   certificate.

   This profile recommends the full PKI Request of the two types of PKI
   requests (Simple or Full PKI Request) and the PKI Request SHOULD be
   encapsulated in SignedData with an encapsulated content type of id-
   cct-PKIData.

   This profile applies the following additional constraints to fields
   that may appear in a Certificate Request Template of CRMF[5]:

       Version
          This field MAY be absent, or MAY specify the request of a
   Version 3 Certificate.  It SHOULD be omitted.

       SerialNumber
          As per CRMF [5], this field is assigned by the CA and MUST
   be omitted in this profile.

       SigningAlgorithm
          As per CRMF [5], this field is assigned by the CA and MUST
   be omitted in this profile.


Park                  Expires November 22, 2009              [Page 19]

Internet-Draft     Traceable Anonymous Certificate            May 2009


       Issuer
          This field is assigned by the CA and MUST be omitted in
   this profile.

       Validity
          This field MAY be omitted.  If omitted, the AI will issue
   a Certificate with Validity dates as determined by the TAC CA
   policy. If specified, then the CA MAY override the requested
   values with dates as determined by the TAC CA policy.

       Subject
          This field MUST be present.  If the value of this
   field is empty, in which case the AI MUST generate a
   subject name that is unique in the context of certificates issued
   by this issuer. If the Subject field contains a Subject name
   already issued by the AI, the AI MUST either reject the certificate
   request, or substitute a pseudonym it generates, depending on the
   policy of the TAC CA.

       PublicKey
          This field MUST be present.



   This profile also refines constraints that may appear in a
   Certificate Request controls:

   The Token is set to attrValues (CertRequest.controls) where the
   attrType MUST be id-kisa-tac.

   This profile also refines constraints that may appear in a
   Certificate Request controls : The Token is set to attrValues where
   the attrType MUST be id-kisa-tac.

   The Certification Request Formats based on PKCS10 can be referred to
   5.3.1 PKCS10 Profile.



6. Security Considerations

   The anonymity provided by the architecture and protocols defined
   in this document is conditional. Moreover, if the user employs
   the same TAC for multiple transactions (with the same or different
   parties), the transactions can be linked through the use of the
   same TAC. Thus the anonymity guarantee is "weak" even though the
   user's real identity is still hidden.


Park                  Expires November 22, 2009              [Page 20]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   To achieve stronger anonymity, a user may acquire multiple TACs,
   through distinct iterations of the protocol. Since each TAC is
   generated independently, it should not be possible for a relying
   party to discover a link between pseudonyms unless the tracing
   feature of this scheme is invoked. If the TAC has a long validity
   interval, this increases the probability that the identity of a
   TAC user will be discovered, e.g., as a result of linking user
   transactions across multiple servers. Thus we recommend that each
   TAC CA consider carefully how long the validity for a TAC
   certificate should be. In the course of issuing a TAC, the AI and the
   user interact directly. Thus the AI may have access to lower layer
   information (e.g., an IP address) that might reveal the user's
   identity. A user concerned about this sort of possible identity
   compromise should use appropriate measures to conceal such
   information, e.g., a network anonymity service such as Tor [insert an
   informative reference to Tor].

   This document makes no provisions for certificate renewal or rekey;
   we recommend TAC users acquire new TACs periodically, to further
   reduce the likelihood of linkage. It also may be possible to
   determine the identity of a user via information carried by lower
   level protocols, or by other, application-specific means.
   For example, the IP address of the user might be used to identify
   him/her. For this reason, we recommend that a TAC be used primarily
   to access web services with anonymity. Note that the TAC
   architecture described in this document is not capable of using
   certificates for use with SMIME, because there is no provision to
   issue two certificates (one for    encryption and one for
   signatures) that contain the same (anonymous) Subject name.
   An analogous problem might arise if a user visits a site (and
   does not conceal his/her identity), the site deposits a "cookie"
   into the user's browser cache, and the user later visits a site and
   employs a TAC with the presumption of anonymity.

   The use of a TAC is a tool to help a user preserve anonymity,
   but it is not, per se, a guarantee of anonymity. We recommend that
   each TAC CA issue certificates with only one lifetime, in order to
   avoid the complexity that might arise otherwise. If a TAC CA
   offered certificates with different lifetimes, then it would need
   to communicate this information from the BI to AI in a way that
   does not unduly compromise the anonymity of the user.

   This architecture uses the UserKey to link a TAC to the
   corresponding real user identity. The UserKey is generated in a
   fashion to ensure that it cannot be examined to determine a
   user's real identity. UserKey values are maintained in two
   distinct databases: the BI database maps a UserKey to a real user


Park                  Expires November 22, 2009              [Page 21]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   identity, and the AI database maps a TAC to a UserKey. The UserKey
   is always carried in a signed data object, a Token. The Token is
   signed to allow the BI to verify its authenticity, to  prevent
   attacks based on guessing UserKey values. The Token also carries a
   Timeout value to allow the AI and BI to reject session-level
   replay attacks, and to facilitate garbage collection of Ai and BI
   databases.

   Threshold cryptography is employed to enable strong separation of
   the BI and AI functions, and to ensure that both must cooperate to
   issue certificates under the aegis of a TAC CA. (The AI and BI must
   ensure that the threshold cryptographic scheme they employ does not
   provide an advantage to either party based on the way the key
   splitting is effected.) Blind signatures are used with threshold
   cryptography to preserve the separation of functions, i.e.,
   to prevent the BI from learning the hash value of the TAC issued
   by the AI.

   Message exchanges between a user and the BI or the AI, between the
   AI and BI, and between an aggrieved party and the AI and BI all make
   use of secure channels. These channels are encrypted to prevent
   disclosure of the Token value and of the pseudonym in the TAC
   request and response and in a tracing request. The channels are
   two-way authenticated to allow the AI and BI to verify their
   respective identities when communication with one another, and
   one-way authenticated to allow the user to verify their
   identities when he communicates with them. Two-way authentication
   is employed for communication between an aggrieved party and the
   AI and BI, to allow all parties to verify the identity of one
   another.

   There is an opportunity for the AI to return the wrong UserKey to
   an aggrieved party, which will result in tracing a certificate to
    the wrong real user identity. This appears to be unavoidable in
   any scheme of this sort, since the database maintained by the BI
   is intentionally ignorant of any info relating a UserKey to a TAC.

   A TAC CA MUST describe in its CP how long it will retain the data
   about certificates it issued, beyond the lifetime of these
   certificates. This will help a prospective TAC subject gauge the
   likelihood of unauthorized of his/her identity as a result of a
   compromise of this retained data. It also alerts relying parties
   of the timeframe (after expiration of a certificate) in which an
   alleged abuse must be brought to the attention of the AI and BI,
   before the data linking a cert to the real user identity is
   destroyed.



Park                  Expires November 22, 2009              [Page 22]

Internet-Draft     Traceable Anonymous Certificate            May 2009


7. IANA Considerations

   This document does not require any IANA registration.

8. Acknowledgments

   Tim Polk (NIST), Stefan Santesson(ACC-sec.com), Jim Schaad (Soaring
   Hawk), David A. Cooper (NIST), SeokLae Lee, JongHyun Baek, SoonTae
   Park (KISA), Taekyoung Kwon (Sejong Univ.), JungHee Cheon (Seoul
   National Univ.), and YongDae Kim Minnesota Univ.) have significantly
   contributed to work on the concept of TAC and identified security
   issues. Their comments enhanced the maturity of the document.



9. References

9.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [2]  D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley,
   W. Polk, "Internet X.509 Public Key Infrastructure
   Certificate and Certificate Revocation List (CRL) Profile,"
   RFC 5280, May 2008.

   [3]  M. Nystrom, B Kaliski "PKCS10 : Certificate Request Syntax
   Specification version 1.7", RFC 2986, November 2000.

   [4] J. Schaad, M. Myers, M. Nystrom, B Kaliski "Certificate
   Management over CMS (CMC)", RFC 5272, June  2008.

   [5] J. Schadd, "Internet X.509 Public Key Infrastructure
   Certificate Request Message Format(CRMF)", RFC 4211,September 2005.

   [6]  R. Hously, "Cryptographic Message Syntax(CMS)", RFC 3852, July
   2004.

   [7] M. Nystrom, B. Kaliski, "PKCS #9: Selected Object Classes and
   Attribute Types Version 2.0", RFC 2985, November 2000

9.2. Informative References

   [8]  S. Brands, Rethinking public key infrastructures and digital
   certificates - Building in Privacy, PHD thesis, Eindhoven
   Institute of Technology, Eindhoven, The Netherlands, 1999.


Park                  Expires November 22, 2009              [Page 23]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   [9]  D. Chaum, "Blind signature system," CRYPTO '83, Plenum
   Press, page 153, 1984.

   [10]  J. Graaf and O. Carvalho, "Reflecting on X.509 and LDAP, or
   How separating identity and attributes could simplify a PKI"
   WSEG 2004, pp. 37-48.

   [11]  R. Grimm and P. Aichroth, "Privacy Protection for Signed
   Media Files: A Separation-of-Duty Approach to the Lightweight
   DRM (LWDRM) System," ACM MM&Sec'04, pp. 93-99, 2004

   [12] R. Rivest, A. Shamir, and L. Adleman, "A method for
   obtaining digital signature and public-key cryptosystems,"
   Communications of the ACM, vol. 21, no. 2, pp.120-126, 1978.

   [13] X.509, "Information technology - Open Systems
   Interconnection - The Directory: Public-key and attribute
   certificate frameworks," ITU-T Recommendation X.509, March
   2000. Also avaiable at ISO/IEC 9594-8, 2001.

   [14] S. Rafaeli, M. Rennhard, L. Mathy, B. Plattner, and D.
   Hutchison, "An Architecture for Pseudonymous e-Commerce,"
   AISB'01 Symposium on Information Agents for Electronic
   Commerce, pp. 33-41, 2001.

   [15] M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams,
   "X.509 Internet Public Key Infrastructure Online Certificate
   Status Protocol - OCSP", June 1999.

   [16] Philip MacKenzie and Michael K. Reiter, "Two-Party Generation
   of DSA Signature", Crypto 2001.

   [17] Shaohua Tang, "Simple Threshold RSA Signature Scheme Based on
   Simple Secret Sharing", 2005

   [18] Taekyoung Kwon, Jung Hee Cheon, Yongdae Kim, Jae-Il Lee,
   "Privacy Protection in PKIs : A Separation of Authority
   Approach", 2007

   [19] T. Dierks, "The Transport Layer Security (TLS) Protocol Version
   1.2", 2008

   [20] B.Ramsdell, "S/MIME verson 3 Message Specification", 1999






Park                  Expires November 22, 2009              [Page 24]

Internet-Draft     Traceable Anonymous Certificate            May 2009


APPENDIX A: Traceable Anonymous Certificate ASN.1 Modules



   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN

      -- EXPORTS All
      -- The types and values defined in this module are exported for
      -- use in the other ASN.1 modules.  Other applications may use
      -- them for their own purposes.

      IMPORTS

      -- Imports from RFC 3280 [PROFILE], Appendix A.1
                 AlgorithmIdentifier, Certificate, CertificateList,
                 CertificateSerialNumber, Name FROM PKIX1Explicit88
                      { iso(1) identified-organization(3) dod(6)
                        internet(1) security(5) mechanisms(5) pkix(7)
                         mod(0) pkix1-explicit(18) }

      -- Imports from CMS
               ContentInfo, SignedData FROM
               CryptographicMessageSyntax2004{ iso(1)
               member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
               smime(16) modules(0) cms-2004(24)}

   UserKey ::= OCTET STRING

   Timeout ::= GeneralizedTime

   BlinedCertificateHash ::= OCTET STRING

   PartiallySignedCertificateHash ::= OCTET STRING

   EncapsulatedContentInfo ::= SEQUENCE {
          eContentType ContentType, -- OBJECT IDENTIFIER : id-data
          eContent [0] EXPLICIT OCTET STRING OPTIONAL }


   id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
   rsadsi(113549) pkcs(1) pkcs7(7) 1 }



   Token ::= ContentInfo


Park                  Expires November 22, 2009              [Page 25]

Internet-Draft     Traceable Anonymous Certificate            May 2009


   TokenandBlindHash ::= ContentInfo

   TokenandPartiallySignedCertificateHash ::= ContentInfo

   id-KISA OBJECT IDENTIFIER ::= {iso(1) member-body(2) korea(410)
   kisa(200004)}

   id-npki OBJECT IDENTIFIER ::= {id-KISA 10}

   id-attribute OBJECT IDENTIFIER ::= {id-npki 1}

   id-kisa-tac OBJECT IDENTIFIER ::= {id-attribute 1}

   id-kisa-tac-token OBJECT IDENTIFIER ::= { id-kisa-tac 1}

   id-kisa-tac-tokenandblindbash OBJECT IDENTIFIER ::= { id-kisa-tac 2}

   id-kisa-tac-tokenandpartially OBJECT IDENTIFIER ::= { id-kisa-tac 3}



   END


























Park                  Expires November 22, 2009              [Page 26]

Internet-Draft     Traceable Anonymous Certificate            May 2009


APPENDIX B: TAC message exchanges over Transport Layer Security

   TAC message exchanges between a user and the BI or the AI, between
   the AI and BI, and between an aggrieved party and the AI and BI
   all make use of secure channels to prevent disclosure of the Token
   value and of the pseudonym in the TAC request and response and in a
   tracing request. The Transport Layer Security Protocol v1.2 [19]
   (TLS) is a suitable security protocol to protect these message
   exchanges and this document recommends use of TLS to protect these
   exchanges. The following text describes how the handshake part of TLS
   should be employed to protect each type of exchange. Note that no
   specific cipher suites are specified for use here; the choice of
   suites is up to the client and servers, as is commonly the case.



B.1. Message exchanges between a User and the BI or the AI

   The channels between a User and the BI or the AI are one-way
   authenticated to allow the user to verify their identities when he
   communicates with them.

            User                        BI or AI

         ClientHello     -------->

                                        ServerHello
                                        Certificate
                         <--------      ServerHelloDone
   ClientKeyExchange
   [ChangeCipherSpec]
             Finished    -------->
                                        [ChangeCipherSpec]
                         <---------        Finished
          TAC Message    <--------->     TAC Message

   Figure 3. TAC Message exchanges between a User and the BI or the AI



B.2. Message exchanges between the BI and the AI

   The channels between the BI and the AI are two-way authenticated to
   allow the AI and BI to verify their respective identities when
   communication with one another.




Park                  Expires November 22, 2009              [Page 27]

Internet-Draft     Traceable Anonymous Certificate            May 2009


             BI                            AI

         ClientHello     -------->
                                        ServerHello
          Certificate
   CertificateRequest
                         <--------      ServerHelloDone
   Certificate
   ClientKeyExchange
   CertificateVerify
   [ChangeCipherSpec]
             Finished        -------->
                                          [ChangeCipherSpec]
                            <---------        Finished
          TAC Message       <--------->     TAC Message

       Figure 4. TAC Message exchanges between BI and AI



B.3. Message exchanges between the aggrieved party and the AI and or
the BI

   The channels between a User and the BI or the AI are two-way
   authenticated, to allow both parties to verify the identity of one
   another.

           User                        BI or AI

         ClientHello     -------->
                                        ServerHello
          Certificate
   CertificateRequest
                         <--------      ServerHelloDone
   Certificate
   ClientKeyExchange
   CertificateVerify
   [ChangeCipherSpec]
             Finished        -------->
                                          [ChangeCipherSpec]
                            <---------        Finished
          TAC Message       <--------->     TAC Message

    Figure 5. TAC Message exchanges between a aggrieved party and the
   BI or the AI




Park                  Expires November 22, 2009              [Page 28]

Internet-Draft     Traceable Anonymous Certificate            May 2009


APPENDIX C: Cryptographic Message Syntax Profile for TAC Token.

   Using the Cryptographic Message Syntax(CMS)[6], TAC Token is a type
   of signed-data object. The general format of a CMS object is :

   ContentInfo ::= SEQUENCE {
              contentType ContentType,
              content [0] EXPLICIT ANY DEFINED BY contentType }

            ContentType ::= OBJECT IDENTIFIER

   As a TAC is a signed-data object, it uses the corresponding OID,
   1.2.840.113549.1.1.2.



C.1. Signed-Data Content Type

   According to the CMS specification, the signed-data content type
   shall have ASN.1 type SignedData:

      SignedData ::= SEQUENCE {
              version CMSVersion,
              digestAlgorithms DigestAlgorithmIdentifiers,
              encapContentInfo EncapsulatedContentInfo,
              certificates [0] IMPLICIT CertificateSet OPTIONAL,
              crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
              signerInfos SignerInfos }

      DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

      SignerInfos ::= SET OF SignerInfo

      The elements of the signed-data content type are as follows:

           Version
               The version is the syntax version number. It MUST be 3,
   corresponding to the signerInfo structure having version number 3.

           digestAlgorithms
               This field specifies digest Algorithms.

           encapContentInfo
               This element is defined in Appendix C.1.1.





Park                  Expires November 22, 2009              [Page 29]

Internet-Draft     Traceable Anonymous Certificate            May 2009


          certificates
               The certificates element MUST be included and MUST
   contain only the single PKI EE certificate needed to validate this
   CMS Object.  The CertificateSet type is defined in section 10 of
   RFC3852 [6].

         crls
               The crls element MUST be omitted.

         signerInfos
               This element is defined in Appendix C.1.2.



C.1.1. encapContentInfo

   encapContentInfo is the signed content, consisting of a content type
   identifier and the content itself.

            EncapsulatedContentInfo ::= SEQUENCE{
                eContentType ContentType,
                 eContent [0] EXPLICIT OCTET STRING OPTIONAL }

            ContentType ::= OBJECT IDENTIFIER

       The elements of this signed content type are as follows:

           eContentType
               The ContentType for an TAC Token is id-data and has the
   numerical value of 1.2.840.113549.1.7.1.

           eContent
               The content of an TAC Token is the DER encoded with the
   input of 'SEQUENCE of UserKey and Timeout'.



C.1.2. signerInfos

   SignerInfo is defined under CMS as:

         SignerInfo ::= SEQUENCE {
              version CMSVersion,
              sid SignerIdentifier,
              digestAlgorithm DigestAlgorithmIdentifier,
              signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
              signatureAlgorithm SignatureAlgorithmIdentifier,


Park                  Expires November 22, 2009              [Page 30]

Internet-Draft     Traceable Anonymous Certificate            May 2009


              signature SignatureValue,
              unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

       The content of the SignerInfo element are as follows:

           Version
               The version number MUST be 3, corresponding with the
   choice of SubjectKeyIdentifier for the sid.

            Sid
               The sid is defined as:

                   SignerIdentifier ::= CHOICE {
                   issuerAndSerialNumber IssuerAndSerialNumber,
                   subjectKeyIdentifier [0] SubjectKeyIdentifier }
               For a TAC Token, the sid MUST be a SubjectKeyIdentifier.

           digestAlgorithm
                This field specifies digest Algorithms.

           signedAttrs
                The signedAttr element MUST be omitted.

           SignatureAlgorithm
                This field specifies the signature Algorithm.

            Signature
               The signature value is defined as:

                SignatureValue ::= OCTET STRING

               The signature characteristics are defined by the digest
and signature algorithms.

           UnsignedAttrs
                unsignedAttrs MUST be omitted.













Park                  Expires November 22, 2009              [Page 31]

Internet-Draft     Traceable Anonymous Certificate            May 2009




Author's Addresses

   SangHwan Park
   Korea Information Security Agency
   78, Garak-Dong, Songpa-Gu, Seoul, Korea
   Email: shpark@kisa.or.kr

   Haeryong Park
   Korea Information Security Agency
   78, Garak-Dong, Songpa-Gu, Seoul, Korea
   Email: hrpark@kisa.or.kr

   YooJae Won
   Korea Information Security Agency
   78, Garak-Dong, Songpa-Gu, Seoul, Korea
   Email: yjwon@kisa.or.kr

   JaeIl Lee
   Korea Information Security Agency
   78, Garak-Dong, Songpa-Gu, Seoul, Korea
   Email: jilee@kisa.or.kr

   Stephen Kent
   BBN Technologies
   10 Moulton Street Cambridge, MA 02138
   Email: kent@bbn.com




















Park                  Expires November 22, 2009              [Page 32]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/