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

[Russ Housley <[e-mail]>]

Uri:

RFC 5280 encourages the rfc822name to be carried in the subjectAltName extension.  It does accommodate "legacy" implementations, as did RFC 2459 in 1999.

RFC 2459 said:

   In addition, legacy implementations exist where an RFC 822 name is
   embedded in the subject distinguished name as an EmailAddress
   attribute.  The attribute value for EmailAddress is of type IA5String
   to permit inclusion of the character '@', which is not part of the
   PrintableString character set.  EmailAddress attribute values are not
   case sensitive (e.g., "[e-mail]" is the same as
   "[e-mail]").

It it was "legacy" in 1999, it is probably well past time to require the email address to be in the subjectAltName extension.

Russ


> On Feb 2, 2022, at 4:11 PM, Blumenthal, Uri - 0553 - MITLL <[e-mail]> wrote:
> 
> 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] <mailto:[e-mail]>> on behalf of Daniel Kahn Gillmor <[e-mail] <mailto:[e-mail]>>
> Date: Wednesday, February 2, 2022 at 15:58
> To: Éric Vyncke <[e-mail] <mailto:[e-mail]>>, The IESG <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[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
> _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>