[cabfpub] BR Enterprise RAs

Ryan Sleevi sleevi at google.com
Tue Jan 21 16:54:27 MST 2014


Rich,

I don't think the EVGs necessarily represent a desirable model in this
regard.

What I'm having trouble understanding is why, when dealing with an
Enterprise RA, you cannot use a Domain Authorization Document? Paragraph 2
of 11.1.1 (regarding Domain Authorization Documents), namely point (ii),
seems like it would be sufficient to cover this case.


On Mon, Jan 20, 2014 at 5:58 AM, Rich Smith <richard.smith at comodo.com>wrote:

> Ryan,
>
> Responses inline below.
>
> -Rich
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com <sleevi at google.com>]
> *Sent:* Friday, January 17, 2014 3:27 PM
>
> *To:* Rich Smith
> *Cc:* Jeremy Rowley; CABFPub
> *Subject:* Re: [cabfpub] BR Enterprise RAs
>
>
>
> Hi Rich,
>
>
>
> While I agree with the conclusion reached by Rob, I'm a little confused
> how changing the definition of 14.2.4 accomplishes the desired result.
>
>
>
> That is, you removed the reference to 7.1.2 (although I'm uncertain why
> there reference is only to para 1, and not 7.1.2 in its entirety), but
> Section 11.1.1 would/should still apply.
>
> *[RWS] That was an oversite.  I'm happy to add it back in.*
>
>
>
> Have I missed something with your proposed change? Is the belief that the
> Enterprise RA can perform the authorization checks from 11.1 on behalf of
> the CA with the new wording?
>
> *[RWS] Regarding issuing certificates w/in the verified Domain Namespace,
> yes.*
>
>
>
> The potential problem I see here is that it would seem to open the
> following loophole:
>
> - CA verifies Enterprise RA is authorized for foo.example (eg: via DNS)
> with a 5 year registration at Time X
>
> - At time X+59 months, Enterprise RA directs CA to issue a certificate for
> www.foo.example, with a 60 month validity (per 9.4.1)
>
> - Effective certificate lifetime is 119 months
>
> *[RWS] It would actually be X+39 months with a 39 month validity by the
> time it matters for a total of 78 months, but I take your point.  I would
> be happy to insert a lower time limit if that would alleviate this concern,
> but I think requiring the CA to re-verify domain control on EVERY request
> when we are talking about an Enterprise customer with whom the CA has an
> ongoing contractual relationship seems excessive and the EV Guidelines
> currently allow for X+27 for a possible total validity of 52 months.  I
> don't think the intent was ever to make the BRs more restrictive on
> Enterprise clients than the EV Guidelines are.*
>
>
>
> I see Section 11.1.1 and Section 14.2.4 as trying to 'defend' against
> this. Of course, they may be doing so poorly (by not checking the
> authorization duration for the domain), but at least that strikes at the
> intent.
>
>
>
> I do agree that we should try to bring the EVGs and BRs into alignment (to
> the degree appropriate), by permitting Enterprise RAs to perform acts on
> behalf of the CA, provided that all FQDNs fall within the scope of the RA's
> verified Domain Namespace.
>
> *[RWS] That's what I'm shooting for here.  We seem to be in rough
> agreement, except possibly in terms of total max validity of the original
> domain verification.  Do you have a suggestion for a limitation that would
> still largely allow an Enterprise RA to obtain most certs in their verified
> Domain Namespace w/out excessive delays on the CA side?*
>
>
>
>
>
> On Fri, Jan 17, 2014 at 12:06 PM, Rich Smith <richard.smith at comodo.com>
> wrote:
>
> Ryan,
>
> As the result of an internal discussion regarding Enterprise RA domain
> control verification we have determined that the current wording of the BRs
> requires the CA to verify domain control on each and every certificate
> request by the enterprise.  My initial opinion was that Section 11.3 would
> allow an Enterprise to obtain certificates in their verified Domain
> Namespace for up to 39 months, however Rob pointed out that Section 11.1.1
> says:
>
>    "the CA SHALL confirm that, _as of the date the Certificate was
>
>     issued_, the Applicant either is the Domain Name Registrant or has
>
>     control over the FQDN".
>
> Rob's opinion is that "as of the date the Certificate was issued" has to
> mean something, and to interpret Section 11.3's "39 months" as overriding
> Section 11.1.1 would render it meaningless.
>
>
>
> I consider his reasoning sound, but I don't think that was the intent,
> especially as it would make the BRs more strict in this regard than the EV
> Guidelines, so that is what this motion is intended to address.  If
> everyone else is of the opinion that 11.3 is sufficient (and I do think
> that quite a few CAs are operating under that assumption) then we can leave
> it alone and move on, but I think the current wording in various sections
> leaves the issue open to interpretation.
>
>
>
> -Rich
>
>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Friday, January 17, 2014 2:33 PM
> *To:* Rich Smith
> *Cc:* Jeremy Rowley; CABFPub
>
>
> *Subject:* Re: [cabfpub] BR Enterprise RAs
>
>
>
> Rich,
>
>
>
> Your original proposal didn't quite indicate the problem that you're
> trying to solve - or at least, the problem as you see it, and instead only
> presented the solution.
>
>
>
> Is the issue something to do with the applicable namespace? Is it trying
> to designate additional entities as Enterprise RAs?
>
>
>
> That is, I see a lot of problems with the proposal as written, and rather
> than trying to dissect them all, I'd like to try and understand what your
> end-goal is, to see how we can move there.
>
>
>
> Cheers,
>
> Ryan
>
>
>
> On Fri, Jan 17, 2014 at 11:30 AM, Rich Smith <richard.smith at comodo.com>
> wrote:
>
> How about editing both to:
>
> The CA MAY contractually authorize the Subject of a specified Valid
> Certificate to perform the RA function and authorize the CA to issue
> additional Certificates at ***the same or higher*** domain levels that are
> contained within the ***verified Domain Namespace*** of the original
> Certificate (also known as an Enterprise Certificate).  In such case, the
> Subject SHALL be considered an Enterprise RA, and the following
> requirements SHALL apply:
>
>
>
> *** indicates where I made the changes.
>
>
>
> -Rich
>
>
>
> *From:* Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> *Sent:* Friday, January 17, 2014 12:58 PM
> *To:* 'Ryan Sleevi'; 'Rich Smith'
> *Cc:* 'CABFPub'
> *Subject:* RE: [cabfpub] BR Enterprise RAs
>
>
>
> Because the language comes straight from the EV Guidelines.  Maybe we
> should update both at the same time?
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org<public-bounces at cabforum.org>]
> *On Behalf Of *Ryan Sleevi
> *Sent:* Friday, January 17, 2014 10:26 AM
> *To:* Rich Smith
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] BR Enterprise RAs
>
>
>
> Third or higher is insufficient for most ccTLDs (example.co.uk) or overly
> broad for gTLDs (foo.example).
>
> Is there a reason you didn't simply refer to the registered domain name
> (and any preceding labels)?
>
> That also covers the school.k12.wv.us type registrations as well.
>
> On Jan 17, 2014 9:19 AM, "Rich Smith" <richard.smith at comodo.com> wrote:
>
> Colleagues,
>
> In reviewing internal practices and BR compliance, we have discovered that
> the BRs seem to have a more restricted definition of what an Enterprise RA
> is allowed than the EV Guidelines.  I think this is due simply to the
> wording of the BRs rather than specific intent.  Because of that, I would
> like to propose the following amendment to the BRs.  Please review and let
> me know if you are willing to endorse.
>
>
>
> ----Motion Begins----
>
>
>
> Replace:
>
> 14.2.4      Enterprise RAs
>
> The CA MAY designate an Enterprise RA to verify certificate requests from
> the Enterprise RA’s own organization.
>
> The CA SHALL NOT accept certificate requests authorized by an Enterprise
> RA unless the following requirements are satisfied:
>
> 1.    The CA SHALL confirm that the requested Fully-Qualified Domain
> Name(s) are within the Enterprise RA’s verified Domain Namespace (see
> Section 7.1.2 para 1).
>
>
>
> With the following:
>
> 14.2.4      Enterprise RAs
>
> The CA MAY contractually authorize the Subject of a specified Valid
> Certificate to perform the RA function and authorize the CA to issue
> additional Certificates at third and higher domain levels that are
> contained within the domain of the original Certificate (also known as an
> Enterprise Certificate).  In such case, the Subject SHALL be considered an
> Enterprise RA, and the following requirements SHALL apply:
>
> (1)   An Enterprise RA SHALL NOT authorize the CA to issue an Enterprise
> Certificate at the third or higher domain levels to any Subject other than
> the Enterprise RA or a business that is owned or directly controlled by the
> Enterprise RA;
>
> (2)   In all cases, IF the Enterprise Certificate is to contain
> Organization details, the Subject of an Enterprise Certificate MUST be an
> organization verified by the CA in accordance with these Requirements;
>
> (3)   The CA MUST impose these limitations as a contractual requirement
> with the Enterprise RA and monitor compliance by the Enterprise RA; and,
>
> (4)   The audit requirements of Section 17.1 of these Requirements SHALL
> apply to the Enterprise RA, except in the case where the CA maintains
> control over the Root CA Private Key or Subordinate CA Private Key used to
> issue the Enterprise Certificates, in which case, the Enterprise RA MAY be
> exempted from the audit requirements.  In the case that the Enterprise RA
> is granted a Technically Constrained Subordinate CA Key, Section 17.9 of
> these audit requirements shall apply to the Enterprise RA.
>
>
>
>
>
> --
>
> Regards,
>
> Rich Smith
>
> Validation Manager
>
> Comodo
>
> http://www.comodo.com
>
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140121/da00231b/attachment-0001.html 


More information about the Public mailing list