I also believe that any publicly supported and documented X.509 extension (e.g. defined by IETF or ITU-T) are allowed for use by CAs, as long as they are documented in the CA's CPS.
Is there anything that prevents it in the current CA/B Forum documents? Thanks, DZ. Jan 10, 2024 20:38:19 Tim Hollebeek via Smcwg-public <smcwg-public@cabforum.org>: > You don’t need a contract to have a right to use someone else’s extension. > > I would say that if Microsoft has public documentation that says or implies > that the extension can and should be used by other organizations, then other > organizations “have the right” to use that extension. > > That said, I have never liked this language, which comes from the TLS BRs. I > would support making it more clear as to what is and isn’t allowed, and even > maybe clarifying what problem is being solved with these requirements. > > -Tim > > *From:* Smcwg-public <smcwg-public-boun...@cabforum.org> *On Behalf Of > *Martijn Katerbarg via Smcwg-public > *Sent:* Wednesday, January 10, 2024 5:54 AM > *To:* SMIME Certificate Working Group <smcwg-public@cabforum.org> > *Subject:* [Smcwg-public] Certificate Template Information extension and SBR > allowance > > Hi all, > > There’s been a request within the S/MIME working group to bring forward > issues that have arisen since the adoption of the SBRs. While we’ve not seen > a whole lot of issues, we believe we may have discovered one now. > > We offer support for Windows’s own auto-enrollment features. In the past we > used to include the “Certificate Template Information” extension (OID > 1.3.6.1.4.1.311.21.7) for this purpose. Since we started issuing SBR > compliant certificates prior to September 1st, we removed support for this > extension on publicly trusted S/MIME certificates. > > As we now have noticed, this has led to a partial breakdown of the > auto-enrollment system. From what we understand, the auto-enrollment > mechanism is specifically looking for this extension in certificates, if a > certificate for a particular required Certificate Template (as specified > through AD) is not found, auto-enrollment will “do its job”, and request a > new certificate. This can lead to multiple new certificates being installed > in a single day, all because the extension is missing. > > We’ve investigated bringing back support for the extension, and are led to > the conclusion that no, this extension would not be allowed per the current > language. A breakdown: > > Section 7.1.2.4 > (https://github.com/cabforum/smime/blob/main/SBR.md#7124-all-certificates[https://url.avanan.click/v2/___https:/github.com/cabforum/smime/blob/main/SBR.md%237124-all-certificates___.YXAzOmRpZ2ljZXJ0OmE6bzphYmIxNjU3ZGU1ZTYwODNjM2Q3N2NjOTI2NDlhNTFhNzo2Ojk4ZDE6N2VhYmQyYzcxNDdhYjlhZDExZmE0MDI3ZWVmYzEyNDY0YzM5YjI1Yzc0NjEzZmUwZTU2MGJjMzhiM2QxMWRjMDpoOkY] > ) states: > /“//All fields and extensions SHALL be set in accordance with RFC > 5280[https://url.avanan.click/v2/___https:/datatracker.ietf.org/doc/html/rfc5280___.YXAzOmRpZ2ljZXJ0OmE6bzphYmIxNjU3ZGU1ZTYwODNjM2Q3N2NjOTI2NDlhNTFhNzo2OmIzZWM6YWE0NTVlYmI4ZDk2OWMwMzJkZmQ1NzM5YzE3YzAwOGUyOGFiYWE2ZTMyNDA4YWY4YTc2MzQyZWVlNDNlMjIzNTpoOkY]. > The CA SHALL NOT issue a Certificate that contains a /*/keyUsage/*/ flag, > /*/extKeyUsage/*/ value, Certificate extension, or other data not specified > in Section > 7.1.2.1[https://url.avanan.click/v2/___https:/github.com/cabforum/smime/blob/main/SBR.md%237121-root-ca-certificates___.YXAzOmRpZ2ljZXJ0OmE6bzphYmIxNjU3ZGU1ZTYwODNjM2Q3N2NjOTI2NDlhNTFhNzo2OmZjMDg6MzYxZGEyOGIzOWI5YmEzY2Y4MjRiOTczYzlkZGMzYmIyNTk4YWU4ZjRkNTRhNzdmNGNlNGI4Y2E3MGZhOGVjZDpoOkY], > Section > 7.1.2.2[https://url.avanan.click/v2/___https:/github.com/cabforum/smime/blob/main/SBR.md%237122-subordinate-ca-certificates___.YXAzOmRpZ2ljZXJ0OmE6bzphYmIxNjU3ZGU1ZTYwODNjM2Q3N2NjOTI2NDlhNTFhNzo2OmU0MTg6MzE4Mzc4YTg4NThmMzMxOWY3Yjk3OGM1MmMyNzgzNTNkYzRiMmRiNTg4NWM0YmFlOTQ4MDAyZTMxZWQyYWY0NzpoOkY], > or Section > 7.1.2.3[https://url.avanan.click/v2/___https:/github.com/cabforum/smime/blob/main/SBR.md%237123-subscriber-certificates___.YXAzOmRpZ2ljZXJ0OmE6bzphYmIxNjU3ZGU1ZTYwODNjM2Q3N2NjOTI2NDlhNTFhNzo2OmRmM2E6ZDE5OTU5Yjg2ODJhYmVkOGZhYjUzMDcwNGY3MDNiZTQ2ZTQ3YTkxMWQ1NjE0OGMxOTJmNjQwYmIxNTI0ZDAwZjpoOkY] > unless the CA is aware of a reason for including the data in the > Certificate. If the CA includes fields or extensions in a Certificate that > are not specified but are otherwise permitted by these Requirements, then the > CA SHALL document the processes and procedures that the CA employs for the > validation of information contained in such fields and extensions in its CP > and/or CPS.”/ > > So far, we could see allowing the extension. We have “a reason for including > the data in the Certificate”, and we could update our CPS. However, the > language continues with an additional SHALL NOT: > > /“//CAs SHALL NOT issue a Certificate with:/ > > 1. /Extensions that do not apply in the context of the public Internet (such > as an //extKeyUsage// value for a service that is only valid in the context > of a privately managed network), unless: > i. such value falls within an OID arc for which the Applicant demonstrates > ownership, or > ii. the Applicant can otherwise demonstrate the right to assert the data in a > public context; or/ > 2. /Field or extension values which have not been validated according to the > processes and procedures described in these Requirements or the CA's CP > and/or CPS//./” > So while the first section might allow us to incorporate the extension, it > seems we also need to meet one of the statements in this block: > “/Extensions that do not apply in the context of the public Internet (such as > an //extKeyUsage// value for a service that is only valid in the context of a > privately managed network), unless://” > /This extension indeed does not apply in the context of the public Internet. > So, we move into the exception cases: > /”//i. such value falls within an OID arc for which the Applicant > demonstrates ownership, or//” > /No. Neither us, nor the Applicant owns the OID. It’s an OID under the > Microsoft OID arc. > ”/ //ii. the Applicant can otherwise demonstrate the right to assert the data > in a public context; or//” > /Unless the Applicant gets a contract stating they were given the right by > Microsoft, we don’t see how this requirement is met. > Then we’re left with “/Field or extension values which have not been > validated according to the processes and procedures described in these > Requirements or the CA's CP and/or CPS.” > /This one is a bit odd. Does this suddenly suggest or imply that the CA may > include any field or extension that has been validated according only to the > CA’s CP and/or CPS? Item “(ii)” ends with an “or”. However, we believe this > is an incorrect editorial bit that should be updated, since the list shifts > back to a previous indentation. > All in all, we’re left with the understanding that, no, this extension is not > allowed (with the exception that if Microsoft were to be the Applicant, it > would be allowed). > With this breakdown, we’re left with a few questions: > * Have other CAs run into the same issue? > * Do other CAs share the same conclusion? > * If this does appear to be an issue, should an extension by the platform of > one of our Certificate Consumers, be specifically added as an allowed > extension? > Regards, > > Martijn > Sectigo
_______________________________________________ Smcwg-public mailing list Smcwg-public@cabforum.org https://lists.cabforum.org/mailman/listinfo/smcwg-public
