[Servercert-wg] Critical Name Constraints (Was: Re: Question on BR 3.2.2.6)
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Tue Mar 3 00:19:38 MST 2020
On 2020-02-29 12:30 π.μ., Ryan Sleevi wrote:
> 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.
I'd first like to remind people about the previous thread
(https://cabforum.org/pipermail/servercert-wg/2019-October/001196.html).
It was a rather short thread, comparing to other much longer discussions
:-) Most Members have been silent on this topic and I'm still trying to
figure out which of the following is true:
1. CAs are just not using name constraints so they don't care about the
outcome
2. CAs are using name constraints and are ok with forcing the extension
to be "critical".
Having been involved with name constraints for years, I find it very
difficult to see the latter being true.
HARICA uses name constraints for several subCAs. Over the years we have
seen implementations in opensource tools/applications/services that
would break if the extension was critical. We still see legacy systems
and unsupported software using TLS Certificates. Some of our Subscribers
complain that certain Relying Parties with old and unsupported devices
can't browse sites. These are all cases that would have availability
issues with TLS.
On the other hand, Certificate Consumers that account for the majority
of the webPKI (those participating in the SCWG), already honor and use
this extension, thus the majority of the webPKI Relying Parties are
currently protected. What benefit would the WebPKI have if this
extension was forced to be "critical", other than just removing an
"exception" to an RFC?
Dimitris.
>
> On Fri, Feb 28, 2020 at 4:59 PM Dimitris Zacharopoulos (HARICA)
> <dzacharo at harica.gr <mailto: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
>> <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/20200303/c3303079/attachment-0001.html>
More information about the Servercert-wg
mailing list