Re: [Lake] 🔔 WG last call for draft-ietf-lake-traces-04

[John Mattsson <[e-mail]>]

I made another commit.
https://github.com/lake-wg/edhoc/commit/75c067174f22541fc82191d124596ad861d26ece

RFC 5280 also requires that key usage is included in CA certs. I think that all three certificates are compliant with RFC 5280.

Cheers,
John

From: Lake <[e-mail]> on behalf of John Mattsson <john.mattsson=[e-mail]>
Date: Monday, 12 June 2023 at 11:12
To: Stephen Farrell <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Lake] 🔔 WG last call for draft-ietf-lake-traces-04
Hi Stephen,

I fixed the problem with the missing notBefore
https://github.com/lake-wg/edhoc/commit/3aece25c3bf201a6ba844ec3acf7500804fb53b2<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-1ea78e9e6bb1937d&q=1&e=7ac4ca6b-e3e8-4456-a2f3-e7cc48f017e8&u=https%3A%2F%2Fgithub.com%2Flake-wg%2Fedhoc%2Fcommit%2F3aece25c3bf201a6ba844ec3acf7500804fb53b2>

Regarding basic constraints, I don’t think this is a big problem for the end-entity certificates, but it is a problem for the “common root certificate”. RFC 5280 states:

   “If the basic constraints extension is not present in a
   version 3 certificate, or the extension is present but the cA boolean
   is not asserted, then the certified public key MUST NOT be used to
   verify certificate signatures.”

This need to be fixed. I will add basic constraints for the “common root certificate”. The traces will not be affected. After that I think traces is ready for IETF last call.

Cheers,
John


From: Lake <[e-mail]> on behalf of Stephen Farrell <[e-mail]>
Date: Saturday, 29 April 2023 at 01:25
To: Göran Selander <[e-mail]>, Mališa Vučinić <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Lake] 🔔 WG last call for draft-ietf-lake-traces-04

Hiya,

On 28/04/2023 15:58, Göran Selander wrote:
> Version -05 is out. I also removed an editor’s note and information
> about where to find test vectors which was not up-to-date.
That looks good to me. One nit though, the certificate in
3.8.1 [1] is missing it's notBefore value. I assume fixing
that doesn't require new traces though, so just do that at
your leisure.

I also see that the sample certificates don't contain any
extensions. It's normal to include basic constraints so if
for some reason you do need to regenerate traces, I wonder
if adding those would an idea. (But don't regenerate the
traces just for that.)

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-lake-traces-05#name-certificates