[Servercert-wg] Question on BR 3.2.2.6

Fri Feb 28 04:18:50 MST 2020

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 <mailto: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 
>> <http://example.com/>” issued a cert for “example.com 
>> <http://example.com/>”, valuation would fail, while a cert issued for 
>> “www.example.com <http://www.example.com/>” would pass.
>> If a CA with a name constraint of “example.com <http://example.com/>” 
>> issued a cert for “example.com <http://example.com/>”, valuation 
>> would pass, alongside a cert issued for “www.example.com 
>> <http://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 <mailto: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 <mailto:servercert-wg at cabforum.org>> wrote:
>>>
>>>     It’s a PKI footgun for sure, but here’s the relevant paragraph
>>>     from4.2.1.10 <http://4.2.1.10/>:
>>>
>>>     “DNS name restrictions are expressed ashost.example.com
>>>     <http://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 <http://www.host.example.com/>would
>>>     satisfy the constraint but
>>>
>>>     host1.example.com <http://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 <http://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 <mailto:Servercert-wg at cabforum.org>
>>> http://cabforum.org/mailman/listinfo/servercert-wg
>>
>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org <mailto: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 <http://www.wisekey.com>
> *
> *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/8dbb6554/attachment-0001.html>