On Mon, Mar 21, 2016 at 8:31 AM, Rob Stradling <[email protected]> wrote:
> On 21/03/16 11:56, Gervase Markham wrote: > > On 21/03/16 11:49, Rob Stradling wrote: > >> What would be the downside of saying that subject:commonName, if > >> included in the cert, MUST contain either the A-label form or U-label > >> form of one of the SAN:dNSName values? > > > > Converting using IDNA2003 or IDNA2008? :-)) > > > > In a data structure designed for computer consumption, why would you not > > want to write the computer-readable, as opposed to human-readable, > > version of the label? My security spider-sense tells me that allowing > > multiple "equivalent" forms of a name in a security context, rather than > > requiring a single canonical form, is a good way of getting nasty bugs. > > Browsers ignore subject.commonName (for determining whether or not the > cert is valid for a given domain name) when 1 or more SAN:dNSNames are > present, right? > FWIW, that appears to be the case for mozilla::pkix. https://dxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixnames.cpp#380 Nonetheless, I would *really* prefer that we be consistent between CN and SANs, just in case there are other browsers out there that don't have this behavior. --Richard > How is the encoding of an ignored field "in a security context"? > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
