Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Salz, Rich]

At IETF102 we had extremely strong consensus to merge this, to address the last 
open AD review comment.

As Richard said, if you have concerns or objections, please speak up NOW.

/rich, co-chair

From: Richard Barnes 
Date: Tuesday, July 17, 2018 at 6:00 PM
To: "c...@letsencrypt.org" 
Cc: Rich Salz , Eric Rescorla , 
"acme@ietf.org" , Russ Housley 
Subject: Re: [Acme] AD Review: draft-ietf-acme-acme-12

... and based on feedback at the meeting, I went ahead and merged this.  I 
understand that EKR will be issuing an IETF last call soon, so if you have 
concerns about this change, please raise them there.  Or on this thread, but in 
any case, ASAP.

Thanks,
--Richard

On Tue, Jul 17, 2018 at 4:27 PM Richard Barnes  wrote:
I went ahead and posted a PR implementing EKR's suggestion:

https://github.com/ietf-wg-acme/acme/pull/429<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_429=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=akOT5FNFHauSSc-eXxV1lyXw7wamEL3Ba7HiBjxAjYE=IcP4Of7AvUdlhfAyNZMU3gwzGdEK1qFBNhUxpcPkY6w=>


On Wed, May 30, 2018 at 4:23 PM Daniel McCarney 
mailto:c...@letsencrypt.org>> wrote:
We have multiple CA’s that support it, and other implementations as well.

Of the multiple CAs that support ACME, which support something resembling the 
current draft? When I looked last the non-Let's Encrypt ACME server 
implementations all seemed to be targeting Certbot and the "ACMEv1" era of this 
draft (e.g. are not using the order based issuance flow at all). There have 
been substantial backwards compatibility breaking changes in the draft since 
this time.

I second EKR's sentiment that there has been little true ACME inter-op testing 
of the protocol as described in draft-12 outside of that done with Let's 
Encrypts ACMEv2 endpoint.

- Daniel / cpu

On Wed, May 30, 2018 at 3:56 PM, Salz, Rich 
mailto:rsalz=40akamai@dmarc.ietf.org>> 
wrote:

  *   Well, we have a fair bit of experience of a lot of people talking to 
Let's Encrypt. That's not really the same as a lot of servers and a lot of 
clients.

We have multiple CA’s that support it, and other implementations as well.  
Certainly LE dominates, but it’s not the only usage.  And certainly not the 
only anticipated future usage.


  *   I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with 
X25519.

That would make the MTI limited to a subset of the WebPKI supported by the 
latest browsers, which seems wrong.  But let’s not bikeshed too much and see 
what the WG consensus is.


___
Acme mailing list
Acme@ietf.org<mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=akOT5FNFHauSSc-eXxV1lyXw7wamEL3Ba7HiBjxAjYE=cFUtkkykElzuumAcVXyZR--IkB424C8nNbuOvrXeKYM=>

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

 and based on feedback at the meeting, I went ahead and merged this.  I
understand that EKR will be issuing an IETF last call soon, so if you have
concerns about this change, please raise them there.  Or on this thread,
but in any case, ASAP.

Thanks,
--Richard

On Tue, Jul 17, 2018 at 4:27 PM Richard Barnes  wrote:

> I went ahead and posted a PR implementing EKR's suggestion:
>
> https://github.com/ietf-wg-acme/acme/pull/429
>
>
> On Wed, May 30, 2018 at 4:23 PM Daniel McCarney 
> wrote:
>
>> We have multiple CA’s that support it, and other implementations as well.
>>
>>
>> Of the multiple CAs that support ACME, which support something resembling
>> the current draft? When I looked last the non-Let's Encrypt ACME server
>> implementations all seemed to be targeting Certbot and the "ACMEv1" era of
>> this draft (e.g. are not using the order based issuance flow at all). There
>> have been substantial backwards compatibility breaking changes in the draft
>> since this time.
>>
>> I second EKR's sentiment that there has been little true ACME inter-op
>> testing of the protocol as described in draft-12 outside of that done with
>> Let's Encrypts ACMEv2 endpoint.
>>
>> - Daniel / cpu
>>
>> On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
>> rsalz=40akamai@dmarc.ietf.org> wrote:
>>
>>>
>>>- Well, we have a fair bit of experience of a lot of people talking
>>>to Let's Encrypt. That's not really the same as a lot of servers and a 
>>> lot
>>>of clients.
>>>
>>>
>>>
>>> We have multiple CA’s that support it, and other implementations as
>>> well.  Certainly LE dominates, but it’s not the only usage.  And certainly
>>> not the only anticipated future usage.
>>>
>>>
>>>
>>>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA
>>>with X25519.
>>>
>>>
>>>
>>> That would make the MTI limited to a subset of the WebPKI supported by
>>> the latest browsers, which seems wrong.  But let’s not bikeshed too much
>>> and see what the WG consensus is.
>>>
>>>
>>>
>>> ___
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>>
>>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

I went ahead and posted a PR implementing EKR's suggestion:

https://github.com/ietf-wg-acme/acme/pull/429


On Wed, May 30, 2018 at 4:23 PM Daniel McCarney  wrote:

> We have multiple CA’s that support it, and other implementations as well.
>
>
> Of the multiple CAs that support ACME, which support something resembling
> the current draft? When I looked last the non-Let's Encrypt ACME server
> implementations all seemed to be targeting Certbot and the "ACMEv1" era of
> this draft (e.g. are not using the order based issuance flow at all). There
> have been substantial backwards compatibility breaking changes in the draft
> since this time.
>
> I second EKR's sentiment that there has been little true ACME inter-op
> testing of the protocol as described in draft-12 outside of that done with
> Let's Encrypts ACMEv2 endpoint.
>
> - Daniel / cpu
>
> On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
> rsalz=40akamai@dmarc.ietf.org> wrote:
>
>>
>>- Well, we have a fair bit of experience of a lot of people talking
>>to Let's Encrypt. That's not really the same as a lot of servers and a lot
>>of clients.
>>
>>
>>
>> We have multiple CA’s that support it, and other implementations as
>> well.  Certainly LE dominates, but it’s not the only usage.  And certainly
>> not the only anticipated future usage.
>>
>>
>>
>>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA
>>with X25519.
>>
>>
>>
>> That would make the MTI limited to a subset of the WebPKI supported by
>> the latest browsers, which seems wrong.  But let’s not bikeshed too much
>> and see what the WG consensus is.
>>
>>
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Daniel McCarney]

>
> We have multiple CA’s that support it, and other implementations as well.


Of the multiple CAs that support ACME, which support something resembling
the current draft? When I looked last the non-Let's Encrypt ACME server
implementations all seemed to be targeting Certbot and the "ACMEv1" era of
this draft (e.g. are not using the order based issuance flow at all). There
have been substantial backwards compatibility breaking changes in the draft
since this time.

I second EKR's sentiment that there has been little true ACME inter-op
testing of the protocol as described in draft-12 outside of that done with
Let's Encrypts ACMEv2 endpoint.

- Daniel / cpu

On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
rsalz=40akamai@dmarc.ietf.org> wrote:

>
>- Well, we have a fair bit of experience of a lot of people talking to
>Let's Encrypt. That's not really the same as a lot of servers and a lot of
>clients.
>
>
>
> We have multiple CA’s that support it, and other implementations as well.
> Certainly LE dominates, but it’s not the only usage.  And certainly not the
> only anticipated future usage.
>
>
>
>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with
>X25519.
>
>
>
> That would make the MTI limited to a subset of the WebPKI supported by the
> latest browsers, which seems wrong.  But let’s not bikeshed too much and
> see what the WG consensus is.
>
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Salz, Rich]

  *   The reason I chose those values is because you're already tied to TLS for 
the communications and therefore you necessarily have the TLS MTI cipher 
suites, which means you already have those algorithms.

If your toolkit exposes it.  If your toolkit is a black box or scripted such as 
CURL, you might as well have the message signatures be what your ultimate 
certificates are gonna be.  That was the point I was trying to make.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 12:56 PM, Salz, Rich  wrote:

>
>- Well, we have a fair bit of experience of a lot of people talking to
>Let's Encrypt. That's not really the same as a lot of servers and a lot of
>clients.
>
>
>
> We have multiple CA’s that support it, and other implementations as well.
> Certainly LE dominates, but it’s not the only usage.  And certainly not the
> only anticipated future usage.
>

Right. And the purpose of the MTI is usually to make future interop work
better.

>
>
>- I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with
>X25519.
>
>
>
> That would make the MTI limited to a subset of the WebPKI supported by the
> latest browsers, which seems wrong.  But let’s not bikeshed too much and
> see what the WG consensus is.
>

I'm not following your point here. Remember, I'm not talking about the MTI
for what the *certs* contain, but rather for what the protocol uses for its
in-protocol signatures. There's no reason you can't use an ECDSA key to
authorize issuance of an RSA cert (Which would presumably be in a
self-signed PKCS#10 blob with RSA), or for that matter, an XMSS cert.

The reason I chose those values is because you're already tied to TLS for
the communications and therefore you necessarily have the TLS MTI cipher
suites, which means you already have those algorithms.

-Ekr


>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Salz, Rich]

  *   Well, we have a fair bit of experience of a lot of people talking to 
Let's Encrypt. That's not really the same as a lot of servers and a lot of 
clients.

We have multiple CA’s that support it, and other implementations as well.  
Certainly LE dominates, but it’s not the only usage.  And certainly not the 
only anticipated future usage.


  *   I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with 
X25519.

That would make the MTI limited to a subset of the WebPKI supported by the 
latest browsers, which seems wrong.  But let’s not bikeshed too much and see 
what the WG consensus is.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 11:45 AM, Salz, Rich  wrote:

> I believe the working group has decided that MTI algorithms are not
> necessary.  If you want that confirmed on the list, we can ask.
>

Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I
want to tell them that the WG had consensus.


  ACME isn’t just WebPKI, as you know, it’s also becoming STIR and some
> have proposed home environments.
>
>
>
> We have many implementations to serve as proof points that MTI isn’t
> required in the Real World.
>

As I said to Richard, it seems like much of the interop is between clients
and LE. It's not hard to get interop when one side is fixed.

-Ekr
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Wed, May 30, 2018 at 11:25 AM, Richard Barnes  wrote:

>
>
> On Tue, May 29, 2018 at 4:02 PM Eric Rescorla  wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 9:57 PM, Russ Housley 
>> wrote:
>>
>>> Eric:
>>>
>>>
>>> > > Do you want to specify a set of acceptable signature algorithms here?
> >
> > I am inclined not to.  We have already forbidden "none" and MAC.  We
> > shouldn't specify "MUST"s here, because CABF sets their own list of
> > required algorithms, and we don't want to conflict.  I guess you
> > could specify some MUST NOTs pretty safely, but given that they're
> > already forbidden by CABF, it seems kind of duplicative.
>
> This is about the signatures that ACME accepts, not the signatures
> in certs. Does CABF have a position on what signature algorithms
> that ACME uses?
>

 Good point.  As Ryan pointed out, this is not something on which there
 is currently CABF guidance.

 Nonetheless, I'm still disinclined to have MUSTs here for other
 reasons.  If they're positive "MUST support" requirements, then we would
 need to come back and revise this document in the event of an algorithm
 break (though admittedly, that would be pretty far down on the TODO list).
 And looking at the current list of JWS algorithms, I don't see any I would
 MUST NOT, except possibly the ones based on SHA-1

>>>
>>> Hmm... Common practice in security protocols is to specify MTI
>>> algorithms. Why is this different?
>>>
>>>
>>> PKIX chose not to specify mandatory-to-implement algorithms.  This was
>>> done because the application that made use of the certificate needed to be
>>> able to impose such requirements.
>>>
>>> Here is one place from the PKIX WG archive in 2011 that states this
>>> approach:
>>>
>>>(https://mailarchive.ietf.org/arch/msg/pkix/
>>> blSByMc7SysNNvkFlsFdcrFLrIs)
>>>
>>>PKIX defines PKI specs for a very wide range of apps, which is why we
>>>do not mandate any alg suite.  Different apps may use different alg
>>> suites.
>>>TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for
>>> itself.
>>>
>>> It seems to me that ACME is being used to support certificate enrollment
>>> for many different applications, so the same approach seems appropriate.
>>>
>>
>> Hmm... This seems like it would be more persuasive if there weren't a
>> dependency on TLS and its MTI algorithms
>>
>> From my perspective, this is sort of on the bubble. Historically, I've
>> seen the IESG insist on MTI algorithms, but it's not consistent. I would
>> like to understand if this is something that has strong consensus in the
>> WG, in which case I'll support that (though other IESG members may feel
>> differently) or if it just happened, in which case I'd ask the WG to
>> reconsider.
>>
>
> I think it's more in the latter category in the former, but TBH, I think
> that kind of argues in favor of the status quo -- we have a fair bit of
> implementation / deployment experience, and this has not been an interop
> problem.
>

Well, we have a fair bit of experience of a lot of people talking to Let's
Encrypt. That's not really the same as a lot of servers and a lot of
clients.


In a similar vein, where we have had discussion of versioning (a similar
> issue) there's been consensus *not* to go the traditional route of having
> version numbers -- you just have to know what version of ACME the endpoint
> you're talking to speaks.  It doesn't seem totally crazy to me for the same
> to be true of the signing algorithms you use.
>
> I guess I don't really know what value you're solving for here
>

I'm not sure what's confusing. The IETF has traditionally required MTI
algorithms to ensure that there is a baseline that allows two
implementations to talk to each other. We spent an enormous amount of time
on this in RTCWEB, so it's not exactly ancient history.

..  Just to try to make this concrete, if you were going to propose some
> algorithms to be MTI / MTnotI, what would you list?
>

I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with X25519.

-Ekr


> --Richard
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Salz, Rich]

I believe the working group has decided that MTI algorithms are not necessary.  
If you want that confirmed on the list, we can ask.  ACME isn’t just WebPKI, as 
you know, it’s also becoming STIR and some have proposed home environments.

We have many implementations to serve as proof points that MTI isn’t required 
in the Real World.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

On Tue, May 29, 2018 at 4:02 PM Eric Rescorla  wrote:

>
>
> On Mon, May 28, 2018 at 9:57 PM, Russ Housley 
> wrote:
>
>> Eric:
>>
>>
>> > > Do you want to specify a set of acceptable signature algorithms here?
 >
 > I am inclined not to.  We have already forbidden "none" and MAC.  We
 > shouldn't specify "MUST"s here, because CABF sets their own list of
 > required algorithms, and we don't want to conflict.  I guess you
 > could specify some MUST NOTs pretty safely, but given that they're
 > already forbidden by CABF, it seems kind of duplicative.

 This is about the signatures that ACME accepts, not the signatures
 in certs. Does CABF have a position on what signature algorithms
 that ACME uses?

>>>
>>> Good point.  As Ryan pointed out, this is not something on which there
>>> is currently CABF guidance.
>>>
>>> Nonetheless, I'm still disinclined to have MUSTs here for other
>>> reasons.  If they're positive "MUST support" requirements, then we would
>>> need to come back and revise this document in the event of an algorithm
>>> break (though admittedly, that would be pretty far down on the TODO list).
>>> And looking at the current list of JWS algorithms, I don't see any I would
>>> MUST NOT, except possibly the ones based on SHA-1
>>>
>>
>> Hmm... Common practice in security protocols is to specify MTI
>> algorithms. Why is this different?
>>
>>
>> PKIX chose not to specify mandatory-to-implement algorithms.  This was
>> done because the application that made use of the certificate needed to be
>> able to impose such requirements.
>>
>> Here is one place from the PKIX WG archive in 2011 that states this
>> approach:
>>
>>(
>> https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs)
>>
>>PKIX defines PKI specs for a very wide range of apps, which is why we
>>do not mandate any alg suite.  Different apps may use different alg
>> suites.
>>TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.
>>
>> It seems to me that ACME is being used to support certificate enrollment
>> for many different applications, so the same approach seems appropriate.
>>
>
> Hmm... This seems like it would be more persuasive if there weren't a
> dependency on TLS and its MTI algorithms
>
> From my perspective, this is sort of on the bubble. Historically, I've
> seen the IESG insist on MTI algorithms, but it's not consistent. I would
> like to understand if this is something that has strong consensus in the
> WG, in which case I'll support that (though other IESG members may feel
> differently) or if it just happened, in which case I'd ask the WG to
> reconsider.
>

I think it's more in the latter category in the former, but TBH, I think
that kind of argues in favor of the status quo -- we have a fair bit of
implementation / deployment experience, and this has not been an interop
problem.

In a similar vein, where we have had discussion of versioning (a similar
issue) there's been consensus *not* to go the traditional route of having
version numbers -- you just have to know what version of ACME the endpoint
you're talking to speaks.  It doesn't seem totally crazy to me for the same
to be true of the signing algorithms you use.

I guess I don't really know what value you're solving for here.  Just to
try to make this concrete, if you were going to propose some algorithms to
be MTI / MTnotI, what would you list?

--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Mon, May 28, 2018 at 9:57 PM, Russ Housley  wrote:

> Eric:
>
>
> > > Do you want to specify a set of acceptable signature algorithms here?
>>> >
>>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>>> > required algorithms, and we don't want to conflict.  I guess you
>>> > could specify some MUST NOTs pretty safely, but given that they're
>>> > already forbidden by CABF, it seems kind of duplicative.
>>>
>>> This is about the signatures that ACME accepts, not the signatures
>>> in certs. Does CABF have a position on what signature algorithms
>>> that ACME uses?
>>>
>>
>> Good point.  As Ryan pointed out, this is not something on which there is
>> currently CABF guidance.
>>
>> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
>> If they're positive "MUST support" requirements, then we would need to come
>> back and revise this document in the event of an algorithm break (though
>> admittedly, that would be pretty far down on the TODO list).  And looking
>> at the current list of JWS algorithms, I don't see any I would MUST NOT,
>> except possibly the ones based on SHA-1
>>
>
> Hmm... Common practice in security protocols is to specify MTI algorithms.
> Why is this different?
>
>
> PKIX chose not to specify mandatory-to-implement algorithms.  This was
> done because the application that made use of the certificate needed to be
> able to impose such requirements.
>
> Here is one place from the PKIX WG archive in 2011 that states this
> approach:
>
>(https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs
> )
>
>PKIX defines PKI specs for a very wide range of apps, which is why we
>do not mandate any alg suite.  Different apps may use different alg
> suites.
>TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.
>
> It seems to me that ACME is being used to support certificate enrollment
> for many different applications, so the same approach seems appropriate.
>

Hmm... This seems like it would be more persuasive if there weren't a
dependency on TLS and its MTI algorithms

>From my perspective, this is sort of on the bubble. Historically, I've seen
the IESG insist on MTI algorithms, but it's not consistent. I would like to
understand if this is something that has strong consensus in the WG, in
which case I'll support that (though other IESG members may feel
differently) or if it just happened, in which case I'd ask the WG to
reconsider.
-Ekr


> Russ
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Russ Housley]

Eric:

> 
> > > Do you want to specify a set of acceptable signature algorithms here?
> > 
> > I am inclined not to.  We have already forbidden "none" and MAC.  We
> > shouldn't specify "MUST"s here, because CABF sets their own list of
> > required algorithms, and we don't want to conflict.  I guess you
> > could specify some MUST NOTs pretty safely, but given that they're
> > already forbidden by CABF, it seems kind of duplicative.
> 
> This is about the signatures that ACME accepts, not the signatures
> in certs. Does CABF have a position on what signature algorithms
> that ACME uses?
> 
> Good point.  As Ryan pointed out, this is not something on which there is 
> currently CABF guidance.
> 
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.  If 
> they're positive "MUST support" requirements, then we would need to come back 
> and revise this document in the event of an algorithm break (though 
> admittedly, that would be pretty far down on the TODO list).  And looking at 
> the current list of JWS algorithms, I don't see any I would MUST NOT, except 
> possibly the ones based on SHA-1
> 
> Hmm... Common practice in security protocols is to specify MTI algorithms. 
> Why is this different?

PKIX chose not to specify mandatory-to-implement algorithms.  This was done 
because the application that made use of the certificate needed to be able to 
impose such requirements.

Here is one place from the PKIX WG archive in 2011 that states this approach:

   (https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs 
)

   PKIX defines PKI specs for a very wide range of apps, which is why we
   do not mandate any alg suite.  Different apps may use different alg suites.
   TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.

It seems to me that ACME is being used to support certificate enrollment for 
many different applications, so the same approach seems appropriate.

Russ

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

On Sun, May 27, 2018 at 3:00 PM, Richard Barnes  wrote:

> Updated PR:
>
> Responses to comments Github: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/710ef835446231ef954b0f6e448718eef04b63fa
> Responses to this email: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/3dd2a10ee55c13ff87772463374a7c0ab4205d5f
>
> Trimming points on which we agree...
>
> On Fri, May 25, 2018 at 12:09 PM Eric Rescorla  wrote:
>
>> > > IMPORTANT
>> > > S 6.2.
>> > > > algorithm in its "alg" field
>> > > >
>> > > >  o  The JWS Payload MUST NOT be detached
>> > > >  o  The JWS Protected Header MUST include the following fields:
>> > > >
>> > > > *  "alg" (Algorithm)
>> > >
>> > > Do you want to specify a set of acceptable signature algorithms here?
>> >
>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>> > required algorithms, and we don't want to conflict.  I guess you
>> > could specify some MUST NOTs pretty safely, but given that they're
>> > already forbidden by CABF, it seems kind of duplicative.
>>
>> This is about the signatures that ACME accepts, not the signatures
>> in certs. Does CABF have a position on what signature algorithms
>> that ACME uses?
>>
>
> Good point.  As Ryan pointed out, this is not something on which there is
> currently CABF guidance.
>
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
> If they're positive "MUST support" requirements, then we would need to come
> back and revise this document in the event of an algorithm break (though
> admittedly, that would be pretty far down on the TODO list).  And looking
> at the current list of JWS algorithms, I don't see any I would MUST NOT,
> except possibly the ones based on SHA-1
>

Hmm... Common practice in security protocols is to specify MTI algorithms.
Why is this different?




> >
> Perhaps just a forward reference.
>
> "Further down" here just means "the next paragraph".  Over that distance,
> I don't think a forward reference is really helpful :)
>

OK.



>
>>
>> > > S 7.1.2.
>> > > > initiated deactivation.
>> > > >
>> > > >  contact (optional, array of string):  An array of URLs that the
>> > > > server can use to contact the client for issues related to
>> this
>> > > > account.  For example, the server may wish to notify the
>> client
>> > > > about server-initiated revocation or certificate expiration.
>> > >
>> > > How am I supposed to know the semantics of these strings? And if they
>> > > are non-mailto URLs, what am I supposed to do with them.
>> >
>> > To first order, the semantic is defined by the scheme of the URL --
>> > "mailto" says "email me", "sip" or "tel" says "give me a call", etc.
>> > We have the "unsupportedContact" error type if the server doesn't
>> > know how to leverage a given scheme.
>>
>>
>> > Of course there are URL schemes that don't make sense as a contact
>> > point (e.g., "data:"), but trying to enumerate those seems quixotic.
>> > Better for the CA to check and reject with the error code we have
>> > provided.
>>
>> Well, http would also be hard to know what to do.
>>
>> My semantic question, however was: are these all equivalent and
>> undifferentiated?
>>
>
> I'm not sure I totally understand the question here, but I think the
> answer is "yes".  Either the server has code to handle a given contact URL
> scheme or it doesn't, in which case unsupportedContact.
>
>

This doesn't seem entirely clear:
1. What do I send to the HTTP URI, if anything? What method do I use?
2. If there is >1 URI, are they all semantically equivalent.



>> > > S 7.4.
>> > > >
>> > > >  The order object returned by the server represents a promise
>> that if
>> > > >  the client fulfills the server's requirements before the
>> "expires"
>> > > >  time, then the server will be willing to finalize the order
>> upon
>> > > >  request and issue the requested certificate.  In the order
>> object,
>> > > >  any authorization referenced in the "authorizations" array
>> whose
>> > >
>> > > What if the CSR contains extensions which are not mentioned here? For
>> > > instance, say I request a given EKU that the CA doesn't like? Or the
>> > > DelegatedUsage extension from https://tools.ietf.org/html/draft-ietf-
>> > > tls-subcerts-00#section-4.1
>> >
>> > [[ DISCUSS - 1e9937c ]]
>> >
>> > This is an unforutunate consequence of not providing the CSR up
>> > front.  It seems like the right outcome here is for the finalization
>> > request to fail.  It's unclear to me whether the order should also
>> > be invalidated.
>>
>> > I think my proposal would be to fail the finalization, but leave the
>> > order open, and the client can re-try with a CSR that the server
>> > might like better.
>>
>> It seems like the implication of this is that it's not possible to
>> demand additional validation procedures at 

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Eric Rescorla]

Forwarding to the list, per Richard.

On Sun, May 27, 2018 at 3:00 PM, Richard Barnes  wrote:

> Updated PR:
>
> Responses to comments Github: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/710ef835446231ef954b0f6e448718eef04b63fa
> Responses to this email: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/3dd2a10ee55c13ff87772463374a7c0ab4205d5f
>
> Trimming points on which we agree...
>
> On Fri, May 25, 2018 at 12:09 PM Eric Rescorla  wrote:
>
>> > > IMPORTANT
>> > > S 6.2.
>> > > > algorithm in its "alg" field
>> > > >
>> > > >  o  The JWS Payload MUST NOT be detached
>> > > >  o  The JWS Protected Header MUST include the following fields:
>> > > >
>> > > > *  "alg" (Algorithm)
>> > >
>> > > Do you want to specify a set of acceptable signature algorithms here?
>> >
>> > I am inclined not to.  We have already forbidden "none" and MAC.  We
>> > shouldn't specify "MUST"s here, because CABF sets their own list of
>> > required algorithms, and we don't want to conflict.  I guess you
>> > could specify some MUST NOTs pretty safely, but given that they're
>> > already forbidden by CABF, it seems kind of duplicative.
>>
>> This is about the signatures that ACME accepts, not the signatures
>> in certs. Does CABF have a position on what signature algorithms
>> that ACME uses?
>>
>
> Good point.  As Ryan pointed out, this is not something on which there is
> currently CABF guidance.
>
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
> If they're positive "MUST support" requirements, then we would need to come
> back and revise this document in the event of an algorithm break (though
> admittedly, that would be pretty far down on the TODO list).  And looking
> at the current list of JWS algorithms, I don't see any I would MUST NOT,
> except possibly the ones based on SHA-1.
>
>
>
>>
>>
>> > > S 6.3.
>> > > >  As noted in Section 6.2 above, all ACME request objects carry
>> a "url"
>> > > >  header parameter in their protected header.  This header
>> parameter
>> > > >  encodes the URL to which the client is directing the request.
>> On
>> > > >  receiving such an object in an HTTP request, the server MUST
>> compare
>> > > >  the "url" header parameter to the request URL.  If the two do
>> not
>> > > >  match, then the server MUST reject the request as unauthorized.
>> > >
>> > > I think you probably need to provide a clear definition of how you
>> > > "compare" them. Is it memcmp? Something else?
>> >
>> > This is specified further down:
>> >
>> > """
>> > The server SHOULD perform the corresponding string equality check,
>> > configuring each resource with the URL string provided to clients
>> > and having the resource check that requests have the same string in
>> > their “url” header parameter.
>> > """
>>
>> Perhaps just a forward reference.
>>
>
> "Further down" here just means "the next paragraph".  Over that distance,
> I don't think a forward reference is really helpful :)
>
>
>
>>
>> > > S 7.1.2.
>> > > > initiated deactivation.
>> > > >
>> > > >  contact (optional, array of string):  An array of URLs that the
>> > > > server can use to contact the client for issues related to
>> this
>> > > > account.  For example, the server may wish to notify the
>> client
>> > > > about server-initiated revocation or certificate expiration.
>> > >
>> > > How am I supposed to know the semantics of these strings? And if they
>> > > are non-mailto URLs, what am I supposed to do with them.
>> >
>> > To first order, the semantic is defined by the scheme of the URL --
>> > "mailto" says "email me", "sip" or "tel" says "give me a call", etc.
>> > We have the "unsupportedContact" error type if the server doesn't
>> > know how to leverage a given scheme.
>>
>>
>> > Of course there are URL schemes that don't make sense as a contact
>> > point (e.g., "data:"), but trying to enumerate those seems quixotic.
>> > Better for the CA to check and reject with the error code we have
>> > provided.
>>
>> Well, http would also be hard to know what to do.
>>
>> My semantic question, however was: are these all equivalent and
>> undifferentiated?
>>
>
> I'm not sure I totally understand the question here, but I think the
> answer is "yes".  Either the server has code to handle a given contact URL
> scheme or it doesn't, in which case unsupportedContact.
>
>
>
>> > > S 7.4.
>> > > >
>> > > >  The order object returned by the server represents a promise
>> that if
>> > > >  the client fulfills the server's requirements before the
>> "expires"
>> > > >  time, then the server will be willing to finalize the order
>> upon
>> > > >  request and issue the requested certificate.  In the order
>> object,
>> > > >  any authorization referenced in the "authorizations" array
>> whose
>> > >
>> > > What if the CSR contains extensions which are not mentioned here? For
>> > > 

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

On Tue, May 15, 2018 at 2:37 AM Ilari Liusvaara 
wrote:

> On Tue, May 15, 2018 at 01:20:14AM +, Richard Barnes wrote:
> >  [ Adding the mailing list ]
> >
> > > S 6.6.
> > > >  |
> > | |
> > > >  | serverInternal  | The server experienced an
> > internal  |
> > > >  | |
> > error   |
> > > >  |
> > | |
> > > >  | tls | The server received a TLS error
> > during  |
> > > >  | |
> > validation  |
> > >
> > > Can you expand on what this means? Suppose instead I got a 500 during
> > > validation?
> >
> > [[ EDIT - 272c754 ]]
> >
> > I think this goes back to when the TLS-SNI challenge.  It's no longer
> > relevant here, so I've removed it.  The new TLS-based challenge can
> re-add
> > it if they need it.
>
> This is incorrect. It is neeed by HTTP-01 already, because that can
> redirect to https://, which then tries to set up TLS, which can fail
> even when the TCP connection succeeded. And given flakyness of
> validation in general, one does not want misleading errors to make
> things even harder.
>

Good point.  I've backed out this change in my working copy.

--Richard



>
> One of the more creative ones I have heard about is misconfigured
> servers that interpret the TLS ClientHello as malformed HTTP request
> and sends back HTTP 400 Bad Request, which the TLS client then tries
> to parse as ServerHello and obviously chokes. This issue is apparently
> not that rare, in fact, Let's Encrypt specifically checks for TLS
> ServerHellos that look like HTTP replies.
>
>
> -Ilari
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Ryan Sleevi]

On Fri, May 25, 2018 at 12:08 PM, Eric Rescorla  wrote:
>
> > > IMPORTANT
> > > S 6.2.
> > > > algorithm in its "alg" field
> > > >
> > > >  o  The JWS Payload MUST NOT be detached
> > > >  o  The JWS Protected Header MUST include the following fields:
> > > >
> > > > *  "alg" (Algorithm)
> > >
> > > Do you want to specify a set of acceptable signature algorithms here?
> >
> > I am inclined not to.  We have already forbidden "none" and MAC.  We
> > shouldn't specify "MUST"s here, because CABF sets their own list of
> > required algorithms, and we don't want to conflict.  I guess you
> > could specify some MUST NOTs pretty safely, but given that they're
> > already forbidden by CABF, it seems kind of duplicative.
>
> This is about the signatures that ACME accepts, not the signatures
> in certs. Does CABF have a position on what signature algorithms
> that ACME uses?
>

The Baseline Requirements do not establish any policies here regarding
proof of key possession (which is not required, strictly speaking) or
domain name validation methods, or on the authentication channel between
the Applicant and CA.

For example, 3.2.2.4.6 of the BRs (at time of writing,
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.7-29-Apr-2018.pdf
) allow the use of MD2 or MD4 as part of their request token construction
or within the use of CSRs.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Ilari Liusvaara]

On Tue, May 15, 2018 at 01:20:14AM +, Richard Barnes wrote:
>  [ Adding the mailing list ]
> 
> > S 6.6.
> > >  |
> | |
> > >  | serverInternal  | The server experienced an
> internal  |
> > >  | |
> error   |
> > >  |
> | |
> > >  | tls | The server received a TLS error
> during  |
> > >  | |
> validation  |
> >
> > Can you expand on what this means? Suppose instead I got a 500 during
> > validation?
> 
> [[ EDIT - 272c754 ]]
> 
> I think this goes back to when the TLS-SNI challenge.  It's no longer
> relevant here, so I've removed it.  The new TLS-based challenge can re-add
> it if they need it.

This is incorrect. It is neeed by HTTP-01 already, because that can
redirect to https://, which then tries to set up TLS, which can fail
even when the TCP connection succeeded. And given flakyness of
validation in general, one does not want misleading errors to make
things even harder.

One of the more creative ones I have heard about is misconfigured
servers that interpret the TLS ClientHello as malformed HTTP request
and sends back HTTP 400 Bad Request, which the TLS client then tries
to parse as ServerHello and obviously chokes. This issue is apparently
not that rare, in fact, Let's Encrypt specifically checks for TLS
ServerHellos that look like HTTP replies.


-Ilari

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] AD Review: draft-ietf-acme-acme-12

[Richard Barnes]

 [ Adding the mailing list ]

Thanks for the thorough review, EKR.  I've posted a PR with proposed
resolutions:

https://github.com/ietf-wg-acme/acme/pull/425

You do hit on a couple of moderately technical points, some of which I
would like the WG to take a quick look at.  Those are highlighted with
"DISCUSS" below.  Simple edits are tagged with "EDIT", and questions for
the AD are marked with "QUESTION".  Ones where I don't think there's a need
for a change are unmarked.

Rather than split things out into separate PRs, I've just made one big PR,
with issues in different commits.  The various issue tags below include the
ID of the corresponding commits.

Chairs / AD: While there are a couple of issues here where I'd like some
eyes besides the authors, I would propose that if we do a re-WGLC, it be
abbreviated, say 1 week.  I do not think these changes merit a new IETF LC.

Thanks,
--Richard


> Because I am now the sponsoring AD for this document, I have performed
> my own review.
>
> This document seems technically sound and is well-written. I have
> raised a number of points below for consideration.
>
>
> IMPORTANT
> S 6.2.
> > algorithm in its "alg" field
> >
> >  o  The JWS Payload MUST NOT be detached
> >  o  The JWS Protected Header MUST include the following fields:
> >
> > *  "alg" (Algorithm)
>
> Do you want to specify a set of acceptable signature algorithms here?

I am inclined not to.  We have already forbidden "none" and MAC.  We
shouldn't specify "MUST"s here, because CABF sets their own list of
required algorithms, and we don't want to conflict.  I guess you could
specify some MUST NOTs pretty safely, but given that they're already
forbidden by CABF, it seems kind of duplicative.


> S 6.3.
> >  As noted in Section 6.2 above, all ACME request objects carry a
"url"
> >  header parameter in their protected header.  This header parameter
> >  encodes the URL to which the client is directing the request.  On
> >  receiving such an object in an HTTP request, the server MUST
compare
> >  the "url" header parameter to the request URL.  If the two do not
> >  match, then the server MUST reject the request as unauthorized.
>
> I think you probably need to provide a clear definition of how you
> "compare" them. Is it memcmp? Something else?

This is specified further down:

"""
The server SHOULD perform the corresponding string equality check,
configuring each resource with the URL string provided to clients and
having the resource check that requests have the same string in their “url”
header parameter.
"""


> S 6.4.1.
> >
> >  The value of the Replay-Nonce field MUST be an octet string encoded
> >  according to the base64url encoding described in Section 2 of
> >  [RFC7515].  Clients MUST ignore invalid Replay-Nonce values.
> >
> >base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"
>
> I am surprised you need to define the BNF for this here. Aren't you
> now creating a separate normative definition.

I can see why this is surprising.  After a bit of searching, though, I
can't find another set of ABNF that matches.  For example, RFC 5802 (SASL
SCRAM) defines its own ABNF for Base64 (in the normal "+/=" encoding), as
does RFC 8224 (SIP Identity).  I note that the list of authors on the
latter includes a certain Mr. Rescorla :)

https://tools.ietf.org/html/rfc5802#section-7
https://tools.ietf.org/html/rfc8224#section-4


> S 7.1.2.
> > initiated deactivation.
> >
> >  contact (optional, array of string):  An array of URLs that the
> > server can use to contact the client for issues related to this
> > account.  For example, the server may wish to notify the client
> > about server-initiated revocation or certificate expiration.
>
> How am I supposed to know the semantics of these strings? And if they
> are non-mailto URLs, what am I supposed to do with them.

To first order, the semantic is defined by the scheme of the URL --
"mailto" says "email me", "sip" or "tel" says "give me a call", etc.  We
have the "unsupportedContact" error type if the server doesn't know how to
leverage a given scheme.

Of course there are URL schemes that don't make sense as a contact point
(e.g., "data:"), but trying to enumerate those seems quixotic.  Better for
the CA to check and reject with the error code we have provided.


> S 7.1.3.
> > authorizations required are dictated by server policy and there
> > may not be a 1:1 relationship between the order identifiers and
> > the authorizations required.  For final orders (in the "valid"
or
> > "invalid" state), the authorizations that were completed.  Each
> > entry is a URL from which an authorization can be fetched with a
> > GET request.
>
> This text seems inconsistent with "immutable" below, because if I have
> completed authorization "a" then I don't need to complete it, but it
> has to stay in the list.

[[ EDIT -