Re: [Anima] towards using of MUST-/SHOULD+/SHOULD- in draft-ietf-autonomic-control-plane-24

[Russ Housley <[e-mail]>]

> On Jun 26, 2020, at 6:02 PM, Michael Richardson <[e-mail]> wrote:
> 
> 
> Russ Housley <[e-mail]> wrote:
>>> <t>ACP nodes MUST NOT support certificates with RSA public keys of
>>> less than 2048 bits. They MUST support certificates with RSA public keys
>>> with 2048 bits and SHOULD support longer RSA keys. ACP nodes MUST
>>> support certificates with ECC public keys using NIST P-256, P-384 and
>>> P-521 curves.</t>
>>> 
>>> <t>ACP nodes MUST support SHA-256, SHA-384, SHA-512 signatures for certificates with RSA key and the same RSA signatures plus ECDSA signatures for certificates with ECC key.</t>
>>> ---
>>> 
>>> I don't understand whether your note about the key length of the curves is an indication of missing text. When i first reviewed with Ben, i had to enter the curves because thats as specific as necessary AFAIK, but given how the key length is implied, i wouldn't understand why i would need to write those down. I don't remember that i have seen that being done either in other RFCs i read through.
>>> 
>>> In any case, specific text suggestions always welcome in case this text is not sufficient.
> 
>    russ> I was expecting you to make one of the curves MUST and the others
>    russ> SHOULD. Making all three curves MUST is okay with me, but it will
>    russ> increase implementation size.
> 
>    russ> Likewise, I was expecting you to make one of the hash functions
>    russ> MUST and the others SHOULD.
> 
> I tried to convince Toerless to go with the MUST-/SHOULD+/SHOULD- terminology from
> IPsecME's RFC8247.
> 
> It would be nice if SAAG lifted section 1.1 into a BCP14-like document, as I
> think that it has widespread applicability throughout documents that want to
> establish interoperable crypto.

IPsec ad S/MIME have been using MUST-/SHOULD+/SHOULD- terminology for a long time.  I'd be willing to help with a BCP14-like document for them.

Russ