Subject: [lamps] draft-ietf-lamps-samples KU check

From: Sean Turner <[email-masked]>
Date: Fri, 25 Mar 2022 06:49:54 -0400

tl;dr: looks good, but I didn’t check the P12 blobs.

Checking for KU bit string and RFC 8813 “compliance”:

s3.1/s3.3 RSA CA certs have KU set to 0000011. This is good; it’s just keyCertSign and cRLSign. I mean you can set more bits but if you don’t have to don’t.

s4.1/s5.1 an RSA sig cert has KU set to 11. This sets both digitalSignature and nonRepudiation. You can set one, the other, or both so this is "good”. I have a slight bias to drop nonRepudiation, but the choice is “compliant”.

s4.2/s5.2 an RSA enc cert has KU set to 001. This is good; it’s just keyEncipherment.

Checking for KU bit string and 8410/draft-ietf-lamps-ku-clarifications "compliance”:

s6.1/6.3 ed25519 CA certs has KU set to 0000011. This is good; it’s just keyCertSign and cRLSign. I mean you can set more bits but if you don’t have to don’t.

s7.1/s8.1 an ed25519 sig cert has KU set to 11. This sets both digitalSignature and nonRepudiation. You can set one, the other, or both so this is "good”. I have a slight bias to drop nonRepudiation, but the choice is “compliant”.

s7.3/8.3 an x25519 enc cert has KU set to 00001. This is good; it’s just keyAgreement.

Cheers,
spt

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 25 Mar 2022 07:28:27 -0400

Thanks for double-checking the KUs in draft-ietf-lamps-samples, Sean!

> tl;dr: looks good, but I didn’t check the P12 blobs.

The P12 blobs are just generated from the other material, so that should
be fine.

> s7.1/s8.1 an ed25519 sig cert has KU set to 11. This sets both
> digitalSignature and nonRepudiation. You can set one, the other, or
> both so this is "good”. I have a slight bias to drop nonRepudiation,
> but the choice is “compliant”.

The draft is in AUTH48 now.  The hope is that these keys and certs will
be used to test implementations in MUAs in the future.  It seems
possible that their parameter choices will be cargo-culted into
some certificate profiles for S/MIME at some point.

I'm inclined to leave them as-is, but if there are scenarios where you
think that the inclusion of nonRepudiation is a bad idea, please let the
WG know.  i'm willing to do another round of revisions on the draft if
there is a compelling reason.

       --dkg

---

From: Sean Turner <[email-masked]>
Date: Fri, 25 Mar 2022 07:44:59 -0400

> On Mar 25, 2022, at 07:28, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

It is perfectly fine to leave them as is. The Certificate Policy drives whether NR is set or not.

spt