> Von: Ryan Sleevi <r...@sleevi.com> 
>> On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus 
>> <mailto:rufus.busch...@siemens.com> wrote:
>>> Von: Ryan Sleevi <mailto:r...@sleevi.com> 
>>> 
>>> The CA can perform ToASCII(ToUnicode(label)) == label to validate.
>>
>> Sorry to be picky, but this check only proofs that a label is a valid IDNA 
>> label but not that it is _not_ a weird server name.
>
> Picky is good! Obviously I'm very picky ;)
> 
> What's not clear to me is why that distinction is relevant, particularly on 
> the validation side of things. IDNA-aware software will,
> by virtue of being IDNA-aware, treat it as an A-label if it's a valid ACE 
> label with the ACE prefix, and, correspondingly, transform
> into a U-Label if they see it as appropriate. From the discussion you were 
> having with Jakob, it's not clear the relevance of that
> point about 'weird hostname' vs 'U-label' - perhaps I missed something?

At the end, it all comes down to the question, whether a CA software has to be 
IDNA aware or not. This question can be divided in two separate sub-questions:

1) MUST a CA software be IDNA aware?
2) SHOULD a CA software be IDNA aware?

Regarding 1: Ballot 202 wanted to make IDNA awareness a strict requirement for 
any CA. Ballot 202 failed, therefor it should be clear, that a CA can choose 
whether to be IDNA aware or not.
Regarding 2: Due to bullet 1 this is a business decision of any CA and I 
believe there are good reasons simply to be ignorant towards IDNA naming 
syntax, because you can't tell if this is just a weird host name or an A-label.

==> As a conclusion I believe any bug that was opened due to the issuance of 
certificates that include hostnames which could be read as an A-label should be 
rejected, as long as the A-label was validated (and all other rules of the 
BRGs, etc. are followed).

/Rufus
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to