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

[Ryan Sleevi]

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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200228/771f2a51/attachment-0001.html>