[cabfpub] [EXTERNAL]Re: Require commonName in Root and Intermediate Certificates ballot draft

Ryan Sleevi sleevi at google.com
Thu Apr 6 19:19:11 UTC 2017


Could you explain how you read it to apply to outstanding
roots/intermediates? That'd be quite useful to know, since I think that if
you're reading it that way, you're also reading that CAs must revoke every
subscriber certificate that doesn't fit the (current) profile, which I'm
sure you agree is most certainly an incorrect read.

On Thu, Apr 6, 2017 at 3:11 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com>
wrote:

> I agree – I was proposing effective immediately as to construction of new
> roots/intermediates.  But I’m not sure Gerv’s ballot reads that way – it
> seems to say any outstanding root/intermediate must meet the new criteria.
>
>
>
> We could add a section 2 to the ballot that says the changes only apply to
> new roots/intermediates that are created after either the Ballot effective
> date, or better still a named date (let’s say 44+ days after the ballot
> starts the formal discussion period, maybe round to the nearest next month?)
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Thursday, April 6, 2017 10:56 AM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Kirk Hall <Kirk.Hall at entrustdatacard.com>
> *Subject:* [EXTERNAL]Re: [cabfpub] Require commonName in Root and
> Intermediate Certificates ballot draft
>
>
>
> Would there be any objection to effective immediately? This would only
> apply to the construction of new roots/intermediates, and only after the IP
> review period (of 30 days).
>
>
>
> On Thu, Apr 6, 2017 at 1:52 PM, Kirk Hall via Public <public at cabforum.org>
> wrote:
>
> Gerv – would this ballot need an effective date clause (“for roots and
> intermediate certificates created after [date]”) so that existing roots and
> intermediate certificates can continue to be used?
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Gervase
> Markham via Public
> *Sent:* Tuesday, March 28, 2017 6:34 AM
> *To:* CABFPub <public at cabforum.org>
> *Cc:* Gervase Markham <gerv at mozilla.org>
> *Subject:* [EXTERNAL][cabfpub] Require commonName in Root and
> Intermediate Certificates ballot draft
>
>
>
> Hi everyone,
>
> Here's a draft of a ballot to require commonName to be present in root and
> Intermediate certificates, which is something we've talked about in the
> past although not all that recently. This idea has had less review, so it
> may require more wordsmithing.
>
> Gerv
>
> *Ballot XXX - Require commonName in Root and Intermediate Certificates*
>
> *Purpose of Ballot: *Section 7.1.4.3 of the BRs, which deals with Subject
> Information for Subordinate CA Certificates, currently requires only that
> all information in a Subordinate CA Certificate is accurate; it does not
> say what information is required. Some of the necessary information is
> required elsewhere in the BRs, but it is not complete - commonName is
> missing. If commonName is omitted, DN clashes can more easily occur. So
> this motion centralises that information in the obvious place, and adds a
> commonName requirement.
>
> The following motion has been proposed by Gervase Markham of Mozilla and
> endorsed by XXX of XXX and XXX of XXX:
>
> -- MOTION BEGINS --
>
> * Delete 7.1.2.1 (e), which currently defines the Subject Information required in a Root CA Certificate.
>
>
>
> * Delete 7.1.2.2 (h), which currently defines the Subject Information required in a Subordinate CA Certificate.
>
>
>
> * Rename section 7.1.4.2, currently titled "Subject Information", to "Subject Information - Subscriber Certificates".
>
>
>
> * Rename section 7.1.4.3, currently titled "Subject Information - Subordinate CA Certificates" to "Subject Information - Root Certificates and Subordinate CA Certificates".
>
>
>
> * Based on the style used in 7.1.4.2.2 and the content from the now-deleted 7.1.2.1 (e) and 7.1.2.2 (h), add the following section 7.1.4.3.1:
>
>
>
> 7.1.4.3.1 Subject Distinguished Name Fields
>
>
>
> Certificate Field: subject:commonName (OID 2.5.4.3)
>
> Required/Optional: Required
>
> Contents: This field MUST be present and the contents MUST be an identifier
>
> for the certificate which is unique across all certificates issued by the
>
> issuing certificate.
>
>
>
> b. Certificate Field: subject:organizationName (OID 2.5.4.10)
>
> Required/Optional: Required
>
> Contents: This field MUST be present and the contents MUST contain
>
> either the Subject CA’s name or DBA as verified under Section 3.2.2.2.
>
> The CA may include information in this field that differs slightly from
>
> the verified name, such as common variations or abbreviations,  provided
>
> that the CA documents the difference and any abbreviations used are
>
> locally accepted abbreviations; e.g., if the official record shows
>
> “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or
>
> “Company Name”.
>
>
>
> c. Certificate Field: subject:countryName (OID: 2.5.4.6)
>
> Required/Optional: Required
>
> Contents: This field MUST contain the two‐letter ISO 3166‐1 country code
>
> for the country in which the CA’s place of business is located.
>
> -- MOTION ENDS --
>
>
>
> The procedure for approval of this Final Maintenance Guideline ballot is
> as follows (exact start and end times may be adjusted to comply with
> applicable Bylaws and IPR Agreement):
>
>
>
> BALLOT XXX
>
> Status: Final Maintenance Guideline
>
> Start time (23:00 UTC)
>
> End time (23:00 UTC)
>
> Discussion (7 to 14 days)
>
> XXX
>
> XXX
>
> Vote for approval (7 days)
>
> XXX
>
> XXX
>
> 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.
>
> 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/20170406/3858fd5f/attachment-0003.html>


More information about the Public mailing list