RE: Requirements for Secondary Certificates (#522)

That seems solvable in the long-term -- if it's a defined OID, then it eventually wouldn't be a "special request" but simply an option included as part of your request.  But certainly it will slow adoption, as first these CAs need to be updated to permit it.

To Ryan's question, it's a mix of concerns.  First, a fair segment of our customers are BYOC, so Let's Encrypt doesn't help them.  For those where we control the certificate provisioning process, the issue is this:  We've already received feedback that the origin of the primary connection wants control over whether "their" connection can be re-used and for which origins.  That doesn't entirely make sense to me, but it's there.  We've so far agreed to swallow that, but also requiring opt-in in the reverse direction seems likely to result in a relatively low total opt-in rate.  To be clear, that conclusion is primarily intuition from having had features that were opt-in rather than opt-out in the past, but it's shared by others involved with the feature that I've talked to.

I see the point about subcerts allowing the primary certificate to be kept at higher security.  Regardless, we need to ensure that a delegated credential can be used with Secondary Certificates, so that operators can move in that direction.  I think that's probably the right long-term place to end up -- the question is whether we require everyone to start there, too.

-----Original Message-----
From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] 
Sent: Tuesday, April 10, 2018 12:37 PM
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: Mike Bishop <mbishop@evequefou.be>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: Requirements for Secondary Certificates (#522)

On Tue, Apr 10, 2018 at 03:11:15PM -0400, Ryan Sleevi wrote:
> On Tue, Apr 10, 2018 at 2:42 PM, Ilari Liusvaara 
> <ilariliusvaara@welho.com>
> wrote:
> 
> > > One proposal is to define a new OID and require it to be on any 
> > > certificates that servers present as Secondary.  This poses 
> > > substantial deployment problems.
> >
> > Yeah, that is going to have deployment problems.
> >
> 
> I'd like to understand more about these deployment problems. It seems 
> these are based on assumption of long-lived certificates and the 
> difficulty of obtaining new certificates. However, a number of CDNs 
> and large providers are using automated APIs for their issuance and 
> renewal, and a number of CAs offer automated APIs for end-users, including, notably, Let's Encrypt.

The thing I am concerned about is one able to get suitable certificate at all, or if it requires some nasty (unscalable) "special request" (which, e.g., Let's Encrypt never does).


-Ilari

Received on Tuesday, 10 April 2018 20:10:09 UTC