[Servercert-wg] Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)

[Ryan Sleevi]

I see. That was answered on the original thread. The short answer: No, it
does not, except where it's explicitly designed to break (i.e. why you make
them critical).

If you have data to believe otherwise, different from that shared on the
thread from last year, that would be great to share to be mindful of.

On Fri, Feb 28, 2020 at 4:59 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 2020-02-28 11:37 μ.μ., Ryan Sleevi wrote:
>
> I'm not sure what you're asking, Dimitris. Could you clarify what "this"
> is?
>
>
> I was referring to potentially removing the exception of the BRs
> (7.1.2.2.f) and require the "critical" bit in the nameConstraints extension.
>
> Dimitris.
>
>
> On Fri, Feb 28, 2020 at 3:40 PM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
>>
>> Doesn't this break other legacy SSL/TLS clients (curl, wget)? How about
>> other protocols like IMAP, POP3, LDAP, FTP that use TLS? Maintaining
>> interoperability was always an important issue to consider.
>>
>> Dimitris.
>>
>>
>>
>> On 2020-02-28 9:47 μ.μ., Ryan Sleevi via Servercert-wg wrote:
>>
>> Pedro,
>>
>> You can find more information about applications and their handling of
>> critical vs non-critical name constraints at
>> https://cabforum.org/pipermail/servercert-wg/2019-October/001196.html (for
>> example, see
>> https://cabforum.org/pipermail/servercert-wg/2019-October/001208.html )
>>
>> You can see Apple suggesting a change to remove this RFC 5280 exception
>> might be suitable around 2022 -
>> https://cabforum.org/pipermail/servercert-wg/2019-October/001312.html
>>
>> On Fri, Feb 28, 2020 at 2:38 PM Clint Wilson <clintw at apple.com> wrote:
>>
>>> Hi Pedro,
>>>
>>> This was updated with iOS 9.0 and macOS 10.12; those versions and later
>>> support critical name constraints.
>>>
>>> Thanks!
>>> -Clint
>>>
>>> On Feb 28, 2020, at 2:07 AM, Pedro FUENTES <pfuentes at WISEKEY.COM> 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
>>>> <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
>>> 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 <+41%2022%20594%2030%2000>
>>> 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 listServercert-wg at cabforum.orghttp://cabforum.org/mailman/listinfo/servercert-wg
>>
>>
>> _______________________________________________
>> 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/d04ca4ad/attachment-0001.html>