On 31 March 2016 at 16:15, David A. Cooper <[email protected]> wrote:
> 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, > I do, but I also assert that it does not require names to be unambiguous. > 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. > I agree! > 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 am not saying anything of the sort. I am just observing that the flaw exists. > > > 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? > Yes. > Would you simultaneously be forbidding the use of CRLs? > Specifying the CRL endpoint would also fix the problem. > What about CA certificates? > What about them? > How would the AIA extension fix the problem with attribute certificates > (RFC 5755) that I highlighted? > I don't know. Are you saying it wouldn't? I don't really know anything about 5755. > > 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. > Interesting. OK, for the sake of argument, let's assume that RFC 5280 does require names to be unambiguous. Now what? There is no mechanism in place to prevent (or even detect) ambiguity - that seems like a problem. Furthermore, what happens when it turns out a name is ambiguous? Presumably that makes all certs containing that name not 5280 compliant? > > > On 03/31/2016 07:51 AM, Ben Laurie wrote: > > On 30 March 2016 at 19:36, David A. Cooper <[email protected]> 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 < <[email protected]> >> [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/trans
