Varga Viktor wrote, On 2009-03-09 06:12: > Multiple caIssuers and OCSP in AIA field, multiple CDP: > ------------------------ > The RFC 5280 doesn’t exclude to have multiple OCSP and caIssuers field > in the AIA. It is good for redundancy, for example to have two OCSP > responder, when one of them is down,the other is accessible?
I agree completely. The RFC does not exclude it. It's not a bad idea. > Does the Firefox handle it? Alas, no. I believe it always uses the first one it finds in the cert, and only that. > This same also implies for CDP. CDP is different, in numerous ways and for numerous reasons. Today, Firefox does not do fetching of certs based on CDP, but that is being implemented now, and I expect it will try potentially all DPs until it gets an acceptable answer or exhausts the list of DPs. > UCC certificate profile > ---------------------------- > There is the UCC certificate profile, which is needed by the Exchange > 2007 to use with external and internal names. These names are put in the > Subject Alternative Name field of the certificate. > > It is possible to these request have FQDN for external, and internal > names without valid FQDN, for internal access. Certs with SANs that are not valid FQDNs are a huge risk. Consider the user who tries to visit https://www/ and gets a response from a server whose cert bears the DNS name www. Realistically, does that user/browser have any strong reason to believe that it's talking to the INTENDED www server? It is *very* easy to conduct MITM attacks against those. But the strategy we use for DNS name validation is simple (ignoring wildcards). We match the ENTIRE name string given to us by the browser (which came from a link or from the user's typing of the URL) and compare it against EACH of the DNS names in the SAN in its entirety. If the two strings match entirely, they match, and we're satisfied. That means that if a user does type https://www/ and gets a cert with a DNS name of www, we'll be satisfied that the host name matches. Perhaps the browser security UI folks should think about the risk of displaying strong security indicators for non-FQDN host names in URLs. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
