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

[Ryan Sleevi]

I'm not sure what you're asking, Dimitris. Could you clarify what "this" is?

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/03fad5ee/attachment-0001.html>