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

[Pedro FUENTES]

Hello,

As a reminder, when I raised this point that triggered the discussion I said this in regards to the possible impact of setting this extension as critical, saying that this should be decided thinking also on other uses than TLS certs, so now that it seems agreed that it really has impact on all subordinate certificates, maybe a possible solution is to modify BR 7.1.2.2…

Where it says…
f. nameConstraints (optional)
If present, this extension SHOULD be marked critical*

It could say (assuming that now EKU is mandatory for new subCAs)…
f. nameConstraints (optional)
If present:
- if the EKU includes serverAuthentication, this extension MUST be marked critical
- if the EKU doesn’t include serverAuthentication, this extension SHOULD be marked critical*

Just my two cents, so see if this helps… For sure it needs properly wording… 

Anyway, I’d say that we’d still need some objective criteria to decide about changing the BR or not, based on the impact in the TLS and non-TLS worlds… Tadahiko-san was making reference in the parallel discussion about the “betterTLS project”, but I don’t know if we have data in the impact on other popular applications, like email clients. If at the end we realize that the current applications treat properly the extension, maybe it can be enforced without any exception or condition.

Best
Pedro

> El 4 mar 2020, a las 23:16, Paul Hoffman via Servercert-wg <servercert-wg at cabforum.org> escribió:
> 
> On Mar 4, 2020, at 2:03 PM, Kurt Roeckx via Servercert-wg <servercert-wg at cabforum.org> wrote:
>> 
>> On Wed, Mar 04, 2020 at 06:36:04PM +0000, Keshwarsingh Nadan via Servercert-wg wrote:
>>>> The question is about what a Root CA, unambiguously in-scope of the BRs, is allowed to sign. Can it sign a "thing" (as I hesitate to call it a Certificate) that violates RFC 5280? Is that permitted for any CA in scope? Because that's what is being proposed by saying nameConstraints on an S/MIME Sub-CA can be non-critical.
>>> 
>>> Technically yes, a Root CA can sign a “thing” or “any|thing” and would not violate RFC5280 as RFC in itself is not a standard. BRs are built using RFC as a building block.
>> 
>> RFC5280 is a standard. RFC5280 doesn't really limit the CA for
>> signing things, it leaves that to the CA to have a policy about
>> it, and the user to review that policy. But RFC5280 does have
>> some requirements about things like the format of a certificates.
>> 
>> But we're discussion the BRs here. It places limits on the policy
>> of the CA, among other things which certicates it can sign. It
>> clearly can not sign anything it wants.
> 
> To be pedantic here, the BRs should place limits on what the private key associated with CA member's public key can be used for. A CA will likely have many public/private key pairs, only some of which will be used by CABForum relying parties. All public/private key pairs that are covered by the BRs should absolutely have limits put on their use.
> 
> (We had similar discussions to this in the careful word formulations for RFCs 2549, 3280, and 5280.)
> 
> --Paul Hoffman_______________________________________________
> Servercert-wg mailing list
> 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/20200305/e5d0a0db/attachment.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/20200305/e5d0a0db/attachment.p7s>