On Wed, Jul 25, 2018 at 2:08 PM Joanna Fox via dev-security-policy < [email protected]> wrote:
> On Friday, July 20, 2018 at 9:39:04 PM UTC-7, Peter Bowen wrote: > > > *Total of 17 certificates issued in 2018 were revoked due to invalid > > > extended ascii characters. CertLint was not catching these issues, > which > > > would have prevented issuance. We have since remediated these > problems, and > > > are adding zLint to our certificate issuance process as a second check. > > > Issued in 2018 certificate serial numbers 4329668077199547083, > > > 8815069853166416488, 8835430332440327484, 13229652153750393997, > > > 12375089233389451640, 11484792606267277228, 11919098489171585007, > > > 9486648889515633287, 14583473664717830410, 7612308405142602244, > > > 4011153125742917275, 6919066797946454186, 15449193186990222652, > > > 14380872970193550115, 1792501994142248245, 12601193235728728125, > > > 10465762057746987360 > > > Cert.sh was unavailable when this was crafted else I would provide > links > > > to the 4 certs which were CT logged. > > > > > > https://crt.sh/?id=294808610&opt=zlint,cablint is one of the > > certificates. It is not clear to me that there is an error here. The > DNS > > names in the SAN are correctly encoded and the Common Name in the subject > > has one of the names found in the SAN. The Common Name contains a DNS > name > > that is the U-label form of one of the SAN entries. > > > > It is currently undefined if this is acceptable or unacceptable for > > certificates covered by the BRs. I put a CA/Browser Forum ballot > forward a > > while ago to try to clarify it was not acceptable, but it did not pass as > > several CAs felt it was not only acceptable but is needed and desirable. > > > > If Mozilla (or another browser) puts forward a policy on this, I'm happy > to > > update certlint to reflect the poicy. > > Using the example provided of > https://crt.sh/?id=294808610&opt=zlint,cablint, the error to which we > were addressing is, “ERROR: Characters in labels of DNSNames MUST be > alphanumeric, - , _ or *”. RFC 5280 states that the SAN field can contain a > dnsName but it must be in the IA5String format. IA5String is defined as > the first 128 characters in the ASCII alphabet. Right now as this is > defined, it does not include international variance of ISO 646. Should we > revisit this issue to clarify if international characters should be > included? GoDaddy would be in support of adding this clarification. That error is coming from zlint and appears, from my reading, to be a bug in zlint. The DNSName entries in the SAN in that certificate only contain allowable characters. The commonName attribute value in the Subject does have characters that are not allowed in the DNSName entry, but commonName is allowed to be a utf8string, which allows these characters. Further the commonName contains a fully qualified domain name that also appears in the SAN, so that BR requirement is met. The challenge in this case is that the BRs do not specify the required encoding of domain names. This doesn't really matter when handling pre-IDN domain names, but with Internationalized Domain Names (IDNs), encoding does need to be specified. Until Mozilla or the CA/Browser Forum clarifies, I do not think this certificate has any errors. Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
