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

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jun 2020 18:02:31 -0400

Russ Housley <[email-masked]> 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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Jun 2020 17:08:49 -0500

On Fri, Jun 26, 2020 at 06:02:31PM -0400, Michael Richardson wrote:
> 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.

Is there are reason that RFC8247's {MUST,SHOULD}[-+] wouldn't be
generally applicable beyond crypto?  The -/+ thing is about pithily
indicating likelihood of future downgrade/upgrade of the requirement/
recommendation -- seems generally applicable to me.

So.. just update RFC2119.

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Jun 2020 19:58:24 -0400

> On Jun 26, 2020, at 6:02 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Jun 2020 21:15:19 -0400

> So.. just update RFC2119.

1) So, BCPs can point to multiple documents.
   BCP14 actually is RFC2119 and RFC8174 now, so we can add a third document if
   desired. That is, it's cheaper to not spin 2119.

2) I'm not claiming others won't use it, I just don't know if they will.
   Crypto progresses... what other things do that in the same way?

---

From: Nico Williams <[email-masked]>
Date: Fri, 26 Jun 2020 22:06:24 -0500

>    desired. That is, it's cheaper to not spin 2119.

Sure.  Plus, RFC2119 is iconic, and used far and wide outside the IETF.

>    Crypto progresses... what other things do that in the same way?

Any time we have a migration from one [sub]protocol to a newer one and
need to retain support for the old one for a while, we will need
something like SHOULD-.  I agree this comes up most often in the context
of cryptographic algorithms.

Nico
--

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jun 2020 16:05:41 +1200

> of cryptographic algorithms.

Interesting discussion but I want to see the ACP in the RFC Editor queue, can we just do what is required for that and nothing else?

I am about a millimetre away from proposing to recall the GRASP spec from the RFC Editor so that we can amputate its normative dependency on the ACP. I really wish I'd done that a year ago.

    Grumpy Brian

---

From: Nico Williams <[email-masked]>
Date: Sat, 27 Jun 2020 00:01:38 -0500

On Sat, Jun 27, 2020 at 04:05:41PM +1200, Brian E Carpenter wrote:
> Interesting discussion but I want to see the ACP in the RFC Editor
> queue, can we just do what is required for that and nothing else?
> 
> I am about a millimetre away from proposing to recall the GRASP spec
> from the RFC Editor so that we can amputate its normative dependency
> on the ACP. I really wish I'd done that a year ago.

I don't follow GRASP, or ACP, so I've no idea what you're talking about,
but I don't see how this discussion could keep ACP from progressing.  In
particular, no one is proposing to update BCP14 and make that a prereq
for ACP progressing.

Nico
--

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Jun 2020 17:05:53 +1200

> particular, no one is proposing to update BCP14 and make that a prereq

Sorry about my tone, but this seems like a discussion for gendispatch, not
anima.

   Brian

---

From: Nico Williams <[email-masked]>
Date: Sat, 27 Jun 2020 00:12:30 -0500

On Sat, Jun 27, 2020 at 05:05:53PM +1200, Brian E Carpenter wrote:
> Sorry about my tone, but this seems like a discussion for gendispatch,
> not anima.

Well, look at the distribution list: Michael clearly meant for SAAG to
see this, and for anima to see his post in case anyone there cares.  I
agree that some other list might be better still, and setting Reply-To:
would have helped keep noise down on anima.  I'm setting Reply-To: now.