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

Tue Mar 3 01:36:30 MST 2020

Hello,

On my side… I’d be keen to align with #2, as I think it’s the way to go, but for that we’d need some objective data to assess the impact and be sure we aren’t shooting in our foot… Do we have any idea of what software nowadays would reject certificates or would malfunction if we enforce the critical thing?

Just as a side comment… In our case, we mostly used name constraints for subordinates intended for "S/MIME certificates" (in reality this means "personal certificates used for authentication, digital signature and secure email", but let’s go for the over-simplified term “S/MIME Certificates” I see it’s used in the Forum) so assuming a rule that is only considering “the webPKI” is maybe not something appropriate. We must see interoperability as a whole as these decisions won't only impact TLS certs, because this rule of the BR applies to all subordinates, not only the ones having the serverAuth EKU.

Best,
Pedro

> El 3 mar 2020, a las 8:19, Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org> escribió:
> 
> 
> 
> 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 <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:
> CAs are just not using name constraints so they don't care about the outcome
> 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 <https://cabforum.org/pipermail/servercert-wg/2019-October/001196.html> (for example, see https://cabforum.org/pipermail/servercert-wg/2019-October/001208.html <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 <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 from 4.2.1.10 <http://4.2.1.10/>:
>>>>>>> 
>>>>>>>  
>>>>>>> “DNS name restrictions are expressed as host.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. <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 <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 <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 <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 <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 <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
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/20200303/4788e3c4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2498 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200303/4788e3c4/attachment-0001.p7s>