Subject: Re: I-D ACTION:draft-ietf-pkix-tac-02.txt

From: "David A. Cooper" <[email-masked]>
Date: Mon, 05 Jan 2009 11:49:04 -0500

All,

I read through the "Traceable Anonymous Certificate" draft and wrote up 
some comments with the respect to what I consider to be the most 
significant issues in this document.  My comments are below.

Dave
------------------------------------------------------------------
Section 1 (Introduction):

 - The final paragraph begins:

      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 enforce that separation.

   The threshold cryptography and "blinded" signatures do not
   enforce separation, as they actually require the RA and CA roles
   to work more closely together than if these techniques were not
   used.  The use of the Token provides a technical means to
   *permit* the separation of the RA and CA roles, but does not
   enforce it.  The TAC protocol cannot prevent the RA and CA from
   sharing identity information (either by exchanging the
   information in non-TAC messages or by the RA encoding the user's
   identity in the UserKey of the Token.  A more appropriate
   statement would be:

      The conditional traceability offered by this model assumes
      strong separation between the RA and CA roles, and employs
      technical means to facilitate that separation.

Section 3 (Requirements):

 - This section begins by stating that the "document describes a
   new separation-of-authority model".  How does the model in this
   document differ from the one in [13], "An Architecture for
   Pseudonymous e-Commerce"?  What properties does the protocol
   in this document have that the protocol in [13] does not?

 - The document explains the need to be able to learn the true
   identity of the holder of a TAC, but not the need to learn
   a user's pseudonym given the user's true identity, yet this
   section states that the solution must enable determining the
   TAC from the true identity?  Why is this a requirement?  What
   protocol messages support this capability?

Section 5 (Issuing a TAC):

 - The protocol involves a complicated scheme involving split
   signatures and blind signatures.  The use of split signatures
   complicates the issuance of both certificates and CRLs, yet
   the need for this scheme is not clear.  It was previously
   argued that the split signature scheme prevents the CA from
   issuing a certificate to a user by itself, which could
   result in a non-traceable certificate.  However, the CA
   could still create a non-traceable certificate by simply
   not maintaining the link between the TAC and the Token.
   An untrustworthy CA could even use a Token issued by the BI
   to one user as the basis for issuing a certificate to a
   different user.  Similarly, a BI could issue a Token to a
   user without first identifying that user.  Since both the AI
   and BI need to cooperate to identify the user associated with
   a TAC, there is no benefit in trying to prevent the AI from
   issuing a non-traceable certificate, as there is no way to
   force the AI (or BI) from cooperating in the tracing of a
   certificate if the AI (or BI) simply chooses not the store
   the information required to perform the trace.

 - The document says that "The reader is referred to [17] and [18]
   where procedures for implementing RSA and DSA threshold
   signatures are described, respectively." I am assuming that this
   text intended to refer to [16], "Two-Party Generation of DSA
   Signature", for DSA rather than [18].  However, [16] specifies
   protocols that require either 4 or 8 messages, but the protocol
   in this paper only allows for a single round trip between the AI
   and BI when performing the split signing operation.  This seems
   to suggest that the current protocol cannot support split
   signing using DSA.

 - Section 5 says that "Blinding is also defined for signature
   algorithms like DSA, but the explanation is more complex, since
   DSA does not natively encrypt data."  Can a reference be
   provided?  I can only find references to papers that propose
   blinding schemes for variants of DSA.

 - Section 5.1, Step 1 states "The signature on a Token is
   generated by the BI using a private key employed only for
   this purpose."  Step 2 states "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.)"  May the BI use the same private key
   and certificate to sign Tokens and for TLS authentication?  If
   not (as stated in Step 1), then why is it necessary for the
   certificate corresponding to the Token signing key to be
   "suitable for use with TLS"?  Many other places in the document
   state that certificates used to verify signatures on CMS
   messages should be "suitable for use with TLS".

 - Section 5.1, Step 2 (and Appendix A) states
   "Token ::= SignedData".  However, according to Appendix C,
   a Token is a CMS message.  That is, a Token is a ContentInfo
   with a contentType of id-signedData and a content that holds
   a SignedData.  Writing "Token ::= SignedData" suggests that
   there is no ContentInfo wrapper.  In order to avoid confusion,
   the Token should always include the ContentInfo wrapper.

 - Section 5.1, Step 4: Why does the AI need to sign the
   Token and BlindedCertificateHash when they are being sent to
   the BI over a two-way authenticated secure channel?  Even
   if CMS is used, that doesn't mean that the content has to be
   signed.  The CMS message sent by the the AI to the BI could
   simply be:

      ContentInfo ::= SEQUENCE {
           contentType ContentType, -- id-data
           content [0] EXPLICIT ANY DEFINED BY contentType }
                -- the content is the DER encoded SEQUENCE
                -- of the Token and BlindedCertificateHash

 - Section 5.1, Step 5: Same as Step 4?  Why does the response
   need to be signed?

 - Section 5.1, Step 6 states:
      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.

   Has it been verified that this will always yield the correct
   result?  My guess is that it will for RSA, but I would need
   to be convinced that for DSA one could perform the unblinding
   operation on a partial signature, then complete the signing
   operation, and be guaranteed to get the correct result.  The
   safer alternative would be for the AI to complete the signing
   operation and then perform the unblinding operation.  (Since
   I have not seen the paper, I am not even certain that a DSA
   signature on a blinded hash is performed in the exact same way
   as a normal DSA signature.  If not, then the split-signing
   protocol may not work on a blinded hash.)

 - Section 5.1, Step 6 states:
      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 to be able to
      match the resubmitted request to the original request, and
      respond accordingly.

   This seem appropriate, but it is contradicted by the following
   text in Section 5.1, Step 4:
      Next, the AI compares the received Token against a cache of
      recent (i.e., not "timed out"), validated Tokens. If a
      duplicate is detected, the certificate request is rejected as
      a replay.

   In addition, only the AI should be able to "match the
   resubmitted request to the original request".

 - Section 5.2, Step A states that "we propose creating a second
   CA, under the TAC CA and have it be the CRL issuer for the EE
   certificates issued by the TAC CA."  However, the actual
   proposal is to create a second (CRL signing only) key for the
   CA, not to create a second CA.

 - Section 5.2, Step A states that "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."  This is not sufficient.  If the CRL that is
   signed using the CA's split certificate-signing key does not
   include an issuingDistributionPoint extension then RPs may
   use this CRL to determine the status of any certificates issued
   by the CA.  So, the self-issued certificate including the CRL
   signing key MUST include a CRLDP extension and the corresponding
   CRL MUST include an IDP extension to ensure that this CRL will
   not be used to verify the status of any other certificates.
   Inclusion of a CRLDP in the EE TAC certificates is useful, but
   does not ensure that RPs will use the correct CRL.

 - Section 5.2, Step A states that "If the AI uses OCSP [14] or
   SCVP [15] to convey the revocation status of TACs, an equivalent
   procedure is employed."  SCVP cannot be used by a CA to convey
   status information in the same way that CRLs and OCSP can, and
   so it should not be mentioned here.

 - Section 5.3.1, Subject begins "If present, ...."  The subject
   field in CertificationRequestInfo is not OPTIONAL and so must
   be present.

 - Section 5.3.1, Subject continues with "value of this field
   [subject] SHOULD be empty".  However, section 5.1, Step 3 says
   "The Subject field of the certificate contains a pseudonym
   generated by the user."  There is no suggestion in section 5.1,
   Step 3 that the user may leave the subject field empty rather
   than including a proposed pseudonym for the subject name.  These
   two sections should be made consistent.

 - Section 5.3.1, Attributes: "This attribute contains
   X509v3 Certificate Extensions."  Which attribute?  Not the
   id-kisa-tac attribute mentioned in the previous sentence?  Is
   inclusion of extension in the PKCS10 optional or are there
   certain extensions that must be included?

 - Section 5.3.1 says:
      This profile applies the following additional constraints to 
      fields that MAY appear in a CertificationRequest Object:

         signatureAlgorithm
             This field specifies the signature algorithm.

   What does this mean?  The signatureAlgorithm is mandatory and
   this text does not impose any constraints on the field.

 - Section 5.3.2, Subject: "If present, the value of this
   field SHOULD be empty, ...."  As with Section 5.3.1, this text
   need to be consistent with section 5.1.

 - Section 5.3.2, Extensions: Is inclusion of extension optional
   or are there certain extensions that must be included?

General:

 - In many places in the document seem to include the wrong
   references.  For example, Section 5 refers to [18] for
   implementing threshold signatures using DSA rather than [16].

 - The protocol messages defined in this document all use the
   same basic format: a CMS signed data object.  For all of these
   messages, the eContentType is specified as id-data and
   (presumably) the MIME type is application/pkcs7-mime, perhaps
   with the parameter smime-type=signed-data.  Each of the
   protocol messages should have its own MIME type and/or
   eContentType.  Otherwise, there is no way for the recipient to
   know how to process the data.

 - Referring to the certificates issued using this protocol as
   anonymous rather than pseudonymous is confusing.  The editors
   note in the Introduction that pseudonymous is the correct term,
   but still choose to use the misleading term "anonymous".  I do
   not agree that the terms are commonly used interchangeably, and
   believe that the use of the correct term, pseudonymous, would
   make the privacy properties of the certificates more clear.
   People already understand the idea of using different names
   (pseudonyms) in different contexts in order to increase privacy.
   Anonymity is achieved by not identifying (authenticating)
   oneself at all, not by identifying oneself using a pseudonym.

 - The protocol should allow for the possibility of rekey.  In many
   cases, users will want to use the same pseudonym for an
   extended period of time.  For example, many people use a
   pseudonym when posting to message boards or when selling items
   on-line (e.g., on eBay).  People who earn good reputations as
   sellers would not want to have to periodically change
   pseudonyms.  A TAC for these users would allow them perform
   strong authentication to prevent others from accessing their
   accounts.  The TAC would allow the sellers to keep their true
   identities a secret while at the same time reassuring buyers
   that sellers' true identities could be determined in case a
   seller committed fraud.  While this type of scenario may not
   have been the original motivation for TAC, is there any reason
   that it should not be supported?

---

From: Stephen Kent <[email-masked]>
Date: Thu, 8 Jan 2009 13:31:33 -0500

David,

First, thanks for reading the I-D and providing comments.  It will 
take a whole for my co-authors and me to respond to all of them, but 
I wanted to let acknowledge receipt of the comment.

Thanks,

Steve