Re: [Trans] text to address DKG's conspiring CAs attack

[David A. Cooper]

You seem to contradict yourself. You say you disagree with my assertion that RFC 5280 as written doesn't work unless names are globally unambiguous, and then you try to support your disagreement by saying that "there is at least one other solution to the problem." So, you acknowledge that if RFC 5280 didn't require names to be globally unambiguous, then there would be a problem, and then suggest how RFC 5280 could be changed to address that problem. Even Steve Kent acknowledges this: Yes, the Security Considerations section of 5280 notes that problems that can arise if names are not globally unique. However, that is not the same as saying that 5280 requires them to be so. Rather it is a warning of the bad things that may happen if name collisions occur. A warning in the Security Considerations section the way we usually note a residual vulnerability in a standard. It is NOT a backdoor way to add a requirement to a standard. If you and Steve were correct that RFC 5280 didn't require names to be globally unambiguous, then (as I've shown) relying parties could obtain incorrect results even if all of the CAs, OCSP responders, etc., in the PKI were behaving honestly in accordance with the standard. That isn't residual security risk to documented in the Security Considerations section. That is a design flaw in the protocol that should have prevented the document from becoming an RFC. Are you and Steve really saying that the PKIX WG deliberating chose to introduce a design flaw into RFC 5280 (and RFC 5755 and other PKIX documents) by deviating from X.509? Why would the PKIX WG co-chairs allow this? I also disagree that you've pointed out "at least one other solution to the problem." The only things I've seen you suggest is that "the vulnerability is also mitigated by requiring AIA in the EE certificate." I can only guess what that means. Do you mean require an AIA extension with the id-ad-ocsp access method in the EE certificate? Would you simultaneously be forbidding the use of CRLs? What about CA certificates? How would the AIA extension fix the problem with attribute certificates (RFC 5755) that I highlighted? Need further evidence of the RFC 5280 requirement? RFC 5280 says: Section 4.1.2.4: The issuer field identifies the entity that has signed and issued the certificate.  The issuer field MUST contain a non-empty distinguished name (DN).  The issuer field is defined as the X.501 type Name [X.501]. Section 4.1.2.6: The subject field is defined as the X.501 type Name.  Implementation requirements for this field are those defined for the issuer field (Section 4.1.2.4). How does X.509 define the Name type: A (directory) name is a construct that identifies a particular object from among the set of all objects. A name shall be unambiguous, that is, denotes just one object. However, a name need not be unique, that is, be the only name that unambiguously denotes the object. So, RFC 5280 says that the issuer and subject fields in certificates as defined as the X.501 type Name, and point to X.501 for the definition of Name, which defines Name to be something that is unambiguous. I'm sure some will argue that RFC 5280 only intended to adopt some aspects of the definition of Name from X.501, and not this part of the definition. However, there is nothing in RFC 5280 to support that. And, you still can't get around the problem that if RFC 5280 didn't require names to be unambiguous, then as it is currently written, it and other PKIX documents would be flawed by design. On 03/31/2016 07:51 AM, Ben Laurie wrote: On 30 March 2016 at 19:36, David A. Cooper <david.coo...@nist.gov> wrote: I provided rather detailed evidence that RFC 5280 does require global name uniqueness. Can you explain why my evidence is wrong? As far as I can work out, your evidence is that RFC 5280 _ought_ to have required global name uniqueness, not that it _does_. I haven't seen you quote anything from RFC 5280 that requires it.   How does the text in Section 6.3 of RFC 5280 ensure that a CRL issued by one CA isn't used to determine the status of certificates issued by an unrelated CA issuing certificates under the same name if both can be validated from the same trust anchor? It doesn't.   I have been explaining what RFC 5280 says (and what X.509 says). I have not been trying to justify that it was a correct design decision, so there's no need for me to answer the question about how one would ensure names are unambiguous. You are free to agree with Steve that RFC 5280 shouldn't have required names to be globally unambiguous, but that doesn't change the fact that (as I have shown) RFC 5280 and other PKIX documents were written in a way that things don't work unless names are globally unambiguous. I don't agree with Steve that RFC 5280 shouldn't have required names to be globally unambiguous, because AFAICS it doesn't. I also don't agree that RFC 5280 was written s.t. it doesn't work unless names are globally unambiguous - there is at least one other solution to the problem, as I've pointed out. If RFC 5280 didn't require names to be unambiguous, why didn't the text in Section 6.3.3 address the problem I mentioned above by requiring that the certification path for a CRL be the same as for the certificate whose status is being checked (or at least require that the list of CA names in the paths be the same)? Again, you can agree with Steve that something like that should have been done, but where's the evidence that it was done? I am not saying there is any evidence it was done.   Dave P.S. It would really be helpful if this discussion thread could end. It's not relevant to TRANS, and there would be no reason to discuss it at all in this group if there wasn't an attempt to include text about it in one of the TRANS documents. Agreed.   On 03/30/2016 01:15 PM, Ben Laurie wrote: On 30 March 2016 at 17:02, David A. Cooper <david.coo...@nist.gov> wrote: So, your contention is that PKIX diverged from X.509 by removing the requirement for names to be unambiguous, and did nothing to address the vulnerability created by this divergence other than noting the vulnerability in the Security Considerations sections of its documents? The working group then went on to develop protocols and profiles that relied on names being unambiguous, and then just noted in the Security Considerations that an unnecessary vulnerability had been created? I have even looked for evidence that the PKIX WG discussed the idea of deviating from X.509 and allowing names to be ambiguous (i.e., unrelated entities operating under the same name) and have been unable to find any evidence of that on the mail list. I have, however, heard an explanation for why the text in Section 4.1.2.6 says what it does, and it was not about a deliberate decision to deviate from X.509. In practice, how would you ensure names were unambiguous? (actually, a CT-like mechanism could be used, but CT does rather post-date 5280) The vulnerability is also mitigated by requiring AIA in the EE certificate, which the BRs do. Arguably, 5280 should also. BTW, in case it is not clear, I do agree with Steve that 5280 does not require global uniqueness.

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans