Subject: TAC I-D comments and responses

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Feb 2009 16:27:56 -0500

Dave,

Thanks for your careful review of the TAC I-D.  Here are responses to 
your comments,

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.

You are absolutely right!  The use of these crypto mechanisms 
facilitates separation, but does not enforce it.  We will make your 
recommended change.

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?

In the architecture for Pseudonymous e-Commerce, a CA can link the 
pseudonym in the subject field to the real identity unilaterally, 
which can lead to a potential 'big brother problem'. In order to 
address this issue, this document proposes the separation of 
authority concepts (two CAs to issue TAC, which tries to prevent one 
CA from linking pseudonym to real identity unilaterally).

- 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?

Mapping from a true identity to a pseudonym is a holdover from an 
early version of the document and can be removed as a requirement.

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.

It's fair to say that use of the mechanisms mandated by the protocol 
is not a technical guarantee of the split between the RA and CA 
functions, e.g., for the reasons you note. However, use of these 
mechanisms probably makes it easier to conduct an audit that verifies 
the desired separation of duties. One could define a TAC system that 
did not specify these mechanistic details. However, verifying that 
such a system provides the desired separation would be more 
difficult, on a case-by-case basis. Since you work at NIST, I think a 
reasonable analogy here is with some of the specs used for FIPS 140-n 
compliance. For example, there is a spec for a PRNG because it makes 
it easy for a lab to evaluate a product claiming compliance with 140, 
not because that PRNG is the only good way to generate random values 
for use in crypto algorithms.

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

DSA-based approaches works but require some changes to the protocols 
between AI and BI. We'll make a future version of the TAC spec 
incorporate the necessary changes,but stick with just RSA for now.

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

You can refer to the blind DSA signature based on MacKenzie and 
Reiter, http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf.

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

There are several questions here:

- We recommend use of different keys for TLS authentication and for 
Token signing, as you noted above. Our advice is conservative, 
following the principle that one should use distinct keys for 
distinct purposes. Key generation is not so expensive as to warrant 
reuse of keys for these two purposes.

-  we use the phrase "suitable for use with TLS" to distinguish the 
certificates used for CMS message verification as distinct from the 
split-key certificates, as a shorthand. If you have a preferred 
wording for EE certificates being used in these cases, I think we 
would be happy to use that wording instead.

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

Good point, We will make the suggested change to show 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 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

When we elected to use CMS we assumed that we had to use one of the 
secured message types (signed, enveloped, encrypted digested, etc.). 
But, you're right that we could define a new OID and have a very 
simple payload. The downside is that existing code probably would not 
be able to parse this top-level contentType, but we will consider 
this proposed simplification.

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

See the reply above.

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

DSA-based approaches will work but require some changes to the 
protocols between AI and BI. In this version of document, we'll make 
suggested changes to go just with RSA.

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

The comments in step 4 are design guidance; they don't impose 
specific constraints on how long an AI holds onto a Token.  We can 
revise the step 6 text to note that although the AI and BI maintain 
state, they do not do so forever.

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

Yes, you're right. We'll revise the text here to say that only AI is 
involved in matching the resubmitted 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.

Sorry if this is not clear enough. The other CRL is issued using a 
private key known to the AI unilaterally. Since the key is distinct, 
but we want the CRL Issuer name to be the same, we elected to have a 
new CA, represented by a new CA certificate issued under the jointly 
managed CA certificate.

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

Thanks for noticing this omission. We'll add the requirement for the 
CRL to contain the CRLDP extension to match against the IDP extension.

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

SCVP responses are more  encompassing than OCSP and CRLs, but they 
can still provide an RP with an indication of whether a given 
certificate has been revoked, or not. So, I'm not sure why you feel 
that SCVP ought 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.

Thanks for catching that.  We'll fix this.

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

We will reconcile the text in the two sections.

- 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?

Whether extensions are required, optional, or permitted is a function 
of the CP for the TAC CA. However, We can add a note that, in 
general, it is a bad idea to allow users to include extensions in a 
cert request because that probably will allow the BI to match the 
issued cert to the user.

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

We'll fix the text to reflect the fact that this is a mandatory 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.

We'll fix that text to be consistent.

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

See the reply above for 5.3.1.

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

We'll review the document and fix the citation errors.

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

We adopted use of CMS to move the data between the AI and BI via our 
TLS-protected channel because Jim Schaad noted that we needed to have 
some way to carry the data that is already known and accepted by the 
application ADs, and CMS satisfies this criteria. Presumably we can 
use a new content type, w/o encryption and still keep them happy, 
even though this is NOT a content type that is generally supported.

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

It is true that the terms are not equivalent, even though many folks 
do use them interchangeably. However, the term pseudonymous isn't 
ideal here as it suggests that only RPs don't know the true identity 
of the Subject. TACs do provide a form of conditional anonymity, 
hence the name.

- 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?

I agree that the ability to retain the same pseudonym would have 
advantages in the contexts you cite above, but we dropped support for 
rekey as it added complexity (as noted by Jim) that we didn't want to 
address at this stage.

Let us know if these responses address your comments.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 27 Feb 2009 12:02:16 -0500

Steve,

Thanks for taking the time to respond to my comments.  I've included my 
responses in-line below for those items that I believe still need to be 
addressed.

Dave

Stephen Kent wrote:
> *In the architecture for Pseudonymous e-Commerce, a CA can link the 
> address this issue, this document proposes the separation of authority 
> concepts (two CAs to issue TAC, which tries to prevent one CA from 
> linking pseudonym to real identity unilaterally).
> *

This is incorrect.  In "An Architecture for Pseudonymous e-Commerce", 
the subscriber requests a certificate from CA A (i.e., the BI).  The 
subscriber authenticates to CA A using his/her real identity.  CA A 
issues certificate A to the subscriber with a pseudonymous subject 
name.  The subscriber then requests a certificate from CA B (i.e., the 
AI).  The subscriber authenticates to CA B using certificate A.  CA B 
issues certificate B to the subscriber with a pseudonymous subject name 
(a name that cannot be connected to the subject name in certificate A).  
The subscriber then uses certificate B to authenticate him/herself 
during normal transactions.  Thus, the subscribers' real identity cannot 
be tied to the subject name in certificate B without the cooperation of 
both CA A and CA B.

Note that the subscriber could even use certificate B to obtain yet 
another pseudonymous certificate from CA C so that it would require the 
collusion of three CAs to tie the pseudonymous identity that he/she uses 
to his/her real identity.

> *It's fair to say that use of the mechanisms mandated by the protocol 
> such a system provides the desired separation would be more difficult, 
> on a case-by-case basis. Since you work at NIST, I think a reasonable 
> analogy here is with some of the specs used for FIPS 140-n compliance. 
> For example, there is a spec for a PRNG because it makes it easy for a 
> lab to evaluate a product claiming compliance with 140, not because 
> that PRNG is the only good way to generate random values for use in 
> crypto algorithms.
> *

Can you please explain how the use of threshold signatures (combined 
with blinded signatures) makes it easier to conduct an audit that 
verifies that the AI and BI are performing their duties properly?

> *You can refer to the blind DSA signature based on MacKenzie and 
> Reiter,*_* http://www.ece.cmu.edu/~reiter/papers/2001/CRYPTO.pdf*_*.
> *

This paper seems to describe a threshold signature scheme (in particular 
two-party generation of DSA signatures), not a blind signature scheme.

> **- Section 5.1, Step 1 states "The signature on a Token is
> *There are several questions here:*
> *
> following the principle that one should use distinct keys for distinct 
> purposes. Key generation is not so expensive as to warrant reuse of 
> keys for these two purposes.*
> *
> *

Why not say "(Note that this certificate is just a certificate suitable 
for use with CMS, and is NOT the split-key certificate used to verify a 
TAC.)"?

> *The comments in step 4 are design guidance; they don't impose 
> *

The problem isn't that Step 6 implies that the AI and BI have to 
maintain state forever (although that is a good point as well).  The 
problem is that Step 4 says that "If a duplicate is detected, the 
certificate request is rejected as a replay".  Step 6 implies that a AI 
should (when possible) respond to a resubmitted request by resending the 
previous generated response, whereas Step 4 implies that the AI must 
respond to a resubmitted request by rejected it (i.e., by not responding 
to the request).

> *Sorry if this is not clear enough. The other CRL is issued using a 
> *

A CA is identified by its name, not by its key. So, in the scenario you 
are describing, you are not creating a new CA that issues CRLs under the 
same name as the AI.  You have a single CA with two keys, one for 
signing certificates and one for signing CRLs.

> ****- Section 5.2, Step A states that "If the AI uses OCSP [14] or
> *SCVP responses are more  encompassing than OCSP and CRLs, but they 
> *

OCSP can (generally) be used in one of two ways: (1) it can be operated 
on behalf of a CA to provide all relying parties with status information 
for the certificates issued by that CA; or (2) it can be operated on 
behalf a relying party to provide status information for all 
certificates that the relying party wishes to validate.  Section 5.2, 
Step A is describing (1), which is appropriate for OCSP but not SCVP.  
Trust model (2) would work for either OCSP or SCVP, but the use of SCVP 
here would relate to the way in which the relying party obtains status 
information, not the way in which the AI makes status information available.

> **- Section 5.3.1, Attributes: "This attribute contains
> *Whether extensions are required, optional, or permitted is a function 
> of the CP for the TAC CA. However, We can add a note that, in general, 
> it is a bad idea to allow users to include extensions in a cert 
> request because that probably will allow the BI to match the issued 
> cert to the user.
> *

The biggest problem is simply that the text says "this attribute" and I 
cannot what tell which attribute it means by "this".  Perhaps the text 
could be reworded as (if my proposed rewording is technically correct):

       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 Attributes field MUST include the id-kisa-tac attribute,
   which holds the Token and is defined below.  The Attributes field
   MAY also contain X509v3 Certificate Extensions that the subscriber
   would like to have included in the certificate.   The profile for
   extensions in certificate requests is specified in the RFC5280[2].

> **- Section 5.3.1 says:
> *We'll fix the text to reflect the fact that this is a mandatory field.
> *

Why not simply delete this?  Based on the second sentence of Section 
5.3.1, the document should not even bother to mention a field unless it 
is to specify an "additional constraint".

> **- Section 5.3.2, Extensions: Is inclusion of extension optional
> *See the reply above for 5.3.1.
> *

As above, the text about Extensions should simply be deleted unless the 
document will impose "additional constraints".

> **General:
>
> *We'll review the document and fix the citation errors.
>
> *- The protocol messages defined in this document all use the
> *We adopted use of CMS to move the data between the AI and BI via our 
> use a new content type, w/o encryption and still keep them happy, even 
> though this is NOT a content type that is generally supported.**
> *

If using a contentType other than id-data is problematic (although I 
can't see why since no standard library can meaningfully process 
something tagged as id-data), at least specify a different MIME type for 
each message.

> **- Referring to the certificates issued using this protocol as
> *It is true that the terms are not equivalent, even though many folks 
> of the Subject. TACs do provide a form of conditional anonymity, hence 
> the name.
> *

I have never heard this definition of pseudonymous.  Anonymous implies 
that no name is used, whereas pseudonymous implies that a fictitious 
name is used. There is no implication that anyone (other than the person 
using the pseudonym) knows the true identity of the person using the 
pseudonym.

> **- The protocol should allow for the possibility of rekey.  In many
> *I agree that the ability to retain the same pseudonym would have 
> address at this stage.*
*
*If the requirement to use a threshold signature scheme were removed, 
then the AI could accept and process standard certificate management 
request messages (including rekey requests) and so support for rekey 
would not add any additional complexity.  It is only the use of the 
threshold signature scheme that makes support for standard certificate 
management operations complex, and as noted above, I still do not see 
how the threshold signature scheme requirement provides any real benefit.

**

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 27 Feb 2009 15:21:37 -0500

A minor nit on the rewording:

The Attributes field MAY also contain a PKCS#9 [RFC2985]
extensionRequest attribute used to carry information about certificate
extensions the requester wishes to be included in a certificate.  The
profile for certificate extensions is specified in RFC5280[2].

Other PKCS#10 attributes (e.g., an attribute with an extension OID as
its type) can be sent to the CA.  PKCS#10 says CAs may use the contents
of PKCS#9 attributes, "as well as other information known to the CA" to
construct certificate extensions.  So sending a bare extension attribute
might conceivably result in that extension being included in the issued
certificate.  But the documented way to request an extension is to use
the extensionRequest attribute.

Dave

From: David A. Cooper

Whether extensions are required, optional, or permitted is a function of
the CP for the TAC CA. However, We can add a note that, in general, it
is a bad idea to allow users to include extensions in a cert request
because that probably will allow the BI to match the issued cert to the
user.

       Attributes