[cabfpub] BR "corrections" ballot

[Peter Bowen]

> On Mar 21, 2016, at 5:31 AM, Rob Stradling <rob.stradling at comodo.com> 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?
> 
> How is the encoding of an ignored field "in a security context”?

It is clear, at least to me, that the U-label/A-label item does not belong in a corrections ballot.  The amount of discussion far exceeds what is expected for a “consent” item.  Given that I added this due to the practices of several CAs (as Rob has so kindly pointed out), I would suggest that one or more of them propose a ballot for that change alone.

Thanks,
Peter