SECDIR review of draft-ietf-pkix-other-certs-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]