|
On 03/24/2016 11:09 AM, Stephen Kent
wrote:
David, Untrue, as I'll demonstrate below. It does require uniqueness That is only one relevant statement in RFC 5280. There are many others, and there are also relevant statements in other PKIX documents. There is also plenty of text in X.509 indicating that names need to be unambiguous across CAs, and the PKIX charter called for maintaining compatibility with X.509: PKIX will continue to track the evolution of ITU-T X.509 documents, and will maintain compatibility between these documents and IETF PKI standards, since the profiling of X.509 standards for use in the Internet remains an important topic for the working group. Within the RFC 5280 Security Considerations section (as updated by RFC 6818), there are at least two paragraphs that address this: While X.509 mandates that names be unambiguous, there is a risk that two unrelated authorities will issue certificates and/or CRLs under the same issuer name. As a means of reducing problems and security issues related to issuer name collisions, CA and CRL issuer names SHOULD be formed in a way that reduces the likelihood of name collisions. Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. At a minimum, implementations validating CRLs MUST ensure that the certification path of a certificate and the CRL issuer certification path used to validate the certificate terminate at the same trust anchor.Why would RFC 5280 describe risks related to two unrelated authorities issuing certificates under the same name if it is permitted for two unrelated authorities to issue certificates under the same name? Are you really suggesting that the document simultaneously indicates that it is acceptable for two unrelated authorities issuing certificates under the same name (your claim), while also stating that CAs SHOULD NOT do this and warning that there are risks if they do? If an attacker obtains the private key of a CA unnoticed, the attacker may issue bogus certificates and CRLs. Even if an attacker is unable to obtain a copy of a CA's private key, the attacker may be able to issue bogus certificates and CRLs by making unauthorized use of the CA's workstation or of an RA's workstation. Such an attack may be the result of an attacker obtaining unauthorized access to the workstation, either locally or remotely, or may be the result of inappropriate activity by an insider. Existence of bogus certificates and CRLs will undermine confidence in the system. Among many other possible attacks, the attacker may issue bogus certificates that have the same subject names as legitimate certificates in order impersonate legitimate certificate subjects. This could include bogus CA certificates in which the subject names in the bogus certificates match the names under which legitimate CAs issue certificates and CRLs. This would allow the attacker to issue bogus certificates and CRLs that have the same issuer names, and possibly the same serial numbers, as certificates and CRLs issued by legitimate CAs. Again, why would the RFC permit something so risky? Why would a document with such a security flaw be allowed to progress to RFC status? Perhaps the answer is that (as I've repeatedly pointed) out, neither RFC 5280 nor the X.509 standard that it profiles permits two different CAs to issue certificates with the same subject names to two different entities, and the Security Considerations section of RFC 5280 is pointing out that there is a risk that this could happen even though the standard doesn't permit it, and pointing out some of the problems that could occur if it did. Looking at the Section 6.3 of RFC 5280 (CRL Validation) also makes the requirement clear. When deciding whether a CRL (that could have been obtained from anywhere) may be used to determine the status of a certificate, RFC 5280 says: (f) Obtain and validate the certification path for the issuer ofRFC 5280 explicitly allows the certification path for the CRL to be different from the certification path for the certificate whose status is being checked, as long as both certification paths start with the same trust anchor (a requirement imposed by RFC 5280, but not X.509). So, using the figure below as an example, RFC 5280 states that the CRL shown on the left could be used to determine the status of the EE certificate on the right (assuming the CRL does not include an optional issuingDistributionPoint extension). [Feel free to read all of RFC 5280 Section 6.3 to verify this.] According to you, however, RFC 5280 permits the subject of the certificate from subordinate CA 1 and the subject of the certificate from subordinate CA 2 to be unrelated entities. If that were true, why would it allow a CRL issued by one entity to be used to determine the status of a certificate issued by an unrelated entity? It doesn't, because RFC 5280 doesn't permit unrelated CAs to issue certificates and/or CRLs under the same name. If it did, then it would need to impose a much stricter requirement for validating CRLs than that the certification path MUST have the same trust anchor. It would need to require something closer to MUST be the same certification path. Along the lines of the text in the Security Considerations section, the text in Section 6.3 requires that the paths start with the same trust anchor in order to protect against the risk that two unrelated CAs issue certificates and CRLs under the same name, but it assumes that there will not be two unrelated CAs issuing under the same name that are part of the same PKI (i.e., are under the same trust anchor). Are you really suggesting that RFC 5280 permits something, but then assumes it won't happen, and then warns that there are risks if it does happen? +--------------+ As I noted before, RFC 5280 isn't the only document that includes text related to this requirement. RFC 5755 (Attribute Certificate Profile) is another example. RFC 5755 indicates that there are three ways to specify the Holder of an attribute certificate (the Holder of an attribute certificate is the equivalent of the Subject of a public-key certificate), and then it says: For any environment where the AC is passed in an authenticated message or session and where the authentication is based on the use of an X.509 PKC, the Holder field SHOULD use the baseCertificateID.where baseCertificateID is defined as IssuerSerial, and IssuerSerial is defined as: IssuerSerial ::= SEQUENCE {[The issuerUID field would almost always be absent, since public-key certificates almost never include this field.] So, RFC 5755 encourages identifying the Holder of an AC by the issuer name and serial number of the Holder's public-key certificate, and yet it says the following the Security Considerations section: If an attribute certificate is tied to the holder's PKC using the baseCertificateID component of the Holder field and the PKI in use includes a rogue CA with the same issuer name specified in the baseCertificateID component, this rogue CA could issue a PKC to a malicious party, using the same issuer name and serial number as the proper holder's PKC. Then the malicious party could use this PKC in conjunction with the AC. This scenario SHOULD be avoided by properly managing and configuring the PKI so that there cannot be two CAs with the same name. Another alternative is to tie ACs to PKCs using the publicKeyCert type in the ObjectDigestInfo field. Failing this, AC verifiers have to establish (using other means) that the potential collisions cannot actually occur, for example, the Certificate Practice Statements (CPSs) of the CAs involved may make it clear that no such name collisions can occur.If the PKIX profile for public-key certificates (RFC 5280) really allowed unrelated CAs to issue certificates under the same name, why would the PKIX AC profile say that issuers of ACs SHOULD use the baseCertificateID choice to identity a Holder in some cases and then warn that using that choice could allow one entity to use (claim "ownership") of another entity's AC if two unrelated CAs issue certificates under the same name and happen to issue certificates with the same serial number (a likely possibility since some CAs issue certificates with sequential serial numbers)? That would seem like a fatal flaw in th profile. If the PKIX profile for public-key certificates (RFC 5280) really allowed unrelated CAs to issue certificates under the same name, why would the text above refer to one of the CAs issuing under this name as a "rogue CA"? Why limit this text to a "rogue CA" if the same circumstance could occur by accident with two legitimate CAs that just happen to issue certificates under the same name? If the PKIX profile for public-key certificates (RFC 5280) really allowed unrelated CAs to issue certificates under the same name, why would the text above suggest "properly managing and configuring the PKI so that there cannot be two CAs with the same name." Doesn't that imply that a PKI with two CAs issuing under the same name isn't "properly managed"? Why would it suggest that if, as you claim, there is nothing improper about two unrelated CAs issuing certificates under the same name, as long the two unrelated CAs are not both issued cross-certificates by the same CA? The answer to all of the above is quite clear. PKIX does not permit two unrelated CAs to issue certificates under the same name. That is, it does require names to be unambiguous across CAs. The two CAs in my scenario have different parents, but the same name and same public key. So Aside from the gratuitous parenthetical in your text falsely stating that RFC 5280 "doe not preclude the creation of two CAs with the same name, so long as the parent CAs are distinct," you still write about two CAs issuing two EE certificates that are identical. If it walks like a duck and it quacks like a duck, then chances are its a duck. In the scenario you are trying to describe, there is one CA that issues one EE certificate. If you stopped trying to pretend otherwise, that would be a great starting point in improving the rest of the text, since so much of the rest of the description is based on trying to treat a single EE certificate issued by a CA as if it were two different, but identical, certificates issued by two different, but colluding, CAs that happen to issue under the same name and using the same key. Why not just acknowledge that this attack scenario involves one CA issuing one EE certificate, where the one CA has been issued cross-certificates by two different "parent" CAs and then write the remainder of the text based on that. That would eliminate any justification for including a parenthetical falsely claiming that RFC 5280 does not preclude the creation of two CAs with the same name, but it would make the description of the attack so much better. Right now, the proposed text isn't "more general," it is just convoluted.
Can you name even one RP that maintains a cache of revocation status info organized by cert path? If not, then why all the text about revocation status checking being performed in the context of a certification path and how "a browser checking a CRL or OCSP response may not match this revocation status data against the doppelganger certificate," followed by a suggestion that the attacker might take advantage of this by revoking one of the two identical EE certificates while not revoking the other. Why would it be the "best strategy" for the attacker to rely on browsers behaving in a way that no browsers actually behave? As I said before, there are ways the attacker might be able to perform the type of attack where some RPs see the EE certificate as having been revoked and others do not, but that it not what you described. Why not just go back to what DKG described, where the attacker revokes the CA certificate along the path submitted to the log and leaves the other CA certificate unrevoked so that there is still a valid certification path to the one EE certificate?
|
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
