Hi Peter, > it is not fully clear to me how the P-label construct differs from the > A-label construct in RFC 5890
My understanding is that both U-labels and A-labels must contain
IDNA(2008)-valid strings. Section 2.3.1 of 5890 says:
"Some strings that are prefixed with "xn--" to form labels may not be
the output of the Punycode algorithm, may fail the other tests
outlined below, or may violate other IDNA restrictions and thus are
also not valid IDNA labels. They are called "Fake A-labels" for
convenience."
Section 2.3.2.1 defines "IDNA-valid" as:
"A string is "IDNA-valid" if it meets all of the requirements of
these specifications for an IDNA label. IDNA-valid strings may
appear in either of the two forms defined immediately below, or
may be drawn from the NR-LDH label subset."
The same section defines A-label as:
"An "A-label" is the ASCII-Compatible Encoding (ACE, see
Section 2.3.2.5) form of an IDNA-valid string."
Given this, any label that is valid under UTS-46 but not IDNA2008 cannot be
called a "U-label" or "A-label". The lowest common denominator between
IDNA2003, 2008, and UTS-46 for ACE labels is that they all contain valid output
of the Punycode algorithm, which is why the CA/Browser Forum coined the term
"P-label" to encompass labels that contain valid output of the Punycode
algorithm but may fail the other checks prescribed by IDNA2008. I have
attempted to capture this in the PR:
https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/88/files#diff-2c24bab3daea8d575b90f4179372ebc69ca9d57b807e5588ac05ba9bcfa94891R439.
CAs that comply with the CA/Browser Forum Baseline Requirements are permitted
to encode only NR-LDH or P-labels in SAN dNSNames, so there is at least
assurance that valid output of the Punycode algorithm is contained in labels
that start with "xn--" in the SAN of WebPKI certificates issued today. This is
certainly sub-optimal from the standpoint of adherence to the IDNA2008
specification, but unfortunately is the most interoperable given the wide
variation in domain registration practices and client handling of IDNs today.
Thanks,
Corey
-----Original Message-----
From: Uta <uta-boun...@ietf.org> On Behalf Of Peter Saint-Andre
Sent: Wednesday, February 1, 2023 6:59 PM
To: uta@ietf.org
Cc: p...@paftech.se; John C Klensin <john-i...@jck.com>
Subject: Re: [Uta] Consensus call for proposed changes to
draft-ietf-uta-rfc6125bis-10
On 2/1/23 6:17 AM, Corey Bonnell wrote:
> I think it would be unfortunate if the usage of terms that are defined
> in RFC 5890 is not aligned with their definitions.
>
> If we are not opposed to introducing new terminology to the document,
> then I suggest the following:
>
> 1. Replace all instances of "A-label" with the term "P-label" from the
> CABF Baseline Requirements [1]: "P-Label: A XN-Label that contains
> valid output of the Punycode algorithm (as defined in RFC 3492,
> Section 6.3) from the fifth and subsequent positions."
> 2. For U-label:
> a. Punt and call it "Unicode representation" instead (this is what
> the CABF Baseline Requirements does, although that may not be
> appropriate for this document).
> b. Create a new term that is defined as "A non-LDH label that
> contains valid output of the decoding algorithm for Punycode (as
> defined in RFC 3492, Section 6.2)." and use this new term instead of
> "U-label".
>
> I'd be happy to work on concrete text to this effect if there's
> agreement this is a good path to resolve the issue.
I would very much like to hear what John Klensin and Patrik Fältström
(cc'd) think about this proposal.
As noted in my other message
<https://mailarchive.ietf.org/arch/msg/uta/92tKoHT3Kjll1o_mCYQYQT8xON4/>
I'm not immediately comfortable with referencing a CA/Browser Forum document
instead of RFC 5890.
Having looked at Corey's proposal more closely, I'm doubly unsure because (a)
it is not fully clear to me how the P-label construct differs from the A-label
construct in RFC 5890 and (b) coming up with new DNS-related terminology in a
late-stage document about certificate validation just seems like a bad idea
(e.g., I'm not sure how to get proper review) even if it were necessary (which
I'm not sure it is).
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
