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

["Eric Vyncke (evyncke)" <[e-mail]>]

Daniel

Thank you for your reply, it is indeed sensible not to have dozens of invalid certs

Regards

-éric


On 02/02/2022, 21:57, "Daniel Kahn Gillmor" <[e-mail]> wrote:

    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