Subject: Re: [Acme] Pre-authorization approach

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Sep 2016 13:07:01 -0400

Not seeing any blockers on this from the subsequent discussion.  Chairs,
what say you?

On Fri, Aug 26, 2016 at 5:17 PM, Eric Rescorla <[email-masked]> wrote:

>
>
> On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker <
> [email-masked]> wrote:
>
>> On 08/26/2016 12:25 PM, Eric Rescorla wrote:
>> >
>> >
>> > On Fri, Aug 26, 2016 at 12:09 PM, Roland Bracewell Shoemaker
>> > <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> >     On 08/06/2016 10:49 AM, Eric Rescorla wrote:
>> >     >
>> >     >
>> >     > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews <
>> [email-masked] <mailto:[email-masked]>
>> >     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> >     >
>> >     >
>> >     >     I also think EKR's comment that we need the ability to
>> authorize domain
>> >     >     names without immediately issuing is a solid one*. So I think
>> we should
>> >     >     take the conservative approach and roll back the
>> new-application flow
>> >     >     for now. I do think we should document wildcard validation
>> before we
>> >     >     finalize the spec, but new-application may not be the best
>> way to do
>> >     >     that.
>> >     >
>> >     >     *Eric, would you mind repeating what you said for the benefit
>> of the
>> >     >     list? All we have right now are the notes and Richard's
>> paraphrase.
>> >     >
>> >     >
>> >     > To the best of my memory, my comment was that I thought it was
>> unfortunate
>> >     > that in order to register a domain you would have to generate a
>> valid CSR
>> >     > and potentially actually get it issued. This is especially true
>> if the
>> >     > key you
>> >     > plan to use for authorization is of a type you never intend to
>> issue into an
>> >     > EE (e.g., you are authorizing with Ed255159 but you are planning
>> to
>> >     > issue ECDSA and RSA). And it may not be possible to make these
>> align
>> >     > if you have various restrictions due to HSMs.
>> >
>> >     Sorry to jump into this so late but could you elaborate on the use
>> case
>> >     your are suggesting here? I am slightly confused about in what
>> >     circumstances you would want to authorize a domain for issuance,
>> but not
>> >     actually issue for it.
>> >
>> >     In a situation where you i.e. don't know all of the names you want
>> to
>> >     issue for in the future why not just wait until you do know all of
>> those
>> >     names to create the authorizations? The same goes for the HSM
>> situation
>> >     you describe, the key will be needed to sign the CSR at some point
>> >     anyway so why do the authorizations need to be created before the
>> key is
>> >     used?
>> >
>> >
>> > The pattern here is you would have a management box that was
>> responsible for
>> > the domain authorization process and for signing off on CSRs for other
>> > devices
>> > but was not itself intended to act as a Web server for the domain (this
>> > is more
>> > plausible with non-SimpleHTTPS authentication). In that case, you might
>> > pre-authorize all the domains but then on-the-fly have the actual origin
>> > servers
>> > make their own CSRs and get them signed off on by the management box. In
>> > this case, you wouldn't ever need an account key to sign the CSR.
>> >
>>
>> I'm still unsure why this is not currently possible with the new-app flow?
>>
>> Assuming in your example the management box passes back a certificate
>> after receiving a CSR from a origin server the only difference I can see
>> is there may be increased latency as the management box has to complete
>> authorizations instead of instantly getting a certificate back from the
>> ACME server.
>>
>
> Who says that the origin server is even up at the time you are authorizing
> the
> management box.
>
> -Ekr
>
>
>>
>> > -Ekr
>> >
>> >
>> >     >
>> >     > -Ekr
>> >     >
>> >     >
>> >     >
>> >     > _______________________________________________
>> >     > Acme mailing list
>> >     > [email-masked] <mailto:[email-masked]>
>> >     > https://www.ietf.org/mailman/listinfo/acme
>> >     <https://www.ietf.org/mailman/listinfo/acme>
>> >     >
>> >
>> >     _______________________________________________
>> >     Acme mailing list
>> >     [email-masked] <mailto:[email-masked]>
>> >     https://www.ietf.org/mailman/listinfo/acme
>> >     <https://www.ietf.org/mailman/listinfo/acme>
>> >
>> >
>>
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Sep 2016 17:23:51 +0000

If anyone objects to this, and there is ensuing discussion on the WG mail list, we’ll work to resolve it.  Otherwise, “silence implies agreement” and we’ll declare consensus next Tuesday.

Thanks.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

From: Richard Barnes [mailto:[email-masked]]
Sent: Thursday, September 08, 2016 1:07 PM
To: Eric Rescorla
Cc: IETF ACME; Roland Bracewell Shoemaker
Subject: Re: [Acme] Pre-authorization approach

Not seeing any blockers on this from the subsequent discussion.  Chairs, what say you?

On Fri, Aug 26, 2016 at 5:17 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Aug 26, 2016 at 1:33 PM, Roland Bracewell Shoemaker <[email-masked]<mailto:[email-masked]>> wrote:
On 08/26/2016 12:25 PM, Eric Rescorla wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>
>     > On Sat, Aug 6, 2016 at 10:36 AM, Jacob Hoffman-Andrews <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     > <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>     >
>     >
>     >     I also think EKR's comment that we need the ability to authorize domain
>     >     names without immediately issuing is a solid one*. So I think we should
>     >     take the conservative approach and roll back the new-application flow
>     >     for now. I do think we should document wildcard validation before we
>     >     finalize the spec, but new-application may not be the best way to do
>     >     that.
>     >
>     >     *Eric, would you mind repeating what you said for the benefit of the
>     >     list? All we have right now are the notes and Richard's paraphrase.
>     >
>     >
>     > To the best of my memory, my comment was that I thought it was unfortunate
>     > that in order to register a domain you would have to generate a valid CSR
>     > and potentially actually get it issued. This is especially true if the
>     > key you
>     > plan to use for authorization is of a type you never intend to issue into an
>     > EE (e.g., you are authorizing with Ed255159 but you are planning to
>     > issue ECDSA and RSA). And it may not be possible to make these align
>     Sorry to jump into this so late but could you elaborate on the use case
>     circumstances you would want to authorize a domain for issuance, but not
>     actually issue for it.
>
>     In a situation where you i.e. don't know all of the names you want to
>     issue for in the future why not just wait until you do know all of those
>     names to create the authorizations? The same goes for the HSM situation
>     anyway so why do the authorizations need to be created before the key is
>     used?
>
>
> The pattern here is you would have a management box that was responsible for

Who says that the origin server is even up at the time you are authorizing the
management box.

-Ekr

>     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     > https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=>
>     <https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=>>
>     >
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>     https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=>
>     <https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=>>
>
>

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Ka_h_rAC-FoxMZuGyBBzqiA8jF_Lsa6ROJgxWhoT9DM&s=m0q9DeMyMLoDGu1wXpwJU8SFF3FoatIYjanJ8L6U7KE&e=>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 8 Sep 2016 15:18:06 -0700

On 08/26/2016 11:19 AM, Richard Barnes wrote:
> This line of argument isn't really useful.  No matter what we specify
> here, clients can choose to only implement a part of the spec.  (There
> are TLS clients that only do RSA.)  Our responsibility here isn't to
> make sure that there's nothing a client can skip, it's to make sure
> that a client that wants to implement the whole spec can.
Agreed we can always have parts of the spec that some clients or some
servers don't implement. However, the only two CAs we have heard from
have said they don't intend to implement pre-auth, which means no
clients will implement it. Is it worthwhile to specify behavior that
no-one is going to implement?