Last Call Review of draft-ietf-pkix-other-certs-
review-ietf-pkix-other-certs-secdir-lc-barnes-2009-08-18-00

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
  These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This documents creates a certificate extension that allows the issuer of 
a certificate to assert that the subject of the certificate is the same 
as that of a set of other certificates (i.e., that the same entity holds 
all the corresponding private keys).  This extension clearly creates 
some impersonation risks, but the document provides sufficient advice to 
CAs to mitigate these risks.

Overall, I think the document is basically ready for publication.  Some 
comments, mostly editorial, follow below.

--Richard


-----
Section 1, Paragraph 2
s/assoicate/associate/

Section 1, Paragraph 3
To be clear here and decouple this paragraph from the last, I would 
replace the phrase "... supports such linkage" to something like "... 
allows a certificate issuer to attest that the end entity that holds the 
private key for the certificate in question also holds other private 
keys corresponding to other certificates."  This change also clarifies 
why you refer to "end entities" below instead of just "subjects".

Section 2, Paragraph 3
Change "... change CA when renewing its certificate" to "... change CA 
when replacing its certificate".  Renewal only happens with the same CA.

Section 3, ASN.1 fragment
Change "::==" to "::=".

Section 3, Paragraph 6 (counting the two ASN.1 lines as a single para)
The first sentence in this paragraph seems very vague -- what does it 
mean for a use of this extension to be "safe"?  Suggest replacing with a 
requirement that is notably absent from this paragraph, namely that "CAs 
MUST issue a certificate containing this extension only after they have 
validated that the holder of the private key for the certificate also 
holds the private keys for linked certificates."

Section 3, Paragraph 6 (same as above)
Do you mean to have both requirements in the final sentence as "SHOULD 
NOT"?  It might be helpful here to note how the "purpose" a certificate 
might be determined, e.g., via CP or EKU OIDs.

Setion 3, Paragraph 10
The validation procedure in RFC 5280 requires an RP to verify that a 
certificate has not been revoked (Section 6.1.3, step (a)(3)), so the 
initial conditional can be omitted.  This requirement is really 
important for this extension, since one reason that certificates get 
revoked is private key compromise, in which case a party other than the 
intended subject has possession of the private key (by definition). 
This situation would allow the attacker to obtain linked certificates 
even from a CA that complies with this document.

Section 3, Paragraph 12
It would be helpful to clarify why this restriction is in place, e.g., 
"Since CA certificates are only used for certificate validation, and 
this extension has no effect on the validation procedure, this extension 
is meaningless for CA certificates."

Section 5
It's not clear that this section belongs in this document.  It would not 
reduce the clarity of the document to remove it.



_______________________________________________
secdir mailing list
secdir at mit.edu


https://mailman.mit.edu/mailman/listinfo/secdir