Subject: [Acme] Do we need/want mandatory-to-implement signature algorithms?

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 May 2018 19:54:14 +0000

*   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.

This came up in the “AD review” thread that many of you have probably just seen and skimmed or ignored. :)

ACME does not define any mandatory-to-implement signature algorithms.  To the best of my recollection, this has never come up, and Eric reasonably asks that we not just say “silence gives consensus.”

SO, if anyone feels we should define a set of MTI signature algorithms for ACME, please speak up now. If you do so, consider proposing what they should be.  Please reply within a week.

Thanks.
                /r$, co-chair

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 May 2018 17:31:27 -0400

> On May 30, 2018, at 3:54 PM, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> 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.
>  

I already spoke on the previous thread.  I will repeat it here...

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 <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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 May 2018 22:40:55 +0100

Hi Russ,

On 30/05/18 22:31, Russ Housley wrote:
> It seems to me that ACME is being used to support certificate
> enrollment for many different applications, so the same approach
> seems appropriate.
I agree with your description of the past:-)

I don't agree with not specifying MTI algs though.

My main reasons are that I think having MTI algorithms for
acme may lead to better interop and less proliferation of
algorithms/suites and less broken/non-tested code. (I
forget what I thought about this years ago, but I may have
changed opinion - it was reasonable for PKIX to not specify
MTI algs a decade or two ago, but that that is no longer a
good plan, as we now do really use all this stuff.)

That said, I don't feel too strongly about it - in practice
I reckon all acme clients will in any case want to implement
and be able to use whatever works with LE, at least for the
next while, and so this won't be a practical problem either
way.

Cheers,
S.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 31 May 2018 17:03:32 -0400

> next while, and so this won't be a practical problem either

I am also not that sanguine about this topic, but I lean in the opposite
direction.  The list of JWS algorithms [1] is not that long, and not
growing quickly.  And there's no Ed25519.  So if we were to pick one or
more MTIs out of this list, we would basically be locking in to ECDSA or
RSA-PSS.

As far as MTnotI: The SHA-1-based algorithms are already marked
"Prohibited".  I guess you could ban RSA with PKCS#1v1.5, but that seems
fairly low-value.

Basically, it seems like the burden of those who want MUSTs here to make a
proposal for what the MUSTs would be.

--Richard

[1]
https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 May 2018 14:09:02 -0700

On Thu, May 31, 2018 at 2:03 PM, Richard Barnes <[email-masked]> wrote:

> "Prohibited".  I guess you could ban RSA with PKCS#1v1..5, but that seems
> fairly low-value.
>

I made that proposal in a separate message: ECDSA w/ P-256 MUST,  EdDSA
X25519 SHOULD.

-Ekr

> --Richard
>
> [1] https://www.iana.org/assignments/jose/jose.xhtml#
> web-signature-encryption-algorithms
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 31 May 2018 17:15:24 -0400

On Thu, May 31, 2018 at 5:09 PM Eric Rescorla <[email-masked]> wrote:

>> On Wed, May 30, 2018 at 5:41 PM Stephen Farrell <
>> [email-masked]> wrote:
>>
>>>
>>> Hi Russ,
>>>
>> Basically, it seems like the burden of those who want MUSTs here to make
>> a proposal for what the MUSTs would be.
>>
>

Sorry, missed that in the thread switch.

I could live with that.  I was incorrect when I said Ed25519 doesn't exist
for JWS; I had missed the "EdDSA" value defined in RFC 8037.

--Richard