[cabfpub] Draft CAA motion (3)

Steve Medin Steve_Medin at symantec.com
Fri Jan 13 22:32:45 UTC 2017

Pending questions handled by an explanatory new angle. Since EV Certificate Approvers and their non-EV counterparts are implemented in Enterprise RA accounts as 2FA-credentialed issuance portal administrators with access to a pre-vetted collection of domains, would you think that if we discover a CAA record in conflict of a pre-vetted domain, we should then immediately revoke the portal access certificate and second factor of every Certificate Approver so authorized by the Contract Signer?

So an organization can hold a contract with a CA for a managed service and have the rights, within aforementioned technical constraints, to produce certificates, but if someone who happens to have access to DNS drops in an I choose you, Pikachu for another CA, that whole contractual relationship, portal account, and course of doing business for a decade plus is all swept to the recycle bin?

So even though the certificate request came in to the same portal as always, and a credentialed Certificate Approver among a team of 30 reviewing certificate requests in an enterprise RA account globally reviewed it, who has been a member of that team for some time, the CAA change takes precedence? The DNS admin (or the bind 0day) rules over them all?

If so, then I suggest specific wording that the amendment takes precedence over the granted rights to Certificate Approvers in EV 11.8.4 and over the contemplation of multiple certificates issued as a result of a single request in BR 4.1.2. For the latter, this tightly correlates with the BR data reuse provisions which are muted by precedence of the amendment and CAA changes.

I suggest consensus about requirements to terminate such relationships, as they dominate the landscape and highly intersect with the consumer of CAA.

> -----Original Message-----
> From: Gervase Markham [mailto:gerv at mozilla.org]
> Sent: Friday, January 13, 2017 5:25 AM
> To: CA/Browser Forum Public Discussion List <public at cabforum.org>
> Cc: Steve Medin <Steve_Medin at symantec.com>
> Subject: Re: [cabfpub] Draft CAA motion (3)
> On 12/01/17 18:47, Steve Medin via Public wrote:
> > The proposed amendment does not invalidate and is in conflict with:
> >
> > BR 4.1.2. Enrollment Process and Responsibilities, specifically:
> >
> > One certificate request MAY suffice for multiple Certificates to be
> > issued to the same Applicant, subject to the aging and updating
> > requirement in Section 3.3.1, provided that each Certificate is
> > supported by a valid, current certificate request signed by the
> > appropriate Applicant Representative on behalf of the Applicant.
> Can you explain why there is a conflict here? This says that the Applicant can
> send you one CSR and you can use it to create multiple certificates. I'm not
> sure how that idea is in conflict with the requirement to check CAA every
> time you issue one.
> > And as Bruce states, the entirety of EVG 11.8.4.
> Again, I see no conflict, so you will need to explain exactly where you think it
> is.
> > In the latter, it is unclear whether the requirement to revoke EV
> > Authority ranks above or below CAA assertions in order of
> > interpretation unless romanette ii’s periodic re-confirmation of the
> > EV Authority of the Certificate Approver is hourly.
> Can you explain the scenario you think is problematic? That someone with EV
> Authority tries to get an EV cert issued and there is an adverse CAA record? I
> don't think the document says that the say-so of someone with EV Authority
> is necessarily the only permission-like thing that a CA needs in order to issue
> an EV certificate. So I would see the two checks (EV Authority approval and
> CAA) as additive.
> Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5744 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170113/e633518c/attachment-0001.p7s>

More information about the Public mailing list