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

[Richard Barnes]

On Thu, May 31, 2018 at 5:09 PM Eric Rescorla  wrote:

>
>
> On Thu, May 31, 2018 at 2:03 PM, Richard Barnes  wrote:
>
>>
>>
>> On Wed, May 30, 2018 at 5:41 PM Stephen Farrell <
>> stephen.farr...@cs.tcd.ie> wrote:
>>
>>>
>>> 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.
>>>
>>
>> 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.
>>
>
> I made that proposal in a separate message: ECDSA w/ P-256 MUST,  EdDSA
> X25519 SHOULD.
>

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


>
> -Ekr
>
>
>> --Richard
>>
>> [1]
>> https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
>>
>> ___
>> 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] Do we need/want mandatory-to-implement signature algorithms?

[Eric Rescorla]

On Thu, May 31, 2018 at 2:03 PM, Richard Barnes  wrote:

>
>
> On Wed, May 30, 2018 at 5:41 PM Stephen Farrell 
> wrote:
>
>>
>> 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.
>>
>
> 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.
>

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
> 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] Do we need/want mandatory-to-implement signature algorithms?

[Richard Barnes]

On Wed, May 30, 2018 at 5:41 PM Stephen Farrell 
wrote:

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

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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Stephen Farrell]

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.



0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

[Russ Housley]

> On May 30, 2018, at 3:54 PM, Salz, Rich  
> 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.
>  
> 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.

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 
)

   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

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

[Salz, Rich]

  *   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

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