[cabfpub] Ballot 189 - Amend Section 6.1.7 of Baseline Requirements
Dimitris Zacharopoulos
jimmy at it.auth.gr
Thu Mar 30 17:03:16 UTC 2017
On 30/3/2017 7:49 μμ, Ryan Sleevi wrote:
> 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.
The intention is that it MUST NOT be permitted to directly sign a
id-kp-timeStamping certificate from such a Root. The reason behind this
is that only Roots that participate in a hierarchy that eventually
issues publicly trusted SSL certificates should have this rule. Roots
that participate in a hierarchy that does not issue SSL end-entity
certificates should not need to follow this rule. Could you please offer
some improvement language to make this clearer?
Thanks,
Dimitris.
>
> On Thu, Mar 30, 2017 at 12:22 PM, Dimitris Zacharopoulos via Public
> <public at cabforum.org <mailto: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 <mailto:Public at cabforum.org>
> https://cabforum.org/mailman/listinfo/public
> <https://cabforum.org/mailman/listinfo/public>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170330/8300b18d/attachment-0003.html>
More information about the Public
mailing list