Re: [lamps] Éric Vyncke's No Objection on draft-ietf-lamps-samples-07: (with COMMENT)

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

I’m not sure I’m happy to see an S/MIME cert declared invalid for absence of SAN attribute.

 

--

Regards,                     

Uri

 

There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.

                                                                                                                                     -  C. A. R. Hoare

 

 

From: Spasm <[e-mail]> on behalf of Daniel Kahn Gillmor <[e-mail]>
Date: Wednesday, February 2, 2022 at 15:58
To: Éric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [lamps] Éric Vyncke's No Objection on draft-ietf-lamps-samples-07: (with COMMENT)

Hi Éric--

On Mon 2022-01-03 04:40:20 -0800, Éric Vyncke via Datatracker wrote:
> -- Section 2.2 & 2.3 --
> Would it be useful to include expired certificates ?

This is a great question, and the LAMPS WG did consider it during
discussion of the draft.  The conclusion that we came to (which i helped
to drive, as editor) is that there are *many* ways that a certificate
can be invalid (in general, or for use with S/MIME in particular), and a
draft that hosts a zoo of invalid certificates would be much larger and
more complex than this simple document.

Expiration is one flavor of invalidity, but why not also test missing
subjectAltName?  or subtly wrong keyUsage or eKU?  or a malformed public
key?  and so on…  It's kind of like Anna Karenina 😛

Rather than try to decide (and fight over) what sort of invalid
certificates to supply in the draft, we decided to stick with just valid
certs here.

The certs should be valid for about three decades, so hopefully in that
time they'll be useful for a lot of different projects.

> And/or a CRL for those examples ? Would providing those additional
> examples make possible more extensive testing?

The certs are expected to be used for testing, and to be used without
having to maintain any online infrastructure for this testing.

§2.3 specifically says "none of the certificates include either an OCSP
indicator or a CRL indicator", so i think including a CRL would just add
to the confusion.

If we want to produce samples that expire or can be revoked, i think
that would be a separate project, similar to the "multiple forms of
invalidity" described above.

> -- Section 4 --
> <joke>Please s/Alice Lovelace/Ada Lovelace/ ;-) </joke> (to be ignored of
> course but I could not resist) Alas not applicable to Charles/Bob Babbage or
> Alan/Carlos Turing or Grace/Dana Hopper :-)

we each nod to the legends in our own peculiar ways :)

   --dkg