[Servercert-wg] Question on BR 3.2.2.6

Thu Feb 27 12:18:12 MST 2020

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” 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 <https://crt.sh/?id=2929505&opt=cablint,zlint.> &opt=cablint,zlint. Interestingly, zlint does not flag this error.

Thanks,

Corey Bonnell 
Software Architect

 <http://www.securetrust.com/> www.securetrust.com

 <https://securetrust.com/resources/library/documents/2019-global-compliance-report/> 2019 Global Compliance Intelligence Report

From: Pedro FUENTES <pfuentes at WISEKEY.COM> 
Sent: Thursday, February 27, 2020 2:02 PM
To: Corey Bonnell <CBonnell at securetrust.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>; Adriano Santoni <adriano.santoni at staff.aruba.it>
Subject: Re: [Servercert-wg] Question on BR 3.2.2.6

Hi Corey,

Thanks for this. 

For the sake of my further enlightenment... can you please point me to the explicit paragraph where it says the the period is not permitted in DNS names? I’m having a hard time to find it. 

This is inconsistent with other sources I checked in the past. Just to put something I found right now using Google we could see examples with period in https://docs.aws.amazon.com/it_it/acm-pca/latest/userguide/name_constraints.html <https://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CIBEZKQLxA&s=5&u=https%3a%2f%2fdocs%2eaws%2eamazon%2ecom%2fit%5fit%2facm-pca%2flatest%2fuserguide%2fname%5fconstraints%2ehtml> 

My main concern would be that a constraint like “gov.XX” could also allow a dns like “www.nogov.XX <http://www.nogov.XX> ”... but I could be misinterpreting the whole thing. 

Best,

Pedro

Le 27 févr. 2020 à 19:32, Corey Bonnell <CBonnell at securetrust.com <mailto:CBonnell at securetrust.com> > a écrit :

Hi Pedro,

I’d like to point out that dNSName GeneralNames in the nameConstraints extension do not have a preceding period (“.”). Per RFC 5280 section 4.2.1.10 (https://tools.ietf.org/html/rfc5280#section-4.2.1.10 <https://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CN9DZvVdww&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc5280%23section-4%2e2%2e1%2e10> ), the preceding period can only be expressed in URIs and rfc822Names. Therefore, the correct encoding is “gov.XX”.

Thanks,

Corey Bonnell 
Software Architect

<image001.png>

 <http://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CNpANfYMkg&s=5&u=http%3a%2f%2fwww%2esecuretrust%2ecom%2f> www.securetrust.com

 <https://securetrust.com/resources/library/documents/2019-global-compliance-report/> 2019 Global Compliance Intelligence Report

From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Pedro FUENTES via Servercert-wg
Sent: Thursday, February 27, 2020 10:27 AM
To: Adriano Santoni <adriano.santoni at staff.aruba.it <mailto:adriano.santoni at staff.aruba.it> >; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Subject: Re: [Servercert-wg] Question on BR 3.2.2.6

Thanks, Adriano. 

You’re right, as the name constraint would appear as “.gov.XX” in the CA certificate, but in BR 7.1.5 it’s said that the DNS name constraints must be validated as mandated in 3.2.2.4, and from that is why I make the reference to 3.2.2.6, as from a validation standpoint I’d say that this type of name constraint is to be considered the same as a wildcard.

Best,

Pedro

El 27 feb 2020, a las 16:17, Adriano Santoni via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > escribió:

Pedro,

in a CA certificate, one would not insert a wildcard in Name Constraints, as it's not needed (per https://tools.ietf.org/html/rfc5280#section-4.2.1.10 <https://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CN9DZvVdww&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc5280%23section-4%2e2%2e1%2e10> ) and probably not even allowed, although RFC5280 does not explicitly forbid it. In your example, it would suffice to include "gov.XX".

That said, I understand that domain control validation for domains listed in a CA certificate (in the Name Constraints extension) must be done by the same methods used for Subscriber certificates, per BR 3.2.2.4 (see the "Note" before 3.2.2.4.1).

Adriano

Il 27/02/2020 15:44, Pedro FUENTES via Servercert-wg ha scritto:

Dear all, 

Sorry if this is not the appropriate way to do things, but I’m a newbie in the Forum, so please be indulgent.

BR 3.2.2.6 says:

“If a wildcard would fall within the label immediately to the left of a registry-controlled1 or public suffix, CAs MUST refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue “*.co.uk <http://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CIAVNaddkw&s=5&u=http%3a%2f%2fco%2euk%2f> ” or “*.local”, but MAY issue “*.example.com <http://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CI4TN_YIkA&s=5&u=http%3a%2f%2fexample%2ecom%2f> ” to Example Co.).”

I’ll have a comment and a question regarding the above...

Comment: In my humble opinion, the wording of that paragraph seems incorrect, as a “MUST” or "MUST NOT” that is conditioned to certain exceptions seem more appropriate to be stated as “SHOULD” or “SHOULD NOT”.

Question: Considering the allowed exception (“unless the applicant proves its rightful control of the entire Domain Namespace”), and in particular thinking on a wildcard of the type “*.gov.XX” used as a name constraint in a CA certificate (and not for a wildcard TLS certificate)... Has been discussed in the past what is an acceptable method to prove this control? Would any method allowed by BR 3.2.2.4 be enough (e.g. agreed change in DNS)?

I’d appreciate to be enlightened with positive comments on the above.

Thanks,

Pedro

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  <http://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CIkWNPMMzg&s=5&u=http%3a%2f%2fwww%2ewisekey%2ecom%2f> WISeKey

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://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CNtAZaFWkw&s=5&u=http%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fservercert-wg> 

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org> 
http://cabforum.org/mailman/listinfo/servercert-wg <http://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CNtAZaFWkw&s=5&u=http%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fservercert-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  <http://scanmail.trustwave.com/?c=4062&d=y5LY3vZrfs_PBNlgvI50S82iXQdFUWF_CIkRMaYIlw&s=5&u=http%3a%2f%2fwww%2ewisekey%2ecom> WISeKey

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/20200227/d5b19d2c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 10027 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200227/d5b19d2c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4947 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200227/d5b19d2c/attachment-0001.p7s>