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

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

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

 

The problem with RFC 5280 is that in practice it facilitates “one cert <-> one email address”.

Originally, S/MIME was conceived to allow me to send email from an account/address, and prove that I’m the originator of it (I as the owner of the given certificate, not (necessarily) of the given email address.

 

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

 

Among other things, it prevents me from signing (or decrypting) emails on more than one rfc822 address using hardware token.

 

In theory, it should be possible to either omit SAN altogether, because my purpose is proving authenticity of the sender, not sender’s address – or, if there’s insistence on addressed, add multiple SAN for multiple email addresses.

 

In practice, while CA would issue me a cert with either no SAN, or multiple SAN – most common corporate email clients (MS Outlook, Apple Mail, don’t recall offhand how Thunderbird behaves) would reject a cert with no SAN, and process only the first SAN if there’s more than one (though I do seem to recall that one of these clients failed a cert with multiple SAN altogether).

 

<Rant>I consider this SAN insistence as a big email screw-up.</Rant>

 

 

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]> 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

_______________________________________________
Spasm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spasm" rel="nofollow">https://www.ietf.org/mailman/listinfo/spasm