[cabfpub] Ballot 125 - CAA Records

Tue Nov 4 15:14:34 UTC 2014

Section 3.2.5 is actually called "Validation of Authority" so that might 
have been a better place.

However, I don't think the actual location matters as much as whether 
all CAs include it in the same section.

Jeremy

On 11/2/2014 2:38 PM, Ben Wilson wrote:
>
> This is an example of a situation where the RFC 3647 framework does 
> not provide the “perfect” section for the expressions of a principle 
> that otherwise is “good” to incorporate into a CP /  CPS.  For 
> purposes of ballot 125, section 4.2 was believed to be the best 
> section for putting that practice.
>
> *From:*public-bounces at cabforum.org 
> [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan Sleevi
> *Sent:* Friday, October 31, 2014 7:05 AM
> *To:* Doug Beattie
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] Ballot 125 - CAA Records
>
> Doug,
>
> My understanding of the framework from 3647 is that section 3.2 is 
> about validating the identity of the requestor and their authorization 
> as Applicant Representative to make such a request.
>
> This doesn't seem appropriate for CAA, as it is about validating the 
> CA's authorization by the organization to issue certificates - 
> regardless of all the policies from 3.2 being met of identifying the 
> Applicant.
>
> There are some similarities to 7.1.2p2 of the BRs - namely the ability 
> to distinguish whether or not the Subject authorized the issuance - 
> but this authorization seems tied to the Applicant Representative, 
> wheras CAA is a broader expression of policy between the Subject and CA.
>
> On Oct 31, 2014 5:42 AM, "Doug Beattie" <doug.beattie at globalsign.com 
> <mailto:doug.beattie at globalsign.com>> wrote:
>
> That’s right Ryan – CAA applies to all SSL/TLS, but probably not 
> applicable to code signing, individual certs, etc.  Section 3.2 
> describes the Identify validation process for all types of 
> certificates the CA issues.
>
> *From:*Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com>]
> *Sent:* Friday, October 31, 2014 8:16 AM
> *To:* Doug Beattie
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] Ballot 125 - CAA Records
>
>
> On Oct 31, 2014 4:46 AM, "Doug Beattie" <doug.beattie at globalsign.com 
> <mailto:doug.beattie at globalsign.com>> wrote:
> >
> > I’m starting to look at making updates to the CPS to support this 
> ballot and wonder if the wrong section was specified in the ballot.  
> Is Section 4.2 where this belongs, or is section 3.2 the right place?
> >
> >
> >
> > Section 4.2 contains high level statements and no real detail, and 
> 4.2 generally refers back to 3.2 for the specifics:
> >
> >
> >
> > 4.2. Certificate application processing
> >
> > 4.2.1. Performing Identification and Authentication Functions
> >
> > 4.2.2. Approval or Rejection of Certificate Applications
> >
> > 4.2.3. Time to Process Certificate Applications
> >
> >
> >
> > Since CAA only applies to some types of certificates, and the 
> details of domain and Organization Identity for each type of cert are 
> listed in 3.2, it would make more sense (to me) to include the steps 
> CAs use when processing CAA records as part of the Domain Control, 
> Ownership or “right to use” processes that are described in section 3.2.
> >
>
> I'm not sure I understand your remark regarding "some types of 
> certificates" - it would certainly apply to every cert intended for 
> server authenticated TLS.
>
> >
> >
> > Doug
> >
> >
> >
> >
> >
> > From: public-bounces at cabforum.org 
> <mailto:public-bounces at cabforum.org> 
> [mailto:public-bounces at cabforum.org 
> <mailto:public-bounces at cabforum.org>] On Behalf Of Ben Wilson
> > Sent: Tuesday, September 30, 2014 11:01 AM
> > To: CABFPub
> > Subject: [cabfpub] Ballot 125 - CAA Records
> >
> >
> >
> > Ballot 125 - CAA Records
> >
> > Rick Andrews of Symantec made the following motion and Jeremy Rowley 
> of Digicert and Ryan Sleevi of Google have endorsed it:
> >
> > Reasons for proposed ballot RFC 6844 defines a Certification 
> Authority Authorization DNS Resource Record (CAA). A CAA allows a DNS 
> domain name holder to specify the CAs authorized to issue certificates 
> for that domain. Publication of the CAA gives CAs and domain holders 
> additional controls to reduce the risk of unintended certificate 
> mis-issuance.
> >
> > The proponents of this ballot believe that this proposed 
> modification to the Baseline Requirements, which gives CAs up to six 
> months to update their CP and/or CPS to state the degree to which they 
> implement CAA, provides all CAs with the flexibility needed to begin 
> implementation of CAA.
> >
> > ---MOTION BEGINS---
> >
> > Add to Section 4 Definitions, new item:
> >
> > CAA: From RFC 6844 (http:tools.ietf.org/html/rfc6844 
> <http://tools.ietf.org/html/rfc6844>): “The Certification Authority 
> Authorization (CAA) DNS Resource Record allows a DNS domain name 
> holder to specify the Certification Authorities (CAs) authorized to 
> issue certificates for that domain. Publication of CAA Resource 
> Records allows a public Certification Authority to implement 
> additional controls to reduce the risk of unintended certificate 
> mis-issue.”
> >
> > Add the following to the end of Section 8.2.2, Disclosure:
> >
> > Effective as of [insert date that is six months from Ballot 125 
> adoption], section 4.2 of a CA's Certificate Policy and/or 
> Certification Practice Statement (section 4.1 for CAs still conforming 
> to RFC 2527) SHALL state whether the CA reviews CAA Records, and if 
> so, the CA’s policy or practice on processing CAA Records for Fully 
> Qualified Domain Names. The CA SHALL log all actions taken, if any, 
> consistent with its processing practice.
> >
> > The resulting Section 8.2.2 would read as follows:
> >
> > The CA SHALL publicly disclose its Certificate Policy and/or 
> Certification Practice Statement through an appropriate and readily 
> accessible online means that is available on a 24x7 basis. The CA 
> SHALL publicly disclose its CA business practices to the extent 
> required by the CA’s selected audit scheme (see Section 17.1). The 
> disclosures MUST include all the material required by RFC 2527 or RFC 
> 3647, and MUST be structured in accordance with either RFC 2527 or RFC 
> 3647. Effective as of [insert date that is six months from Ballot 125 
> adoption], section 4.2 of a CA's Certificate Policy and/or 
> Certification Practice Statement (section 4.1 for CAs still conforming 
> to RFC 2527) SHALL state whether the CA reviews CAA Records, and if 
> so, the CA’s policy or practice on processing CAA Records for Fully 
> Qualified Domain Names. The CA SHALL log all actions taken, if any, 
> consistent with its processing practice.
> >
> > ---MOTION ENDS---
> >
> > The review period for this ballot shall commence at 2200 UTC on 
> Tuesday, 30 September 2014, and will close at 2200 UTC on Tuesday, 7 
> October 2014. Unless the motion is withdrawn during the review period, 
> the voting period will start immediately thereafter and will close at 
> 2200 UTC on Tuesday, 14 October 2014. Votes must be cast by posting an 
> on-list reply to this thread.
> >
> > 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 currently seven (7) members– at least seven members must 
> participate in the ballot, 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
> >
>
>
>
> _______________________________________________
> 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/20141104/1bcc2bdc/attachment-0003.html>