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

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 02 Feb 2022 15:43:29 -0500

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 2 Feb 2022 21:11:52 +0000

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 <[email-masked]> on behalf of Daniel Kahn Gillmor <[email-masked]>
Date: Wednesday, February 2, 2022 at 15:58
To: Éric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [lamps] Éric Vyncke's No Objection on draft-ietf-lamps-samples-07: (with COMMENT)

Hi Éric--

--dkg

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Feb 2022 16:46:10 -0500

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., "[email-masked]" is the same as
   "[email-masked]").

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 <[email-masked]> wrote:
> 
> From: Spasm <[email-masked] <mailto:[email-masked]>> on behalf of Daniel Kahn Gillmor <[email-masked] <mailto:[email-masked]>>
> To: Éric Vyncke <[email-masked] <mailto:[email-masked]>>, The IESG <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> _______________________________________________
> Spasm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 2 Feb 2022 22:04:14 +0000

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.

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>

--

Regards,

Uri

-  C. A. R. Hoare

Hi Éric--

--dkg

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Feb 2022 17:24:34 -0500

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

I do not understand this view.

RFC 5280 says: "If the subjectAltName extension is present, the sequence MUST contain at least one entry."  This structure allows many GeneralName entries, and there is no requirement that a name form only be used only once.  So, several email addresses could be included, but of course, the CA needs to validate all of them.

From a user interface perspective, and email client would need to confirm that the sender's email address is present in one of the subjectAltName extension entries.

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 02 Feb 2022 17:28:55 -0500

> From a user interface perspective, and email client would need to confirm that the sender's email address is present in one of the subjectAltName extension entries.

Thank you both for the informative discussion, as well as for confirming
that figuring out *which* malformed certificates to include in
draft-ietf-lamps-samples would have been an adventure down the rabbit
hole. ☺

      --dkg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 2 Feb 2022 23:10:24 +0000

Correct, in theory. In practice, while CA would validate those addresses and issue a cert with several SAN entries, the actual email clients won’t accept those certs – or would accept for only one (usually, the first) SAN entry.

Agreed, not exactly following 5280 – but can you argue with MS or Apple? I tried – unsuccessfully.

>From a user interface perspective, and email client would need to confirm that the sender's email address is present in one of the subjectAltName extension entries.

Arguable – if I get an email from you, I care that it’s from Russ Housley, rather than from [email-masked] .  But that’s my personal opinion – the real problem is not validating email addresses (though I find it unnecessary) – but refusal by the actual commercial email clients to accept a cert with more than one SAN (aka, more than one email address specified).

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 03 Feb 2022 01:08:19 -0500

> Agreed, not exactly following 5280 – but can you argue with MS or Apple? I tried – unsuccessfully.

Are you saying that you asked MS and Apple to ensure that their MUAs
(Outlook and Mail.app?) would accept a certificate that has multiple
e-mail addresses in it, and they declined?  and it doesn't currently
work? (i haven't tested)

Is there a public record of that attempt?  Did MS or Apple have a
specific reason to not want it?

         --dkg

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 3 Feb 2022 06:50:31 +0000

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" <[email-masked]> wrote:

    Hi Éric--

       --dkg

---

From: "Brown, Wendy (10421)" <[email-masked]>
Date: Thu, 3 Feb 2022 12:37:29 +0000

There may be a register setting required, but outlook will let you use certificates that have an rfc822Name that does not match your current email and I thought it also accepted certificates with multiple email SANs, although I have not test that recently.

-----Original Message-----
From: Daniel Kahn Gillmor <[email-masked]> 
Sent: Thursday, February 3, 2022 1:08 AM
To: Blumenthal, Uri - 0553 - MITLL <[email-masked]>; Russ Housley <[email-masked]>
Cc: LAMPS <[email-masked]>
Subject: Re: [lamps] Éric Vyncke's No Objection on draft-ietf-lamps-samples-07: (with COMMENT)

> Agreed, not exactly following 5280 – but can you argue with MS or Apple? I tried – unsuccessfully.

Are you saying that you asked MS and Apple to ensure that their MUAs (Outlook and Mail.app?) would accept a certificate that has multiple e-mail addresses in it, and they declined?  and it doesn't currently work? (i haven't tested)

Is there a public record of that attempt?  Did MS or Apple have a specific reason to not want it?

         --dkg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 3 Feb 2022 12:57:23 +0000

>> Agreed, not exactly following 5280 – but can you
>> argue with MS or Apple? I tried – unsuccessfully.
>
> (Outlook and Mail.app) would accept a certificate that has multiple
> e-mail addresses in it,

Exactly.

> and they declined? 

More accurate would be to say "did not dignify with an answer".

> and it doesn't currently work? (i haven't tested)

Correct, at least when I tested last (several years ago). We gave up since, and don't issue multi-SAN email certs anymore - why bother. 

As I recall, the cert would be recognized as valid - but it won't sign outgoing or decrypt incoming email if the SAN is not the first in the SEQUENCE. Truth is - I don't remember the details by now. Might've been that their software didn't take such a cert at all. 

> Is there a *public* record of that attempt? 

I'm afraid not, sorry.

> Did MS or Apple have a specific reason to not want it?

Not having consumed my morning coffee yet, I'm itching to reply "only stupidity, obstinance, and inertia".
Seriously, I don't know, and professionally/technically am not aware of any possible good reason - especially since 5280 *does* allow that use case.