[Servercert-wg] Question on BR 3.2.2.6

Fri Feb 28 04:41:03 MST 2020

You are right, Dimitris. 

My original question was about validating a namespace of the type “*.gov.XX” and for that I got already enough feedback. 

Now this has become something else, so I guess next person participating in the ongoing discussion about name constraints could change the email subject. 

Best,
Pedro 

> Le 28 févr. 2020 à 12:19, Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr> a écrit :
> 
>  I am not sure if this discussion continues to be related to 3.2.2.6 or the name constraints extension. I suggest starting a separate thread about discussing name constraints in the BRs.
> 
> 
> Thanks,
> Dimitris.
> 
> 
> 
> On 2020-02-28 12:07 μ.μ., Pedro FUENTES via Servercert-wg wrote:
>> Hello,
>> 
>> Actually Apple’s interpretation was the one I had… but I wrongly assumed that “label” could be also understood as a concatenated string at the left, and that it could also pass the test, while I understand now that a “label” must be separated with a period of the allowed name constraint...
>> 
>> BTW, Clint, once you get into this… Has Apple solved the issue that provoked that a the Name Constraints extension marked as critical was giving a “non trusted” error in MacOS and iOS? In the past I think this was the only case that prevented to enforce this rule of the BR and the extension had to be left non-critical in order to work in Apple systems… It would be good to know if this is still an issue.
>> 
>> Thanks,
>> Pedro
>> 
>>> El 28 feb 2020, a las 0:32, Clint Wilson via Servercert-wg <servercert-wg at cabforum.org> escribió:
>>> 
>>> Hi all,
>>> 
>>> Our interpretation of this is that a Name Constraint dNSName which contains a preceding ‘.’ requires one or more additional labels to match the name constraint, while a Name Constraint dNSName which contains no preceding ‘.’ allows zero or more labels.
>>> For example, if a CA with a name constraint of “.example.com” issued a cert for “example.com”, valuation would fail, while a cert issued for “www.example.com” would pass.
>>> If a CA with a name constraint of “example.com” issued a cert for “example.com”, valuation would pass, alongside a cert issued for “www.example.com” passing too.
>>> 
>>> Thanks,
>>> -Clint
>>> 
>>>> On Feb 27, 2020, at 11:35 AM, Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Thu, Feb 27, 2020 at 2:18 PM Corey Bonnell via Servercert-wg <servercert-wg at cabforum.org> wrote:
>>>>> It’s a PKI footgun for sure, but here’s the relevant paragraph from 4.2.1.10:
>>>>> 
>>>>>  
>>>>> 
>>>>> “DNS name restrictions are expressed as host.example.com.  Any DNS
>>>>> 
>>>>>    name that can be constructed by simply adding zero or more labels to
>>>>> 
>>>>>    the left-hand side of the name satisfies the name constraint.  For
>>>>> 
>>>>>    example, www.host.example.com would satisfy the constraint but
>>>>> 
>>>>>    host1.example.com would not.”
>>>>> 
>>>>>  
>>>>> 
>>>>> A dNSName permittedSubtree value of “gov.XX” wouldn’t allow “nogov.XX”, as the matching is done by appending zero or labels to the dNSName and not a simple string concatenation. In other words, “gov.XX” and “www.gov.XX”                                     are permitted, but “nogov.XX” is not.
>>>>> 
>>>>>  
>>>>> 
>>>>> As for the ACM documentation you provided, I don’t think it’s RFC-compliant given the paragraph above. Here’s an example (long-expired) subCA that contains incorrectly encoded nameConstraints (due to the leading period) and cablint complains: https://crt.sh/?id=2929505&opt=cablint,zlint. Interestingly, zlint does not flag this error.
>>>>> 
>>>> 
>>>> Thanks for pointing that out, Corey. I filed https://github.com/zmap/zlint/issues/413 for this, because as you note, it is malformed. 
>>>> <image003.png>_______________________________________________
>>>> Servercert-wg mailing list
>>>> Servercert-wg at cabforum.org
>>>> http://cabforum.org/mailman/listinfo/servercert-wg
>>> 
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> http://cabforum.org/mailman/listinfo/servercert-wg
>> 
>> WISeKey SA
>> Pedro Fuentes
>> CSO - PM eSecurity Solutions
>> Office: + 41 (0) 22 594 30 00
>> Mobile: + 41 (0) 791 274 790
>> Address: 29, Rte de Pré-Bois - CP 853 | Geneva 1215 CH - Switzerland
>> Stay connected with WISeKey
>> 
>> THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks
>> 
>> CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender
>> 
>> DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.
>> 
>> 
>> 
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> http://cabforum.org/mailman/listinfo/servercert-wg
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200228/6e0b547d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3854 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200228/6e0b547d/attachment-0001.p7s>