[cabfpub] Ballot 189 - Amend Section 6.1.7 of Baseline Requirements

[Dimitris Zacharopoulos]

On 30/3/2017 10:51 μμ, Ryan Sleevi wrote:
>
> On Thu, Mar 30, 2017 at 2:40 PM, Dimitris Zacharopoulos 
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
>     It removes the "e.g" that was causing the confusion. At least that
>     was the outcome from the previous discussion. it-kp-timeStamping
>     is not included in the specific exceptions (administrative role
>     certificates, Internal CA operational device certificates)
>
>
> Sure, I apologize that I wasn't clearer. I'm asking what was the goal 
> of changing
>
> "Root CA Private Keys MUST NOT be used to sign Certificates except in 
> the following cases:"
>
> to
> "Private Keys corresponding to Root Certificates that participate in a 
> hierarchy that issues Certificates with an extKeyUsage extension that 
> includes the value id-kp-serverAuth [RFC5280] MUST NOT be used to sign 
> Certificates except in the following cases:"
>
> And whether that was necessary. It sounds like removing the e.g. does 
> exactly what you want, so why the extra change above?
>

The reason for this language was to have a clear scope on which Root CA 
Certificates are affected by this rule.

For example, if there is a Root CA Certificate that is in a hierarchy 
that does not issue SSL Certificates (say it is enabled by Root programs 
only for id-kp-emailProtection or id-kp-codeSigning), it might be 
possible to issue timestamping certificates directly from these Roots. I 
don't have any strong feelings about this so we could remove the long 
sentence. How about:

"Private Keys corresponding to Root Certificates MUST NOT be used to 
sign Certificates except in the following cases:

 1. Self-signed Certificates to represent the Root CA itself;
 2. Certificates for Subordinate CAs and Cross Certificates;
 3. Certificates for infrastructure purposes (administrative role
    certificates, internal CA operational device certificates)
 4. Certificates for OCSP Response verification;"

Anyone who might object to this change?


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170330/a4e0d7a1/attachment-0003.html>