[Servercert-wg] Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri Feb 28 13:40:25 MST 2020
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
> <mailto: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
>> <mailto: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 <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 <tel:+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 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/c3b26e3d/attachment-0001.html>
More information about the Servercert-wg
mailing list