Are U-labels allowed in CN?

[Michel Le Bihan]

I always thought that they were, but from discussion under https://github.com/zmap/zlint/issues/601 it seems that they are not.

I found two certificates with U-labels in CN and I am wondering whether it's a linter issue or a case of misissuance.

https://crt.sh/?id=4512264235&opt=zlint

https://crt.sh/?id=3909545050&opt=zlint

[Kurt Roeckx]

From memory, I think in a CN it should be a U-label, in a SAN it
should be an A-label.


Kurt

[Corey Bonnell]

One of the reasons that Ballot 202 failed was that it proposed prohibiting U-labels from appearing in the CN, which several CAs noted in the “no” vote emails that this was the reason why they were voting against the ballot.

 

Given that there have been no normative changes to the allowed encoding of values in the CN field since ballot 202 was voted on, I’m inclined to agree with you and Kurt that U-labels are allowed, provided that the corresponding A-label encoding of the domain name is included as a dNSName in the SAN.

 

That being said, I don’t think prohibiting U-labels in CN is the worst idea in the world since conversion from U-labels to A-labels can yield different A-label representations of the domain name depending on if you’re using IDNA 2003, 2008, or transitional processing.

 

Thanks,

Corey

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/44052966-5378-478b-8562-b69f740dcde3n%40mozilla.org.

[Rob Stradling]

Corey wrote:

> I’m inclined to agree with you and Kurt that U-labels are allowed, provided that the corresponding A-label encoding of the domain name is included as a dNSName in the SAN

Hi Corey.  The discussion at https://github.com/zmap/zlint/issues/601 has so far reached the opposite conclusion.  Would you mind reviewing https://github.com/zmap/zlint/issues/601#issuecomment-841168368 and explaining in more detail why you disagree?

ISTM that "no normative changes to the allowed encoding of values in the CN field since ballot 202 was voted on" assumes that ballot 202 only intended to change the rules, whereas IIRC the main intention of ballot 202 was to clarify existing rules by stating them more explicitly in the BRs.

It's unfortunate that ballot 202 failed, because it means we have to dig a bit deeper to articulate what the current rules actually are.

---

From: 'Corey Bonnell' via dev-secur...@mozilla.org
Sent: Friday, May 14, 2021 21:49
To: Michel Le Bihan; dev-secur...@mozilla.org
Subject: RE: Are U-labels allowed in CN?

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/DM6PR14MB2186A826B44E9847649C0A7D92509%40DM6PR14MB2186.namprd14.prod.outlook.com.

[Corey Bonnell]

Hi Rob,

Responses inline.

 

> Hi Corey.  The discussion at https://github.com/zmap/zlint/issues/601 has so far reached the opposite conclusion.  Would you mind reviewing https://github.com/zmap/zlint/issues/601#issuecomment-841168368 and explaining in more detail why you disagree?

 

Yes, I reviewed the zlint issue discussion prior to posting here last week. Since Michel continued the conversation here, I thought mdsp is the most appropriate forum to discuss.

 

While your interpretation that the encoding of the CN value and dNSName must be byte-for-byte identical is a reasonable interpretation, it also reasonable to interpret the requirement as allowing encoding of U-labels, provided that the equivalent A-label encoding is contained in a dNSName. As I mentioned in my previous email, the proposed prohibition on this practice was one of the reasons why the ballot failed and no Root Programs stated that the practice was prohibited even in light of the ballot failure.

 

> ISTM that "no normative changes to the allowed encoding of values in the CN field since ballot 202 was voted on" assumes that ballot 202 only intended to change the rules, whereas IIRC the main intention of ballot 202 was to clarify existing rules by stating them more explicitly in the BRs.

 

I don’t believe this is accurate. Ballot 202 proposed introducing new requirements such as a prohibition on issuing certificates for domain names that contain hyphens as the third and fourth character but do not contain “xn” as the first two characters of a label (i.e., a prohibition on issuance of domain names that contain R-LDH labels that are not XN-labels). I know of no prohibition in force now for such labels, as they conform to preferred name syntax.

 

> It's unfortunate that ballot 202 failed, because it means we have to dig a bit deeper to articulate what the current rules actually are.

 

100% agreed. I’d be happy to work on a replacement ballot to clear these rules up.

 

Thanks,

Corey

[Rob Stradling]

> it also reasonable to interpret the requirement as allowing encoding of U-labels, provided that the equivalent A-label encoding is contained in a dNSName.

Hi Corey.  I'm struggling to see how that can be a reasonable interpretation, given the Defined Terms and the nature of DNS.

> > ISTM that "no normative changes to the allowed encoding of values in the CN field since ballot 202 was voted on" assumes that ballot 202 only intended to change the rules, whereas IIRC the main intention of ballot 202 was to clarify existing rules by stating them more explicitly in the BRs.

>

> I don’t believe this is accurate. Ballot 202 proposed introducing new requirements such as a prohibition on issuing certificates for domain names that contain hyphens as the third and fourth character but do not contain “xn” as the first two characters of a label (i.e., a prohibition on issuance of domain names that contain R-LDH labels that are not XN-labels). I know of no prohibition in force now for such labels, as they conform to preferred name syntax.

Note that I wrote "the main intention...was to clarify", not "the only intention...was to clarify".  FWIW, I think that what I wrote is consistent with the summary of ballot 202:

https://archive.cabforum.org/pipermail/public/2017-July/011651.html (emphasis mine)

'The current Baseline Requirements do not expressly allow underscore characters in Subject Alternative Names. This ballot seeks to clarify that one or more underscore characters (“_”) are allowed in FQDNs. In many places it also replaces the term "FQDN" with "Domain Name" because "Domain Name" now means either "FQDN" or "Wildcard Domain Name". The ballot clarifies validation of wildcard domain names. It also cleans up some of the language in Sections 3.2.2.4 and 7.1.4.2.1 of the Baseline Requirements.'

---

From: Corey Bonnell
Sent: Thursday, May 20, 2021 13:39
To: Rob Stradling
Cc: Michel Le Bihan; dev-secur...@mozilla.org

[Corey Bonnell]

> Hi Corey.  I'm struggling to see how that can be a reasonable interpretation, given the Defined Terms and the nature of DNS.

 

Following this line of logic, the definitions in section 1.6 and the wire format of IPv4 would prohibit the inclusion of IP addresses in the CN and SAN, as the IPv4 protocol does not use the dotted-string notation on the wire. I hope we agree that this is not a reasonable interpretation, and instead would agree that the address forms as encoded in certificates may be in a presentation format that diverges from the on-the-wire encoding.

 

> Note that I wrote "the main intention...was to clarify", not "the only intention...was to clarify".  FWIW, I think that what I wrote is consistent with the summary of ballot 202:

 

<snip>

 

I agree insomuch as there were clarifications on the allowance of existing practice as well as new restrictions proposed in ballot 202. However, given that the prohibition on expressing U-labels in the CN and including non-XN R-LDH labels in dNSNames were new restrictions, I don’t see how one can reasonably argue that one practice is currently prohibited and the other currently allowed as result of ballot 202 failing to pass absent further discussion or clarification by Root Programs on these issues.

[Kurt Roeckx]

On Thu, May 20, 2021 at 11:28:46AM +0000, Rob Stradling wrote:
> Corey wrote:
> > I’m inclined to agree with you and Kurt that U-labels are allowed, provided that the corresponding A-label encoding of the domain name is included as a dNSName in the SAN
>
> Hi Corey. The discussion at https://github.com/zmap/zlint/issues/601 has so far reached the opposite conclusion. Would you mind reviewing https://github.com/zmap/zlint/issues/601#issuecomment-841168368 and explaining in more detail why you disagree?

I think the text "is one of the values" means that if the CN
contains a U-label, it should translate to one of the A-labels in
the SAN.

The CN is a DirectoryString, so a TeletexString, PrintableString,
UniversalString, UTF8String or BMPString. The SAN on the other
hand is an IA5String. They clearly have a different purpose. The
one in the SAN is identical to the one that will be used in
protocols, so an A-label. The one in the CN can be display to a
user, so a U-label would be more useful.

There does not seem to be any text that says the CN should be a
U-label or a A-label. I think a U-label makes more sense.

The CN has been deprecated for a very long time, maybe it's time
to actually stop using it.


Kurt

[Ryan Sleevi]

On Thu, May 20, 2021 at 1:31 PM Kurt Roeckx <ku...@roeckx.be> wrote:

On Thu, May 20, 2021 at 11:28:46AM +0000, Rob Stradling wrote:
> Corey wrote:
> > I’m inclined to agree with you and Kurt that U-labels are allowed, provided that the corresponding A-label encoding of the domain name is included as a dNSName in the SAN
>
> Hi Corey.  The discussion at https://github.com/zmap/zlint/issues/601 has so far reached the opposite conclusion.  Would you mind reviewing https://github.com/zmap/zlint/issues/601#issuecomment-841168368 and explaining in more detail why you disagree?

I think the text "is one of the values" means that if the CN
contains a U-label, it should translate to one of the A-labels in
the SAN.

Using which translation algorithm? UTF46? IDNA2003? IDNA2008?

And what if the TLS/PKI using application is using a different translation algorithm?

When RFC 2818 was specified, only A-Labels were permitted. Implementations only supported A-Labels for verification. The use of U-Labels, or the nature of the string type itself, was completely irrelevant, for both 2818 and 2459/3280.

When 5280 was specified, after IDNA2003 (RFC 3490) was finished, there are very clear rules in Section 7.1 as to where IDNs may occur:

   Internationalized Domain Names (IDNs) may be included in certificates
   and CRLs in the subjectAltName and issuerAltName extensions, name
   constraints extension, authority information access extension,
   subject information access extension, CRL distribution points
   extension, and issuing distribution point extension.

Note that it does not say they may occur within the commonName field. The "may" here is functioning as an extensible allowlist - and the omission of commonName is neither accidental (it was deprecated) nor a sign it's OK to do whatever you want for other fields. This is functionally the same language that was had with ECC and keyUsages, and the resolution there was the same as what's being said here: the omission is a sign it's not permitted.

Any CA issuing with U-Labels is a CA that is introducing security issues to relying parties, because to display the commonName is to potentially display a value other than the actual verified name. Some may want to dismiss that as simply inconsequential differences between IDNA2003 and IDNA2008, or that the risks are somehow minor, but that's entirely incorrect. For example, it overlooks the significant effort by RP applications, including Firefox and Chrome, to reduce the risk of homoglyph and mixed-script attacks in how it's presented to users.

It's true, we could eliminate this security issue entirely by refusing to display the certificate, or any data provided by CAs in the certificate, as part of relying party applications. And that has its own compelling benefits that may make it beneficial. But to the extent that CAs are partners in keeping software vendors' users secure, failing to recognize how choices by the CA put those users at risk is quite telling on the CA.

I'm only aware of a single application that ever supported U-Labels within the CN, which was never a specified behaviour, and that is Microsoft, which as best I can tell, did not support IDNA2003/2008/UTS46 but a custom algorithm based on their own criteria (although with significant compatibility with 2003/UTS46, which is unsurprising).

At the core, it seems this is the typical debate between members of this community: "If no one explicitly said I couldn't, that means I can" vs "If no one ever defined, specified, or explicitly allowed what I'm doing, does that mean I can't". Regardless of your perspective on default-allow vs default-deny, the expectation from members of this community has generally been "We expect CAs to act beyond reproach and to take into consideration the security issues raised".

Ballot 202 was, as Rob highlights, an attempt to clarify the logical consequences of existing requirements, and to consider allowing things which were implicitly not permitted to be explicitly permitted. This is similar to CABForum Ballot SC12, which resulted because CAs ignored the discussion of 202, and the existing requirements not permitting things, and continued to do the forbidden thing. SC12 clarified by making it explicit what was already forbidden, while also adding (briefly) an allowance/relaxation to make temporarily permitted what was already implicitly forbidden. It would be a shame if we have to do another such ballot to say U-Labels are explicitly prohibited, when they are already implicitly prohibited.

[Kurt Roeckx]

On Thu, May 20, 2021 at 04:01:52PM -0400, Ryan Sleevi wrote:
> On Thu, May 20, 2021 at 1:31 PM Kurt Roeckx <ku...@roeckx.be> wrote:
>
> > On Thu, May 20, 2021 at 11:28:46AM +0000, Rob Stradling wrote:
> > > Corey wrote:
> > > > I’m inclined to agree with you and Kurt that U-labels are allowed,
> > provided that the corresponding A-label encoding of the domain name is
> > included as a dNSName in the SAN
> > >
> > > Hi Corey. The discussion at https://github.com/zmap/zlint/issues/601
> > has so far reached the opposite conclusion. Would you mind reviewing
> > https://github.com/zmap/zlint/issues/601#issuecomment-841168368 and
> > explaining in more detail why you disagree?
> >
> > I think the text "is one of the values" means that if the CN
> > contains a U-label, it should translate to one of the A-labels in
> > the SAN.
> >
>
> Using which translation algorithm? UTF46? IDNA2003? IDNA2008?

I'm not sure why you ask, and then go and say it's IDNA2003.

> When 5280 was specified, after IDNA2003 (RFC 3490) was finished, there are

> *very* clear rules in Section 7.1 as to where IDNs may occur:

>
> > Internationalized Domain Names (IDNs) may be included in certificates
> > and CRLs in the subjectAltName and issuerAltName extensions, name
> > constraints extension, authority information access extension,
> > subject information access extension, CRL distribution points
> > extension, and issuing distribution point extension.

You're quoting 7.2, which is about GeneralNames. CommonName is not
a GeneralName.

In 7.1 it says:
Standard naming attributes, such as common name, employ the
DirectoryString type, which supports internationalized names through
a variety of language encodings.


Kurt

[Ryan Sleevi]

On Thu, May 20, 2021 at 11:32 AM Kurt Roeckx <ku...@roeckx.be> wrote:

> Using which translation algorithm? UTF46? IDNA2003? IDNA2008?

I'm not sure why you ask, and then go and say it's IDNA2003.

The “why” is covered in the Ballot 202 discussion, and the security implications.

You're quoting 7.2, which is about GeneralNames.

Apologies, yes, this was a typo for the section reference, but you seem to have missed the point. Section 7.1 is *not* about internationalized domain names, as both it and Section 7.3 make clear. The BRs do not allow domainComponent, for quite some time.

Put differently: Internationalized Names are a broad component and cover the whole of naming things, and internationalized domain names, such as U-labels, are an explicit subset of that with defined characteristics (7.2 and 7.3). The comparison of 7.1, using StringPrep, is about refining how internationalized names (such as surname) are compared within certificates and the directory, and is largely not implement in PKI implementations. But that is not somehow an allowance for commonName in TLS to take on U-Labels.

[Corey Bonnell]

Hi Ryan,

Comments inline.

 

> Any CA issuing with U-Labels is a CA that is introducing security issues to relying parties, because to display the commonName is to potentially display a value other than the actual verified name. Some may want to dismiss that as simply inconsequential differences between IDNA2003 and IDNA2008, or that the risks are somehow minor, but that's entirely incorrect.

 

I agree that encoding a U-label representation of a domain name in the CN that produces different A-labels depending on the version of IDNA is a security concern, especially if the CN-ID is used to perform hostname verification. However, for many writing systems in the world, the “ToAscii” algorithm for IDNA 2003, 2008, and UTS46 yield the same set of A-labels when native script is used in U-labels, so this particular security concern does not manifest in many cases.

 

> It would be a shame if we have to do another such ballot to say U-Labels are explicitly prohibited, when they are already implicitly prohibited.

 

This seems strange to me. If there’s a security concern – especially one that has a different risk profile depending on language used by Subscribers/RPs -- then we should amend policy to fix it. Declaring that this practice is universally insecure and “implicitly prohibited” deep in a random thread of a newsgroup likely will not have the desired effect. Clear guidance is the best way to address these issues.

 

Thanks,

Corey

[Ryan Sleevi]

On Fri, May 21, 2021 at 9:43 AM Corey Bonnell <Corey....@digicert.com> wrote:

> It would be a shame if we have to do another such ballot to say U-Labels are explicitly prohibited, when they are already implicitly prohibited.

 

This seems strange to me. If there’s a security concern – especially one that has a different risk profile depending on language used by Subscribers/RPs -- then we should amend policy to fix it. Declaring that this practice is universally insecure and “implicitly prohibited” deep in a random thread of a newsgroup likely will not have the desired effect. Clear guidance is the best way to address these issues.

Clear guidance like widely used linting tools that enforce this, and discussion about this point in the CA/Browser Forum during the discussion of Ballot 202 about precisely these conclusions?

I think you're trying to say that, yes, just like underscores made us repeat the existing technical requirements, the U-Label issue also needs to restate the existing technical requirements. The profiles work, unfortunately, is largely a restatement of existing technical requirements, which some CAs have still found unclear. At what point, however, do we stop restating existing requirements, and can reasonably place an expectation on CAs to work through them themselves?

[Kurt Roeckx]

On Thu, May 20, 2021 at 03:44:18PM -1000, Ryan Sleevi wrote:
> On Thu, May 20, 2021 at 11:32 AM Kurt Roeckx <ku...@roeckx.be> wrote:
>
> > > Using which translation algorithm? UTF46? IDNA2003? IDNA2008?
> >
> > I'm not sure why you ask, and then go and say it's IDNA2003.
>
>
> The “why” is covered in the Ballot 202 discussion, and the security
> implications.

I can't find anything relevant in ballot 202 or the discussion
about it. Can you point to something relevant?

> > You're quoting 7.2, which is about GeneralNames.
>
>
> Apologies, yes, this was a typo for the section reference, but you seem to
> have missed the point.

I think you missed the point. You seem to argue that 7.2 has
a list of the only places where an IDN can be used. But that
section is limited to only GeneralNames. It does not cover
something like a distinguished name.

> Section 7.1 is *not* about internationalized domain
> names, as both it and Section 7.3 make clear. The BRs do not allow
> domainComponent, for quite some time.

Section 7.1 is about internationalized names, which, according to
section 7, includes internationalized domain names. It does not at
all make it clear that you can't put a internationalized domain
name in any of the fields it mentions. Section 7.3, like section
7.2, is about a specific field that does not allow encoding a
U-label.

Section 7.2 is very clear that if you convert an international
domain name to put it in a SAN, you must convert it using IDNA2003.
And if you want to display it, you should convert it to Unicode
using IDNA2003.

I don't see anything implying that you can't put a U-label in
commonName. Both A-label and U-label seem to be allowed.

The BR requirement that the CN must be in the SAN seems to imply
that the CN should be a U-label, since there is no requirement
on the CN to convert it from an A-label to a U-label for display.

Displaying only the U-label can have a security impact, but having
to look at the CN to see if you're connected to the correct host
looks more problematic to me, and an A-label is most likely not
going to help at all.


Kurt

[Ryan Sleevi]

On Sat, May 22, 2021 at 1:29 AM Kurt Roeckx <ku...@roeckx.be> wrote:

I think you missed the point.

My previous reply specifically addresses the points you are still raising here.

Given that we are at a point where nothing new is being contributed, it seems we’ve reached the end of productive discussion.

As I previously addressed, you seem to be taking the position that, despite very specific requirements on how and where internationalized domain names appear, CAs are free to invent their own new methods ad-hoc (“default allow”). As has long been the case in this community, that approach has been very poorly received - as we see with some CAs existing, open incident reports, and unless something is explicitly permitted, CAs should operate from an assumption that it is forbidden.

7.1 does *not* allow for U-Labels in the commonName, nor have they *ever* been allowed. 7.2 and 7.3 describe how IDNs appear within SANs and DNs, as RFC 8399 makes abundantly clear within its introduction, particularly the second paragraph.

Your entire argument is simply “I don’t see it prohibited” (which, as I point out, it is, clearly), when the entire point for all CAs is that if you don’t see something clearly *permitted*, you’re already in dangerous territory. For this case of U-Labels in CN, you won’t find it, because they aren’t allowed, nor have they ever been.

[Peter Bowen]

On Sat, May 22, 2021 at 10:13 AM Ryan Sleevi <ry...@sleevi.com> wrote:
> As I previously addressed, you seem to be taking the position that, despite very specific requirements on how and where internationalized domain names appear, CAs are free to invent their own new methods ad-hoc (“default allow”). As has long been the case in this community, that approach has been very poorly received - as we see with some CAs existing, open incident reports, and unless something is explicitly permitted, CAs should operate from an assumption that it is forbidden.
>
> 7.1 does *not* allow for U-Labels in the commonName, nor have they *ever* been allowed. 7.2 and 7.3 describe how IDNs appear within SANs and DNs, as RFC 8399 makes abundantly clear within its introduction, particularly the second paragraph.
>
> Your entire argument is simply “I don’t see it prohibited” (which, as I point out, it is, clearly), when the entire point for all CAs is that if you don’t see something clearly *permitted*, you’re already in dangerous territory. For this case of U-Labels in CN, you won’t find it, because they aren’t allowed, nor have they ever been.

Ryan,

Have been one of the authors of ballot 202, I think you are over
stating the state a bit. As I found when writing certlint, there are
many places where terms are undefined or underdefined in the BRs. One
of these is "fully qualified domain name". RFC 5280 does not address
the contents of the common name attribute. RFC 5890
(https://datatracker.ietf.org/doc/html/rfc5890#section-4.2) makes it
clear that a fully-qualified domain name may contain U-labels. It also
makes clear that "label", when used standalone, includes both
U-labels, A-labels, and more.

As to earlier comments about IDN2003, IDN2008, and UTS46, it is
important to remember that the places where these vary are in
conversion of a Unicode string to a Punycode string. Going the other
direction, such as taking a dNSName-type name from the
SubjectAlternativeName and converting to Unicode, has remained
consistent. So it is possible to validate that the commonName is
equivalent to a dNSName-type SAN in all cases.

Thanks,
Peter

[Kurt Roeckx]

On Sat, May 22, 2021 at 07:12:53AM -1000, Ryan Sleevi wrote:
>
> 7.1 does *not* allow for U-Labels in the commonName, nor have they *ever*
> been allowed. 7.2 and 7.3 describe how IDNs appear within SANs and DNs, as
> RFC 8399 makes abundantly clear within its introduction, particularly the
> second paragraph.

To be correct, a commonName never has a domain name in it, so
it can't contain an IDN, U-label or A-label. It's just a name.
Since the CN never contains any domain name, I fail to see how
it can be "abundantly clear" that it should contain an A-label.

The BRs says it should be one of the values of values of the
SAN, without any details on how to do that.

The only guidance we have is that for displaying it to the user
we should (or SHOULD in RFC 8399) convert it a U-label. Just like
we convert an IP address from a binary value to a string for a
human.

Note that the BRs do not adopt RFC 8399 or 8398, they're based on
RFC 5280.

> Your entire argument is simply “I don’t see it prohibited” (which, as I
> point out, it is, clearly), when the entire point for all CAs is that if
> you don’t see something clearly *permitted*, you’re already in dangerous
> territory. For this case of U-Labels in CN, you won’t find it, because they
> aren’t allowed, nor have they ever been.

I see no text that permits to use of A-labels in a CN.


Kurt

[Ryan Sleevi]

On Sat, May 22, 2021 at 9:24 AM Kurt Roeckx <ku...@roeckx.be> wrote:

Note that the BRs do not adopt RFC 8399 or 8398, they're based on
RFC 5280.

I see we are fully doubling down on rehashing past discussions of the Forum in this thread. It’s unclear if this is a bad faith attempt to do so, or if it’s just genuine ignorance of the applicability of the BRs due to not being a CA, but in any event, your statement is wrong.

The BRs incorporate 8398 and 8399, just as they do 6818, 5480, or 8813. This was, in part, discussed during 202 and why I previously mentioned the IDNA2003/2008 issues, and previously been discussed as whether or not it was necessarily to explicitly reference every RFC that was incorporated by reference, such as 3279 and 4055, and the process by which the IETF manages and amends these documents.

> Your entire argument is simply “I don’t see it prohibited” (which, as I
> point out, it is, clearly), when the entire point for all CAs is that if
> you don’t see something clearly *permitted*, you’re already in dangerous
> territory. For this case of U-Labels in CN, you won’t find it, because they
> aren’t allowed, nor have they ever been.

I see no text that permits to use of A-labels in a CN.

🙄

While this appears to be trolling in order to justify misissuance, it’s so deeply problematic as it deserves a reply. Inevitably, zero sympathy or trust would be placed in a CA making such an argument, but those without CA affiliations arguing such bad faith statements inevitably undermines the security of all users, and thus demands a response, precisely so that CAs are not misguided into thinking it’s somehow reasonable or legitimate a position. It equally seems unlikely that you are earnest in your position that it SHOULD be allowed to use U-Labels, at least based on the replies to date, and so it’s unclear if the interest here is anything more than in playing word games that have real and harmful consequences to end-users. Why someone would want to take such unjustified positions is unclear, because it certainly does not help model the behavior that is to be expected of CAs, nor does it help improve the security of users.

You can find this language in BRs 7.1.4.2.2 (a), RFC 2818, and RFC 6125.

[Kurt Roeckx]

On Sat, May 22, 2021 at 10:08:59AM -1000, Ryan Sleevi wrote:
> On Sat, May 22, 2021 at 9:24 AM Kurt Roeckx <ku...@roeckx.be> wrote:
>
> > Note that the BRs do not adopt RFC 8399 or 8398, they're based on
> > RFC 5280.
>
> I see we are fully doubling down on rehashing past discussions of the Forum
> in this thread. It’s unclear if this is a bad faith attempt to do so

Please assume that whatever I write is in good faith. I'm trying
to understand things. Your attitude does not help. I explicitly
asked about a link to a discussion related to ballot 202 and IDNA
2003/2008.

> You can find this language in BRs 7.1.4.2.2 (a), RFC 2818, and RFC 6125.

RFC 6125 says in section 6.4.2 that a CN can have a U-label.


Kurt

[Ryan Sleevi]

On Sat, May 22, 2021 at 10:50 AM Kurt Roeckx <ku...@roeckx.be> wrote:

Please assume that whatever I write is in good faith. I'm trying
to understand things. Your attitude does not help.

Nor does stating absolutes about the BRs. There’s a difference between asking whether 5480, or subsequent IETF documents that update and replace text of unambiguously in-scope documents are covered by the BRs and definitively stating they are not.

> You can find this language in BRs 7.1.4.2.2 (a), RFC 2818, and RFC 6125.

RFC 6125 says in section 6.4.2 that a CN can have a U-label.

Could you clarify what portion of text you believe states this?

6.4.2 is discussing the reference identifier, which is the client-held identity, not the presented identifier, which is what the server presents in its certificate. Explicitly, the process of the client is that it must convert the U-Labels it has to ACE, and perform the comparison against the presented identifiers - which are always ACE, as covered by 5280 - as an ASCII comparison.

You do not convert U-Labels in presented identifiers to ACE, nor do you compare U-Labels to U-Labels (e.g. as Microsoft did/does): you compare A-Label to A-Label by normalizing everything to ACE.

This process is covered as part of 6.2.1 - the client construction of reference identifiers is wholly independent of the server’s presentation.

[Kurt Roeckx]

On Sat, May 22, 2021 at 11:02:31AM -1000, Ryan Sleevi wrote:
> On Sat, May 22, 2021 at 10:50 AM Kurt Roeckx <ku...@roeckx.be> wrote:
>
> > Please assume that whatever I write is in good faith. I'm trying
> > to understand things. Your attitude does not help.
>
> Nor does stating absolutes about the BRs. There’s a difference between
> asking whether 5480, or subsequent IETF documents that update and replace
> text of unambiguously in-scope documents are covered by the BRs and
> definitively stating they are not.

If you think I'm wrong, you can explain why I'm wrong, pointing to a
document or some other discussion, or ask me to explain it. But most
of the time you don't do that and seem to resolve to tone that I
can only describe as not constructive and not welcoming any
discussion.

> > You can find this language in BRs 7.1.4.2.2 (a), RFC 2818, and RFC 6125.
> >
> > RFC 6125 says in section 6.4.2 that a CN can have a U-label.
>
> Could you clarify what portion of text you believe states this?

I misunderstood that text. That document expects an A-label in the
CN.


Kurt

[Ryan Sleevi]

On Sat, May 22, 2021 at 11:51 AM Kurt Roeckx <ku...@roeckx.be> wrote:

If you think I'm wrong, you can explain why I'm wrong, pointing to a
document or some other discussion, or ask me to explain it. But most
of the time you don't do that and seem to resolve to tone that I
can only describe as not constructive and not welcoming any
discussion.

This is because Brandolini’s Law makes it unfortunately asymmetric to correct these issues, especially when a trivial search with “site:cabforum.org” turns up past discussions, such as:

- Apple: 

https://archive.cabforum.org/pipermail/public/2017-July/043341.html

- Google: 

https://archive.cabforum.org/pipermail/public/2016-January/006632.html

Or discussions such as 

https://lists.cabforum.org/pipermail/servercert-wg/2019-October/001318.html 

and https://archive.cabforum.org/pipermail/public/2016-February/038462.html

You can see from the timestamps on the messages that these are not new discussions, nor are new points being raised. It’s just rehashing and relitigating, and doing so in a way that is stating in absolute how things are, rather than questions, and when they’ve previously been clarified, repeatedly.

Is it fair to expect you to have been contemporaneously familiar with the discussions? No, of course not. Is it reasonable to have expected you to spend five to ten minutes looking for these past discussions, once it was pointed out that they existed? It seems so. Was all of the discussion fully captured on the public lists? Unfortunately, not always, due to inconsistency of minutes especially for the spirited discussions. But the conclusions were and are stated there.

However, the seeming lack of doing the basic search, and the confidence in the (wrong) answer, is exactly what we would say is problematic for CAs to do. We rightfully take CAs to task when they don’t research past discussions or compliance incidents before applying their own (flawed) interpretations. We expect CAs to be familiar with the broad picture and the interconnection of contextual history, such 2818/3280 predating IDNs, and thus being implicitly A-labels by virtue of the non-existence of U-Labels.

We would not and should not tolerate CAs acting as literal genies when it benefits them, but as just a simple caveman lawyer when it might prohibit things. While we should certainly work to ensure things are clear, it’s not just reasonable, but essential, to hold CAs to higher standards, and that’s why “Devil’s Advocate” discussions are so dangerous: it has the effect of legitimizing those problematic behaviours and justifying lowering the bar.

Do I fault the OP for asking the question? Of course not! But do I fault the confidence of the wrong answer, without the recognition of the harm being done and confusion being actively reintroduced in to a long settled matter? Yes.

[Corey Bonnell]

> Clear guidance like widely used linting tools that enforce this, and discussion about this point in the CA/Browser Forum during the discussion of Ballot 202 about precisely these conclusions?

 

Again, I find this approach to defining policy to be strange and likely ineffective. This community has long frowned upon “the linter didn’t catch this” as rationale for why compliance incidents occurred, so suggesting that CAs should rely on linter results does not align with previous discussion. Nor does it assuage concerns of non-compliance that is currently not checked by linters today.

 

As to why the ballot 202 discussions are insufficient guidance to CAs on whether U-labels are prohibited in CN, one needs to look no further than this post [1] here on MDSP, which Mozilla stated a full year after ballot 202 failed that encoding U-labels in the CN is not a policy violation. Given this, I cannot agree that this practice is clearly prohibited. If we decide that it should be prohibited (which I’d be on board with), then we should resurrect ballot 202 and explicitly state the expectations.

 

Thanks,

Corey

 

[1] https://groups.google.com/g/mozilla.dev.security.policy/c/LdYPWj1SCGM/m/NeVL3mwsAAAJ

 

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Friday, May 21, 2021 1:11 PM
To: Corey Bonnell <Corey....@digicert.com>

Cc: ry...@sleevi.com; Kurt Roeckx <ku...@roeckx.be>; Rob Stradling <r...@sectigo.com>; Michel Le Bihan <michel.le...@gmail.com>; dev-secur...@mozilla.org
Subject: Re: Are U-labels allowed in CN?

 

 

 

On Fri, May 21, 2021 at 9:43 AM Corey Bonnell <Corey....@digicert.com> wrote:

[Kurt Roeckx]

On Sat, May 22, 2021 at 12:34:25PM -1000, Ryan Sleevi wrote:
> On Sat, May 22, 2021 at 11:51 AM Kurt Roeckx <ku...@roeckx.be> wrote:
>
> > If you think I'm wrong, you can explain why I'm wrong, pointing to a
> > document or some other discussion, or ask me to explain it. But most
> > of the time you don't do that and seem to resolve to tone that I
> > can only describe as not constructive and not welcoming any
> > discussion.
>
>

> Brandolini’s Law

I consider this passive aggressive behaviour. Which is at least
better than calling me a troll.

> However, the seeming lack of doing the basic search, and the confidence in
> the (wrong) answer, is exactly what we would say is problematic for CAs to
> do. We rightfully take CAs to task when they don’t research past
> discussions or compliance incidents before applying their own (flawed)
> interpretations. We expect CAs to be familiar with the broad picture and
> the interconnection of contextual history, such 2818/3280 predating IDNs,
> and thus being implicitly A-labels by virtue of the non-existence of
> U-Labels.

Like always, I've spend time researching this. I'm sorry that I do
not agree with you.

Clearly there has not been a consensus about this and other
things. People have indicating it needs to be clarified.

Technically, A-labels did not exist either. I would expect you to
say that before RFC 5280 A-labels weren't allowed. I think the use
of an A-label when RFC 5280 didn't exist is a bad idea.

Also, RFC 5280 obsoletes RFC 3280, which in turn obsoletes RFC
2459. So to understand RFC 5280, there is no need to understand
the others.

> We would not and should not tolerate CAs acting as literal genies when it
> benefits them, but as just a simple caveman lawyer when it might prohibit
> things. While we should certainly work to ensure things are clear, it’s not
> just reasonable, but essential, to hold CAs to higher standards, and that’s
> why “Devil’s Advocate” discussions are so dangerous: it has the effect of
> legitimizing those problematic behaviours and justifying lowering the bar.
>
> Do I fault the OP for asking the question? Of course not! But do I fault
> the confidence of the wrong answer, without the recognition of the harm
> being done and confusion being actively reintroduced in to a long settled
> matter? Yes.

I think your continued message of "hold CAs to higher standards"
and the tone of your messages if someone doesn't agree with you is
stopping CAs from participating in discussions, and so learning to
understand things. I think your confidence in what you think is the
correct answer combined with the tone of your message is also
harmful.


Kurt

[Kurt Roeckx]

On Fri, May 21, 2021 at 01:11:01PM -0400, Ryan Sleevi wrote:
>
> Clear guidance like widely used linting tools that enforce this, and

I actually removed that check in x509lint in 2016, I don't plan
to re-add it until a document is published that clarifies it.


Kurt

[Ryan Sleevi]

On Mon, May 24, 2021 at 3:22 AM Corey Bonnell <Corey....@digicert.com> wrote:

> Clear guidance like widely used linting tools that enforce this, and discussion about this point in the CA/Browser Forum during the discussion of Ballot 202 about precisely these conclusions?

Just to make sure we’re on the same page here:

- Clear statements from a root program before a ballot

- Ballot that attempts to clarify, with universal browser support but CAs objecting, because they wanted to redefine policy in ways browsers did not find acceptable

- Clear statements from a root program after said ballot

- Clear statements from RFCs

But because someone asked the question again, you don’t agree that it’s clear enough. Certainly, the failure of the ballot by CAs has zero bearing on root program expectations.

I can certainly understand and appreciate that it’s not clear enough for some CAs, but there’s a difference here between “It is prohibited/permitted” and “I have to read 3 RFCs vs just the BRs, so we should make the BRs clearer”, and I certainly hope you’re not attempting, as others have incorrectly done, to argue it’s permitted.

As it relates to the lint itself, which is what started this discussion, this thread has the receipts when it comes to what standard CAs are being held to. If Mozilla has chosen to ignore a requirement of the BRs - as they are free to do and have done so in the past, with a number of CAs - that doesn’t change the BRs.

[Corey Bonnell]

> If Mozilla has chosen to ignore a requirement of the BRs - as they are free to do and have done so in the past, with a number of CAs - that doesn’t change the BRs.

 

Are you asserting that Mozilla has granted an exception to CAs for this supposed violation of the BRs?

 

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Monday, May 24, 2021 1:17 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: Kurt Roeckx <ku...@roeckx.be>; Michel Le Bihan <michel.le...@gmail.com>; Rob Stradling <r...@sectigo.com>; dev-secur...@mozilla.org; ry...@sleevi.com
Subject: Re: Are U-labels allowed in CN?

 

 

 

On Mon, May 24, 2021 at 3:22 AM Corey Bonnell <Corey....@digicert.com> wrote:

[Ryan Sleevi]

On Mon, May 24, 2021 at 4:10 AM Kurt Roeckx <ku...@roeckx.be> wrote:

> Brandolini’s Law

I consider this passive aggressive behaviour. Which is at least
better than calling me a troll.

Continually stating factually wrong things, then demanding they are valid or true if not corrected, and tone policing when they are corrected, is indistinguishable from trolling.

Like always, I've spend time researching this. I'm sorry that I do
not agree with you.

I don’t think there’s been any evidence to support your researching, given by the complete lack of citations here, or the repeated factually wrong statements.

But similarly, this approach isn’t whether you agree with me, no more than saying “fake news” somehow makes the truth unreal. The ample evidence of the expectations, unambiguous, from root programs is there, and from that perspective, this is settled.

Simply saying you interpret up to be down does not make it true. Are there contextual situations where up may be down, such as “when floating in space”? Sure. But if you’re going to argue that, you bear the burden to demonstrate that contextual sense with supporting language that is consistent, which you haven’t done. In the limited situation where you’ve offered support for your misinterpretation, you’ve consistently taken language out of the context of the document and framework it is written in. When you talk about ignoring 3280/2459, or what the state of the world was when these documents were written, you’re simply inventing a fiction to support your flawed understanding, and then claiming it is real, or that things aren’t clear.

To put it differently, it would be as if saying in the sentence “Geschirrspülmaschine is a German word for dishwasher”, that because “Geschirrspülmaschine” is not an English word, it is undefined, underdefined, devoid of meaning, or could mean anything because it’s not an English word, even as the sentence itself places both the context and the definition right in front of the reader.

The latest reply is an example of this, in which arguments about A-Labels are quite simply made up, and used to justify completely wrong statements, as if that’s somehow a reply. I suspect that, as with reaching the complete opposite conclusion of RFC 6125, this is similarly a mistake of reading the RFCs. That is, to suggest because a spec uses the definition of the “preferred name syntax” (the LDH rule) is to somehow exclude a subset of that, simply because it did not name all the subsets, is as silly as it is insulting.

Clearly there has not been a consensus about this and other
things.

The BRs are not a popularity contest, nor are they an opportunity for exegetical remixing. They are a reflection of root programs expectations for CAs, codified in a way that can be audited to provide assurance to those root programs’ needs. The root programs are the ultimate arbiters of this. If any element of text is unclear, it is, at best, a personal relationship between the CA and the entity consuming the audit report, such as the root program, to clarify.

Statements like this are unquestionably why auditors have issue releasing more details in their audit reports, because they are worried about an unskilled population misrepresenting their audit reports when they are not party to the interpretations and understanding. And I do sympathize with their concerns, even if some are overblown. There is benefit to making sure you, as a member of the community, reach the same understanding as the root program and the CA, so that you can ensure the root program reflects your needs, but that does not make you an equivalent interested party with respect to defining expectations.

I think your continued message of "hold CAs to higher standards"
and the tone of your messages if someone doesn't agree with you is
stopping CAs from participating in discussions, and so learning to
understand things. I think your confidence in what you think is the
correct answer combined with the tone of your message is also
harmful.

I think this remark is rooted in what I’ve highlighted above: a belief that your interpretation is just as valid as root programs’ clearly stated expectations.

From a CA, this is unacceptable behavior - and quite problematic where we have several open incidents where CAs are doing just that: stating unambiguous requirements were somehow ambiguous or subject to interpretation, ignoring past incidents, discussion, and relevant context in order to justify it.

From a non-CA, when there is ample evidence to the contrary, as both referenced and now provided, it’s simply contrarianism that attempts to relitigate settled decisions to no productive end.

If you would like to make a constructive contribution, then the point of discussion is not endlessly (and incorrectly) debating “Is this allowed” (Answer: No, it is not, this is settled as prohibited), nor “Should this be allowed” (Answer: No, there are clear risks), but rather, “Should anything be done to make this clearer, and if so, what?”

Again, this isn’t pedantry, nor is it trying to deny you the opportunity to contribute and have a voice. However, it would be deeply problematic to continue to assert something was permitted when a Mozilla CA communication made clear was unquestionably prohibited, such as issuing a MITM CA. Yet that is what you’re effectively doing here, with respect to U-Labels rather than MITM, and doubling down on it.

If this was something new and original, and there was a compelling case to be made for different interpretations, it’s entirely reasonable that the response may be different here. But this isn’t - this is a rehash of a debate long settled, with no new arguments, and a complete disregard for the past arguments. And at that point, it goes from the good faith question of the OP, to wanting to relitigate past decisions.

[Ryan Sleevi]

On Mon, May 24, 2021 at 7:44 AM Corey Bonnell <Corey....@digicert.com> wrote:

> If Mozilla has chosen to ignore a requirement of the BRs - as they are free to do and have done so in the past, with a number of CAs - that doesn’t change the BRs.

 

Are you asserting that Mozilla has granted an exception to CAs for this supposed violation of the BRs?

That is up to Mozilla to clarify the past remark. As both Apple and Google highlighted both before and after Ballot 202, the language of the BRs and the RFCs do not permit U-Labels.

[Matthew Hardeman]

I wonder how much of these discussions could be avoided if the root programs and CA/B Forum came together to design a compliance linter which took inputs such as:

1.  The proposed TBS certificate.

2.  The intended use-case / profile (ex:  WebPki -> Leaf/EE Certificate -> TLS Server + TLS Client)\

And then the tool provided the maximum amount of technical compliance analysis and in the event that no exceptions as to proper form are found it spits out a list of those caveats and stipulations to compliance which would be applicable.  (This contains DNS names, these are subject to validation per BR rules x - y and CAA policy checking, etc, etc.)

The tool would be versioned, root programs could align policy changes to the tools' revisions.  It seems like so much could be resolved technologically with an agreed firm implementation rather than rules lawyering.

The full scope of determining compliance checking for a given issuance would be:

1.  The approved pre-issuance tool as of this issuance was Linter version X.

2.  This is an end-entity cert subordinate to an included root with the TLS Server trust bit.

3.  The tool said this cert looks good subject to the following caveats.

4.  Evaluate the truth and support for the required stipulations reported by the tool.

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHHTE2h5NLBzF2FPEQ5-dmNMxy90b2us5CqeE7kLBUt4PA%40mail.gmail.com.

[Ryan Sleevi]

On Mon, May 24, 2021 at 10:31 AM Matthew Hardeman <mhar...@gmail.com> wrote:

I wonder how much of these discussions could be avoided if the root programs and CA/B Forum came together to design a compliance linter which took inputs such as:

Nowhere near enough, given how many requirements are independent of the TBSCertificate (e.g. policies and procedures). Those technical elements are already being tackled by the profiles work in the Forum, as much as possible.

However, the approach of “If the tool accepts it, it must be right” is a fundamentally flawed approach. It’s the same argument we’d see 5-7 years ago from CAs, “But OpenSSL didn’t complain about it,” as if that made it technically correct. The current status with linters are “If it’s known bad, we say it, but that doesn’t mean it’s definitely good” is a better position, and reflects the reality of the complexity of exhaustive ness - which is why CAs are expected to layer multiple controls (particularly Certlint and zlint, to cover both ASN.1/syntactic linting and semantic linting, respectively).

The reality is that to go to the natural extreme of that, in which a “pass” means “Cannot be challenged as wrong,” the inevitable necessity is to simplify as much as possible, and prune as many unrelated features or unnecessary flexibility. This would require removing much of the legacy baggage of X.509, and ASN.1, and despite the significance of that effort, would be less than trying to get to a “guaranteed good” linter using today’s frameworks.

[Corey Bonnell]

> That is up to Mozilla to clarify the past remark. As both Apple and Google highlighted both before and after Ballot 202, the language of the BRs and the RFCs do not permit U-Labels.

 

Ryan, I cannot agree with you that Google has made a clear statement concerning the prohibition on U-labels in the CN. In this message [1] on cabfpub (dated 2018-05-23, almost 10 months after the ballot 202 failure), the Chrome root program representative stated:

 

“CAs that encode in U-Label unfortunately facilitate greater

confusion, and thus are discouraged (and, should that ballot be brought

forward, forbidden) from doing so :)”

 

This is a clear statement that absent the passage of a further ballot, CAs are discouraged (but not forbidden) from encoding U-labels in the CN.

 

I want to raise this not to defend the practice of encoding U-labels in CN (conversely, the practice should go away), but obligating CAs to follow statements that are documented solely in a collection of mailing list posts that span several years and are seemingly contradictory to previous statements is a highly ineffective and dangerous way to state policy.

 

It is ineffective because it is very unlikely that any of the points raised will be incorporated into guidance for auditors and it is also highly unlikely that all CAs will share the same interpretation of messages that carry nuance. For example, in the post you directed Kurt to in early 2016 concerning the initial discussion of U-labels in CN, the Google Root program representative stated his interpretation “with my strict interpretation hat on”, which means it is not an absolute statement and/or conveys uncertainty and is not intended to be immediately actionable guidance for CAs. Similarly, the message from Apple after ballot 202 failed that you linked to contains similar indications of uncertainty, namely prefacing the entire message with “my understanding”. I hope we can agree that proper policies we expect to be followed must not contain such nuanced, uncertain language.

 

Similarly, treating random messages from Root Program representatives from various mailing lists as policy statements is dangerous. As we all know, messages in spirited discussions may be done in haste and not consider all relevant details, especially as the group’s shared understanding of the topic builds. Only through clearly stated documents that have undergone the appropriate review should policy be expressed. Expecting otherwise invites disaster, especially if a Root Program representative makes a statement that is based on a flawed understanding or incomplete information at the start or middle of a discussion.

 

Perhaps a crazy idea, but I think organizations that hold the literal keys to the Internet should be operated according to a set of well documented and understood policy documents and not a random assortment of mailing list posts that may or not may not be accurate or applicable today.

 

Thanks,

Corey

 

[1] https://lists.cabforum.org/pipermail/public/2018-May/045090.html

 

From: Ryan Sleevi <ry...@sleevi.com>
Sent: Monday, May 24, 2021 2:05 PM
To: Corey Bonnell <Corey....@digicert.com>
Cc: dev-secur...@mozilla.org
Subject: Re: Are U-labels allowed in CN?

 

 

 

On Mon, May 24, 2021 at 7:44 AM Corey Bonnell <Corey....@digicert.com> wrote:

[Brian Smith]

'Corey Bonnell' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

[O]bligating CAs to follow statements that are documented solely in a collection of mailing list posts that span several years and are seemingly contradictory to previous statements is a highly ineffective and dangerous way to state policy.

I agree. It's not reasonable to require people to read this mailing list to understand the policy. The baseline requirements and related documents are the only normative statement of policy. It would be unreasonable to make the mailing list contents part of the policy.

When the baseline requirements are unclear, like they are with this u-label thing, the result should be a ballot on a change to the wording of the baseline requirements such that the new wording is clear, and then a vote. Without that, the discussion on the mailing list is mostly a waste of time.

Because of the difficulty with the different versions of IDNA and versions of the Unicode standard, and because putting anything in the subject common name field is already deprecated in 7.1.4.2.2, I think the only resolution that makes sense is a ballot that clarifies the baseline requirements wording to require that any domain name in the subject common name field be a character-for-character match of a dNSName entry present in the subjectAltName field.

More generally, the cabforum documents are poorly written. There are tons of places in the documents where vague language is used, when instead precise language could be used. There are a lot of omissions. This is why there are these long discussions. The baseline requirements, at least, need to be rewritten to serve as a specification for software, written by software developers for software developers. Then there wouldn't be disagreements like this.

Cheers,

Brian