[Servercert-wg] Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Fri Feb 28 14:58:54 MST 2020
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
> <mailto: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
>> <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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200228/190ff19a/attachment-0001.html>
More information about the Servercert-wg
mailing list