Re: Google Trust Services - OCSP Generation Error

[David Kluge via dev-security-policy]

Thank you Ryan.

I added both to the bug.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

AW: AW: Incident Report DFN-PKI: Non-IDNA2003 encoded international domain names

[Buschart, Rufus via dev-security-policy]

> Von: Ryan Sleevi  
>> On Fri, Jan 25, 2019 at 2:01 PM Buschart, Rufus 
>>  wrote:
>>> Von: Ryan Sleevi  
>>> 
>>> 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