Subject: Comments on draft-ietf-pkix-tac-011.txt

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Aug 2008 12:44:56 -0700

Authors,

I have a series of what I consider to be serious issues with this document.
I have communicated some of these issues directly to the authors, but I feel
that the entire list should get my full review.

1.  What is the time length that TAC certificates are expected to be used
for?  Are they onetime certificates, are they supposed to be good for a
short period of time (i.e. months) or are they supposed to be good for
extended periods of time (i.e. years but used infrequently), or all of the
above?

2.  Given the ability to potentially link an identity from other information
on the network (i.e. IP addresses), I would like to see some text describing
the types of protocols that TAC certificates should and should not be used
in.  For example, it could be used for an anonymous TLS client auth
certificates, but would probably not be as useful for a SIP or S/MIME
certificate.  Or maybe you disagree with that.  A description of the types
circumstances that these certificates are used in would helpful in trying to
determine if they are both useful and susceptible to other types of attacks.

3.  I think the document should strongly suggest that indirect CRLs are used
by TAC CAs.  This would almost be a requirement for OCSP.  The protocol
needs to have a way for a communication to occur between the AI and BI to
allow for signing of CRLs in any event.  What is this going to look like.
Does the BI simply trust the AI to hand it a correct hash?  Does the AI sign
the CRL, pass it to the BI to finish signing and then verify, does the AI
give the TBS to the BI, have the BI sign it and then return the signature to
the AI to finish signing and publish?

4.  Information should be placed in the document (Security Considerations is
fine) about the financial model associated with this issuing model.  All
user financials need to be done with the BI and not the AI, the AI would
have to get compensated by the BI for issued certificates.  An associated
item with this is the question of should the BI be able to influence
contents of the certificate, specifically the lifetime of the certificate to
correspond to the money paid.

5.  Renewal/Rekey operations are not covered by this document.  Either you
need to state that these operations are never done, or you need to have a
secure method of allowing the operation to be completed.  In this case the
Token no longer exists (or at least is no longer valid) and so the AI would
need to prove to the BI that the BI should sign the certificate.  One
possible method would be to send the BI the TBSigned of the new certificate
along with the old certificate allowing it to see that it had previously
signed a certificate for subject name.  It would still not be traceable back
to the user's Token, but would give assurances that the certificate should
be issued.

6. The document does not discuss the fact that a TAC certificate should only
issue TAC certificates.  If this statement is incorrect, then the document
needs to discuss how non-TAC certificates are to be issued.  In this case
the BI would be signing certificates for people it has never seen before and
has no information about.

7.  Guidance needs to be supplied about how long items are to be kept in the
respective databases.  Are these database entries expected to be kept
forever once a certificate has been issued?  Or are they only kept for
approximately the life of the certificate.  This is really impacted by the
answer to question #5 on rekey/renewal, but has some additional tracing
implications beyond that.

8.  How much is the following considered to be a potential attack on the
scheme.  The BI collects and remembers the time at which it issued a
signature on a certificate, it then stores that information in its database
and trolls for certificates that are issued at about the same time to match
up with the user information it has in the database.  Actually this attack
could potentially be expanded in a more general way.  If an attacker looks
for IP addresses talking to the CA, and then looks for certs from the CA
that were issued about that time, if the number of certificates issued is
small it might be possible to tie an IP address to a certificate.

9.  If you believe that TAC permits both signature and encryption
operations, then you need to address an additional problem.  If a DSA
signature certificate and a DH encryption certificate pair are needed, it is
some protocols may require that they contain the same subject name, and thus
would need to be issued at the same time.  The current TAC protocol makes no
allowances for the ability to have the BI sign two independent certificates
at the same time.  This could be done by allowing the protocol to present
multiple blinded hashes to the BI to be signed for a single token.

10.  Suggest addition of text to "Step 1" in section 5.1.  "Hashing of the
user's name, without the additional of additional random material MUST NOT
be used for to create a UserKey.  It must be assumed that an attacker could
obtain the user's name."  The reason for this is that people may assume that
doing a hash will create a user key that satisfies the condition that it not
be associable with the user's name since it is a one-way function and could
not be reversed.

11.  In section 5.1 Step 2, the statement is made that a TLS certificate
should be used for doing the signature operation on a CMS object.  You might
want to rethink this statement.  While there is nothing technically wrong
with this, some CMS validators would reject the signature since the EKU
would not be correct.

12.  CRMF (and PKCS#10) are certification message request formats, they are
not protocols.  The certificate request protocols that the PKIX working
group has standardize are CMC and CMP.  The text needs to be written to
reflect this.  Either talk about the formats or talk about the protocols I
don't really care which, just don't confuse the two.

13.  I would like to see for each of the steps in 5.1, an explanation of who
needs to be protected against for the communication.  This will better allow
others to decide on how to implement this with non-TLS communications.  For
example, could this be done with e-mail or are the security requirements not
met?

14.  I am not sure how detailed this topic needs to be covered, but the
document needs to discuss the fact that obtaining this certificates may take
time and  the transaction may not be completed in one round trip from the
user to the AI.  One question that comes about is does this increase any
security considerations?

15.  I would strongly recommend that a Token be a CMS ContentInfo object.
All CMS implementations will accept a ContentInfo object to be decoded, not
all of them will accept a SignedData object to be decoded.  Additionally if
you use a ContentInfo object, the BI could apply encryption to the token so
that only the AI can understand the contents.  Thus either Signed(content)
or Signed(Encrypted(Signed(content))) would be returned to the user.

16.  The numbering of steps on Figure 1 is incorrect starting with step #4.
One of the steps does not include a transmission step (or the transmission
is part of two steps).

17.  In section 5.2, step C - should the BI also conduct its own assessment
of the fact that the aggrieved party's case before releasing the
information?

18.  In section 6, does there need to be any comments about the possible
problem of BI trying to attack AI share of the key?  I have not read any
threshold crypto work recently, but it seems to me that a shorter half key
might be easier to break.

19.  I am not an expert here, however you probably need to explain how the
communications over the TLS link are being made.  I assume that you are
using HTTPS, but that is not clear.

I'll make a pass over the ASN.1 after these issues have been resolved.
Questions of what the content of various items looks like will change based
on some of the above questions.  At a minimum however we will need to get a
CMS content type to be used in the token.

I should be online frequently for the next week, but infrequently for the
two weeks after that.

Jim