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

[Ryan Sleevi]

Dimitris,

I'm unclear on your goals with #2, despite having participated in the
thread.

For example, despite being very familiar with this topic, I must admit, I'm
confused as to what "participate in a hierarchy that issues Certificates
with an extKeyUsage" means.

There's at least two possible readings:
1) From the root, through the intermediates, etc, a certificate is issued
with id-kp-serverAuth. This is the "flow upward" approach, where *if* it's
possible to issue such a certificate, this applies
2) It only applies if the root directly issues such a certificate

There's problems with both interpretations, however
1) As worded, it could be seen as 'not applying' if the server doesn't
_issue_ such a certificate, but is technically capable of doing so.
  That is, consider a root with an anyEKU, an intermediate with an anyEKU,
and a leaf with id-kp-timeStamping. As worded, this would be seen as "out
of scope", while under the existing language, it would be clearly in scope,
which is the desired outcome
2) would be seriously under-scoped, since we know it's rare for such
intermediates to exist


Could you clarify a bit more on the timestamping concern here? The root
MUST NOT sign an id-kp-timeStamping certificate directly, as worded, but
it's unclear if you think that's incorrect and should be permitted.

On Thu, Mar 30, 2017 at 12:22 PM, Dimitris Zacharopoulos via Public <
public at cabforum.org> wrote:

>
> *Ballot 189 - Amend Section 6.1.7 of Baseline Requirements*
>
> The following motion has been proposed by Dimitris Zacharopoulos of HARICA
> and endorsed by Bruce Morton of Entrust and Jeremy Rowley of Digicert
>
> *Background*:
>
> Section 6.1.7 of the Baseline Requirements states that the Root CA Private
> Keys MUST NOT be used to sign end-entity certificates, with some
> exceptions. It is unclear if this exception list includes end-entity
> certificates with EKU id-kp-timeStamping. This ballot attempts to clarify
> two things:
>
>    1. that it affects Root Keys in a hierarchy that issues SSL
>    Certificates and
>    2. that it does not include time stamping certificates in the
>    exception list.
>
> It also clears the exception language for 1024-bit RSA Subscriber
> Certificates and testing products with Certificates issued by a Root.
>
> *-- MOTION BEGINS --*
>
> *Current section 6.1.7*
>
> Root CA Private Keys MUST NOT be used to sign Certificates except in the
> following cases:
>
>    1. Self-signed Certificates to represent the Root Certificate itself;
>    2. Certificates for Subordinate CAs and Cross Certificates;
>    3. Certificates for infrastructure purposes (e.g. administrative role
>    certificates, internal CA operational device certificates, and OCSP
>    Response verification Certificates);
>    4. Certificates issued solely for the purpose of testing products with
>    Certificates issued by a Root CA; and
>    5. Subscriber Certificates, provided that:
>       1. The Root CA uses a 1024-bit RSA signing key that was created
>       prior to the Effective Date;
>       2. The Applicant’s application was deployed prior to the Effective
>       Date;
>       3. The Applicant’s application is in active use by the Applicant or
>       the CA uses a documented process to establish that the Certificate’s use is
>       required by a substantial number of Relying Parties;
>       4. The CA follows a documented process to determine that the
>       Applicant’s application poses no known security risks to Relying Parties;
>       5. The CA documents that the Applicant’s application cannot be
>       patched or replaced without substantial economic outlay.
>       6. The CA signs the Subscriber Certificate on or before June 30,
>       2016; and
>       7. The notBefore field in the Subscriber Certificate has a date on
>       or before June 30, 2016
>
> *Proposed section 6.1.7*
>
> 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:
>
>    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;
>
> *These changes become Effective 30 days after the ballot passes.*
>
> *-- MOTION ENDS --*
>
> The procedure for this ballot is as follows (exact start and end times may
> be adjusted to comply with applicable Bylaws and IPR Agreement):
>
> BALLOT 189 Status: Amend BR 6.1.7
>
> Start time (22:00 UTC)
>
> End time (22:00 UTC)
>
> Discussion (7 days)
>
> 30 March 2017
>
> 6 April 2017
>
> Vote for approval (7 days)
>
> 6 April 2017
>
> 13 April 2017
>
> If vote approves ballot: Review Period (Chair to send Review Notice) (30
> days)
> If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be
> created.
> If no Exclusion Notices filed, ballot becomes effective at end of Review
> Period.
> Votes must be cast by posting an on-list reply to this thread on the
> Public Mail List.
>
> Upon filing of Review Notice by Chair
>
> 30 days after filing of Review Notice by Chair
>
> From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
> Maintenance Guideline, such ballot will include a redline or comparison
> showing the set of changes from the Final Guideline section(s) intended to
> become a Final Maintenance Guideline, and need not include a copy of the
> full set of guidelines. Such redline or comparison shall be made against
> the Final Guideline section(s) as they exist at the time a ballot is
> proposed, and need not take into consideration other ballots that may be
> proposed subsequently, except as provided in Bylaw Section 2.3(j).
>
> Votes must be cast by posting an on-list reply to this thread on the
> Public list. A vote in favor of the motion must indicate a clear 'yes' in
> the response. A vote against must indicate a clear 'no' in the response. A
> vote to abstain must indicate a clear 'abstain' in the response. Unclear
> responses will not be counted. The latest vote received from any
> representative of a voting member before the close of the voting period
> will be counted. Voting members are listed here:
> https://cabforum.org/members/
> In order for the motion to be adopted, two thirds or more of the votes
> cast by members in the CA category and greater than 50% of the votes cast
> by members in the browser category must be in favor. Quorum is shown on
> CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum
> number must participate in the ballot for the ballot to be valid, either by
> voting in favor, voting against, or abstaining.
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170330/f6e96c28/attachment-0003.html>