Subject: [lamps] WG adoption of draft-dkg-lamps-samples ?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 04 Nov 2020 09:08:29 -0500

Hi LAMPS folks--

As I'm working on the header protection draft, I find it would be useful
to have well-known key and certificate material that can be used for the
test vectors.

In related past work, I've used the S/MIME certificates and keys (and
certificate authority) that I published last year in
draft-dkg-lamps-samples:

   https://datatracker.ietf.org/doc/draft-dkg-lamps-samples/

This draft is now expired, but the data contained in there is still
useful.  It consists of certificate and secret key material for three
parties: a certificate authority, and two correspondents: Alice and Bob.
The sample certificates for Alice and Bob are both issued by the sample
certificate authority.

I don't think there's anything objectionable or complicated in the
document, and the contents should be easy for people to test.

This does not fall into one of the three numbered bullets in the LAMPS
charter, but it's certainly relevant to LAMPS as it touches on both
S/MIME (the certificates are intended for e-mail use) and X.509.

I'd like to produce a permanent, WG-reviewed reference for this
material, which i think means WG adoption.  Alternately, i can pursue
the independent-stream, but i would much rather have WG eyes on it.

I could take this through SECDISPATCH, but i'm sure it would be routed
here.

So, I'm asking for WG adoption of this document.  If the chairs think
we'd need a charter revision to adopt it, I propose adding the following
paragraph to the charter:

    4. Publication of sample keys and certificates for use with
       S/MIME. Having stable, well-known keys and certificates for use
       in generating test vectors will facilitate testing and
       interoperability among S/MIME-enabled e-mail implementations.

I'm happy to cede authority on the document to the WG consensus.  I
volunteer to continue as editor of the document in this case, but i'd
also be happy if someone else wanted to edit it.

    --dkg

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 11:31:16 -0500

> the independent-stream, but i would much rather have WG eyes on it.

I think that it's very very useful to have test vectors here.
They need to be renewed regularly as algorithms and key sizes changes.
Old ones are even valuable because they are expired.

    > paragraph to the charter:

I think that the WG should adopt it, and I don't think that we need a
charter revision to do so.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 11:38:14 -0500

> https://datatracker.ietf.org/doc/draft-dkg-lamps-samples/

As an editorial nit, the various samples need to have <sourcecode>,
etc. and a file XXX so that they can be extracted easily.

I also suggest you leave the --text output from openssl's x509
processor with the certificate for human consumption.

Finally, https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki.git
     and https://github.com/rgmhtt/draft-moskowitz-eddsa-pki.git
is somewhat related, and perhaps we should consider merging of efforts, or
producing one with the other.

Bob, Henk and I never expected these to be published, but it might be
worth making your samples draft be a generated output.

I modularized the first one so that it could be re-run more easily, but
haven't touched the second one yet.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 4 Nov 2020 16:50:33 +0000

Hi,

> also be happy if someone else wanted to edit it.

I agree this document should be adopted by the WG.

I am not yet sure that the document ever need to become an RFC (as 
opposed to just staying as a draft that gets refreshed periodically), 
but I can probably be convinced.

Best Regards,

Alexey

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Nov 2020 13:04:37 -0500

DKG:

My view is that the document would be very useful if the conclusions from the experiment were at the front of the document, and then the details of the experiment follow.

In the past, the S/MIME WG published RFC 4134, which helped foster interoperability.  Your I-D had a different intent, at least originally.  So, a restructuring now that the header-protection standards are used would be another possibility.

Russ

> On Nov 4, 2020, at 9:08 AM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Hi LAMPS folks--
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 04 Nov 2020 13:00:36 -0500

> I agree this document should be adopted by the WG.

Thanks for the support!

> but I can probably be convinced.

The main reason is that i want it to be referencable (and not expired)
by other drafts that have test vectors.  I note that if we're changing
the certificates in question regularly, that will break any test vector
that relies on it.  So static/permanent seems simple and advantagous,
and (afaict) in the IETF static/permanent means RFC.  Otherwise, i don't
really care whether it's an RFC or not.

If you think that the WG can maintain the document in draft state
perpetually, that'd be fine with me, but i don't understand the
administrative process for ensuring that happens.

               --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 04 Nov 2020 13:36:30 -0500

> Old ones are even valuable because they are expired.

The draft currently uses 2048-bit RSA keys, bound into certificates that
expire in ~2050.

My original intent was to *not* have the certificates expire in the near
future.  I want to encourage the creation of test vectors that are
supposed to be technically valid for a decade or two at least.

(of course no test vectors produced with this material are *really*
valid, because the secret key material is published and known)

If we want deliberately expired certificates, i think we should generate
them such that they are already expired, so that people can produce
deliberately expired test vectors.  I'd be willing to consider adding
such a thing to the draft if the WG feels strongly that it's needed, but
i started the draft with the intent of keeping it simple, focusing on
how valid certs are expected to look in the S/MIME context.

Note: i am a big fan of negative examples in test suites generally, but
a catalog of all the ways that a certificate might *not* be valid in a
given context is a huge undertaking, much larger than the current draft.
It's not just simple certificate expiration.  A catalog of negative
examples -- just for S/MIME purposes -- should include the following
issues in all different certificates (root CA and end entity of course,
but also intermediate certs, which the current draft doesn't touch on):

 - expired certs
 - certs "from the future"
 - insufficient keyUsage or extendedKeyUsage flags
 - weak key material
 - bad digest algorithms in the signature
 - critical unknown ("poison") extensions
 - probably a lot more!

This seems like it would be a different (and much bigger) project than
the current draft, so i'm wary of the bloat.

> charter revision to do so.

Thanks for the statement of support.

> etc. and a file XXX so that they can be extracted easily.

Interesting!  the draft uses a markdown-to-xml workflow (see the
Makefile in https://gitlab.com/dkg/lamps-samples) and i don't know how
to make that workflow generate <sourcecode> or filenames.  If anyone has
pointers to how to make that work, i'd welcome suggestions (merge
requests directly on gitlab would be bonus).

> processor with the certificate for human consumption.

I'm not convinced that we want to embed the output of whatever
particular version of OpenSSL i happen to have on my computer today into
the draft itself.  People can use their preferred X.509 renderer on the
cert as given if they want to review it in more detail.  The goal of the
draft is to describe the salient features in human terms, and provide an
object that any tool can be run against.

[ The certificates were originally generated with certtool from GnuTLS
  (again, see the Makefile), not OpenSSL, not that it matters ]

> producing one with the other.

I'd be happy to include additional certificates using ECDSA and EDDSA in
a future revision of this draft.  However, I don't think that guidance
about operating a PKI, or suggestions about how to use `openssl` from
the command line belong in this draft.

I'd welcome Bob's (or anyone's) help in making sure that the modern
cryptographic algorithms are represented in a catalog of sample
certificates.

Out of curiosity: how is one expected to encrypt an e-mail message to an
ECDSA or EDDSA S/MIME certificate?  Or are those expected to be
signing-only certificates?

> worth making your samples draft be a generated output.

The samples draft is already a generated output -- see the Makefile in
the gitlab repo.

I've also committed the generated material so that the entropy involved
in the key generation (picking large primes) and certificate creation
(datestamps and serial number) doesn't cause unnecessary churn in the
draft, but if there are problems with any of the sample certificates, it
should be pretty straightforward to tweak the generation steps, destroy
the artifacts, and have them be recreated.

Regards,

        --dkg

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 14:03:43 -0500

> but I can probably be convinced.

I guess any references to it from other documents would be informational, so
there would be no downref issue?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 04 Nov 2020 14:34:01 -0500

On Wed 2020-11-04 13:04:37 -0500, Russ Housley wrote:

> My view is that the document would be very useful if the conclusions
> from the experiment were at the front of the document, and then the
> details of the experiment follow.

I'm not sure which experiment you're talking about, Russ.

While I've already used these certificates for things like header
protection rendering tests, they've also been useful for exercising
generic cryptographic functionality in several different MUAs, usability
tests, sources for bug reports, etc.

I want a simple, stable document that contains sample X.509v3
certificates and associated secret key material for use with S/MIME
without associating these artifacts with any particular standardization
effort.

> Your I-D had a different intent, at least originally.

The intent of this I-D was to offer generic certificates for use with
S/MIME -- not about header protection specifically.  I don't think the
draft is (or should be) tied to header protection.

> So, a restructuring now that the header-protection standards are used
> would be another possibility.

I'm hoping that the test vectors for the header protection draft (which
will be MIME objects) will use these sample certificates.  But i'm also
hoping that other S/MIME drafts that include test vectors will feel free
to use these certificates too.  I'm hoping to add some test vectors in
draft-dkg-e2e-mail-guidance, for example, and i'll use them there.

That would make it much easier for people to set up their MUA for
testing arbitrary functionality -- just load the default sample cert
set, and then explore whatever you're exploring.

        --dkg

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Nov 2020 15:06:50 -0500

> I'm not sure which experiment you're talking about, Russ.

When people sent you the screen shots for the way that various mail clients rendered the samples.

> without associating these artifacts with any particular standardization

Understood.  I support this part.  It was important for early S/MIME interoperability, and it will probably be important as AEAD gets rolled out for S/MIME 4.0.

[snip]

> draft-dkg-e2e-mail-guidance, for example, and i'll use them there.

That seems like a good idea.

> set, and then explore whatever you're exploring.

Some user agents make it easier than others, but that is not a reason to stop.

Russ

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Nov 2020 15:18:31 -0500

Daniel Kahn Gillmor <[email-masked]> wrote:
    >> I think that it's very very useful to have test vectors here.  They
    >> need to be renewed regularly as algorithms and key sizes changes.  Old
    >> ones are even valuable because they are expired.

    > The draft currently uses 2048-bit RSA keys, bound into certificates
    > that expire in ~2050.

    > My original intent was to *not* have the certificates expire in the
    > near future.  I want to encourage the creation of test vectors that are

I agree that some stability is useful.
Some certificates that expire past "xx50" would be good, since there was that
Y2K hack, which I hope is now gone :-)

    > If we want deliberately expired certificates, i think we should
    > generate them such that they are already expired, so that people can
    > produce deliberately expired test vectors.

Yes, I agree.

    > a catalog of all the ways that a certificate might *not* be valid in a

+1

    > to make that workflow generate <sourcecode> or filenames.  If anyone
    > has pointers to how to make that work, i'd welcome suggestions (merge

I originally cheated, and I had created a perl script "insert-figures"
before the era of kramdown, see:
  https://github.com/anima-wg/anima-bootstrap/blob/master/insert-figures

is includes some support for tracking down the right YANG module.
kramdown itself has an include:
   {::include ../ghc/packets-new/p4.out}

you have to put in the <sourcecode> stuff.  I've mentioned this need to
Carsten at some time.

    > particular version of OpenSSL i happen to have on my computer today

I don't care what you pretty printer you use, but I think that the human
readable part has some value.

    > into the draft itself.  People can use their preferred X.509 renderer
    > on the cert as given if they want to review it in more detail.  The
    > goal of the draft is to describe the salient features in human terms,
    > and provide an object that any tool can be run against.

In ten years, the renderer might print something different, and it might
actually be valuable to know that something changed.

    > (again, see the Makefile), not OpenSSL, not that it matters ]

Good. I should use certtool more often myself.

    > Out of curiosity: how is one expected to encrypt an e-mail message to
    > an ECDSA or EDDSA S/MIME certificate?  Or are those expected to be

Blush. Good point!
I have no idea how ECDSA works with S/MIME encryption.

    > draft, but if there are problems with any of the sample certificates,
    > it should be pretty straightforward to tweak the generation steps,
    > destroy the artifacts, and have them be recreated.

I think you are saying that the key generation is intentionally deterministic
from a known seed?

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Nov 2020 09:52:45 -0500

> Y2K hack, which I hope is now gone :-)

you're talking about GeneralizedTime vs. UTCTime, i think?  these
certificates all are after 2050, so they do tickle that particular
boundary.  From the "alice" cert (in the ugly dumpasn1 rendering):

[…]
 97  32:     SEQUENCE {
 99  13:       UTCTime 20/11/2019 06:54:18 GMT
114  15:       GeneralizedTime 27/09/2052 06:54:18 GMT
       :       }
[…]

> you have to put in the <sourcecode> stuff.  I've mentioned this need to

If there's an open bug report, i'd be happy to see it so i can weigh in!

> readable part has some value.
[…]
> actually be valuable to know that something changed.

The most valuable human-readable part is the stuff in English that
introduces each certificate ☺.  And it's definitely valuable to know
that a particular tool's rendering has changed, but i don't think that
an RFC is the right place to record a changelog of renderer output for
any particular tool.

> I have no idea how ECDSA works with S/MIME encryption.

Does anyone have a suggestion here?  Is anyone on this list using either
ECDSA or EDDSA with e-mail?

> I think you are saying that the key generation is intentionally deterministic

hah, i wish!  my code (and my knowledge of the toolchains i'm using) is
not that clever.  I just ran the tools in the standard way, and took a
snapshot of their output.  Generating from a seed is a good idea for
future work.

…does some reading…

Looks like certtool has --provable and --seed options that can be used
for this, at least for RSA and DSA key generation using FIPS PUB186-4
algorithms (i.e., Shawe-Taylor).  I supposed for ECDSA or EDDSA key
generation, we could just deterministically select (hard-code) the secret
key based on a (correctly-sized) digest of a simple string.

Thanks for the useful feedback and suggestions!

       --dkg

---

From: Deb Cooley <[email-masked]>
Date: Sun, 15 Nov 2020 06:33:37 -0500

Apologies for top posting....

-----snip---------------------------------------------

I don't have one (and I may never if I retire before US DOD moves off of
RSA2048) but an ECDSA cert would be used for digital signature in S/MIME.
Encryption would use a separate key/cert - not ECDSA, most likely ECDH with
a semi-static scheme (sender is ephemeral, recipient is static).

Deb Cooley

On Thu, Nov 5, 2020 at 9:57 AM Daniel Kahn Gillmor <[email-masked]>
wrote:

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

---

From: Henning Krause <[email-masked]>
Date: Sun, 15 Nov 2020 17:50:34 +0000

> a semi-static scheme (sender is ephemeral, recipient is static).

I've created an ECDSA certificate using OpenSSL and used that successfully to encrypt an SMIME message. OpenSSL simply uses the ECDSA key for ECDH. I've also created a prototype in C# to the same thing and was able to decrypt the message created by OpenSSL.

So creating sample certificates is relatively straight forward:

Generate key:
ecparam -out ecdsa.key -name secp256r1 -genkey

The key can then be used to create a certificate signing request and the actual cert.

The encryption indeed uses an ephemeral key for the sender and the static public key from the recipients certificate.

@Deb Cooley, why do you say you would a different certificate? 

Kind regards,
Henning

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 15 Nov 2020 19:18:29 +0000

> On 4 Nov 2020, at 19:03, Michael Richardson <[email-masked]> wrote:
> 

Yes.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Nov 2020 00:14:22 -0800

> I've created an ECDSA certificate using OpenSSL and used that successfully to encrypt an SMIME message. OpenSSL simply uses the ECDSA key for ECDH. I've also created a prototype in C# to the same t…

I think OpenSSL is not supposed to do that, and furthermore I thought there
was a bug report on github about OpenSSL doing so, but I couldn't find it
quickly if it exists.

-Ben

---

From: Henning Krause <[email-masked]>
Date: Mon, 16 Nov 2020 08:29:19 +0000

Hi,

> was a bug report on github about OpenSSL doing so, but I couldn't find it

Is there any written statement about this in an RFC? Because applications are going to implement this stuff and CA will enroll SMIME certificates using ECDSA keys, they need to know that they have to enroll two certificates per email address (or add another key in the first cert - I think I saw a draft for that on this list).

I fear that unless its forbidden by the standard, people will implement it this way.

Kind regards,
Henning

---

From: Jonathan Hammell <[email-masked]>
Date: Mon, 16 Nov 2020 04:11:56 -0500

> @Deb Cooley, why do you say you would a different certificate?

Section 5.2 of NIST SP 800-57-1 rev 5 forbids using a key for both
signing and encryption and gives several reasons.

RFC 5480 does allow "any combination" of the key usage bits
digitalSignature, nonRepudiation and keyAgreement. However, note that
RFC 8813 disallows keyEncipherment or dataEncipherment in general ECC
certificates (i.e. with algorithm identifier id-ecPublicKey).

Jonathan

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Nov 2020 01:16:53 -0500

On Sun 2020-11-15 17:50:34 +0000, Henning Krause wrote:
> The encryption indeed uses an ephemeral key for the sender and the
> static public key from the recipients certificate.

Does this mean that if i can convince the certificate-holder to sign a
document of my choosing, i can convert that signature to enable
decryption of a ciphertext that was encrypted to the sender?

Reusing the same cryptographic material for different purposes seems
like it raises new cross-protocol questions that are potentially ugly --
isn't it safer to just avoid those risks with single-purpose
mathematical objects?

             --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Nov 2020 01:19:38 -0500

> a semi-static scheme (sender is ephemeral, recipient is static).

Thanks for this suggestion -- how would this separate ECDH cert be
distributed?  the signing ECDSA certificate is bundled with the
signature in PKCS#7.  do we just stick the ECDH cert in the same spot?
do we need to mark it for purpose?  if so, how?  is it
directly/explicitly tied to the signing cert?

Sure would be nice to have some samples to make this clear :)

     --dkg

---

From: Jonathan Hammell <[email-masked]>
Date: Mon, 16 Nov 2020 06:36:08 -0500

> Sure would be nice to have some samples to make this clear :)

As Deb said, encryption with ECDH is typically ephemeral-static.
Therefore, the ECDH certificate belongs to the recipient and the
sender just creates and sends an ephemeral public key (i.e. no
certificate).  In the KeyAgreeRecipientInfo, the sender would put
his/her ephemeral key in originatorKey.  The recipient's ECDH
certificate is referred to in KeyAgreeRecipientIdentifier, but the
actual certificate is not sent in the structure since the recipient
only needs to use his/her private key for decryption (and likely has
the certificate, anyway).

In practice, when a sender doesn't have the recipient's ECDH
certificate, typically he/she has to request a S/MIME signed message
from the recipient, which does seem to include all certificates
(signing and encryption); but this is the same as for RSA.

Jonathan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 Nov 2020 09:24:32 -0500

Encryption/Key agreement certificate distribution problem is not unique to
EC.  We have the same issue in RSA.  S/MIME clients can be configured to
send signer's encryption/key agreement certificate.  Absent a directory that
is how certificates are distributed by the users.

Key usage extension and SPKI algorithm dictate if the SPKI can be used as a
static ECDH.  There are two ways to do that. 

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Monday, November 16, 2020 1:20 AM
To: Deb Cooley <[email-masked]>; LAMPS WG <[email-masked]>
Cc: Cooley, Dorothy E <[email-masked]>; Michael Richardson
<[email-masked]>
Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ?

On Sun 2020-11-15 06:33:37 -0500, Deb Cooley wrote:

> Encryption would use a separate key/cert - not ECDSA, most likely ECDH 
> with a semi-static scheme (sender is ephemeral, recipient is static).

Thanks for this suggestion -- how would this separate ECDH cert be
distributed?  the signing ECDSA certificate is bundled with the signature in
PKCS#7.  do we just stick the ECDH cert in the same spot?
do we need to mark it for purpose?  if so, how?  is it directly/explicitly
tied to the signing cert?

     --dkg

---

From: Deb Cooley <[email-masked]>
Date: Mon, 16 Nov 2020 09:31:15 -0500

Exactly.  To demonstrate using RSA, I could sign a message off of my 'for
real' account.  You would get both my signature cert and my encryption cert
(both RSA today).  This allows you to encrypt to me today, and it would
work the same way w/ ECC algorithms.  Let me know if you want me to do
this, I'd be happy to.

Using a single key pair for multiple uses (signature and key
transport/agreement) is seldom a good thing.  The NIST SP that Jonathan
lists is a good source.

Deb

---

From: Henning Krause <[email-masked]>
Date: Mon, 16 Nov 2020 17:23:54 +0000

Hi Jonathan,

indeed NIST says we must not use the same keys, but the RFCs are not that clear:

RFC 8813 disallows keyEncipherment or dataEncipherment in general ECC certificates certificates (i.e. with algorithm identifier id-ecPublicKey, but also with id-ecDH or id-ecMQV).

But the encryption with ECC uses ECDH, and per RFC 5280, ECDH should fall under the keyAgreement usage, or am I wrong? 

I can't find anything in those RFC that would forbid me to use the same certificate for signature and encryption. 

Did I overlook something?

Kind regards,
Henning

> From: Jonathan Hammell [mailto:[email-masked]]
> Sent: Montag, 16. November 2020 10:12
> To: Henning Krause <[email-masked]>
> Cc: Deb Cooley <[email-masked]>; LAMPS WG <[email-masked]>;
> Cooley, Dorothy E <[email-masked]>; Michael Richardson
> <[email-masked]>
> > > Does anyone have a suggestion here?  Is anyone on this list using
> > > either ECDSA or EDDSA with e-mail?
> > >
> > > Encryption would use a separate key/cert - not ECDSA, most likely
> > > ECDH with a semi-static scheme (sender is ephemeral, recipient is static).
> > >
> >
> > I've created an ECDSA certificate using OpenSSL and used that successfully
> to encrypt an SMIME message. OpenSSL simply uses the ECDSA key for
> ECDH. I've also created a prototype in C# to the same thing and was able to
> decrypt the message created by OpenSSL.
> >
> > The encryption indeed uses an ephemeral key for the sender and the static
> public key from the recipients certificate.
> >
> Section 5.2 of NIST SP 800-57-1 rev 5 forbids using a key for both signing and
> encryption and gives several reasons.
> 
> RFC 5480 does allow "any combination" of the key usage bits digitalSignature,
> nonRepudiation and keyAgreement. However, note that RFC 8813 disallows
> keyEncipherment or dataEncipherment in general ECC certificates (i.e. with
> algorithm identifier id-ecPublicKey).
> 
> Jonathan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 Nov 2020 12:44:09 -0500

Below is the logic S/MIME Encrypting client should use to determine if a EC
public key in a X.509 certificate can be used to create a recipient token.

All of the following conditions should be met:

1.  The algorithm OID in SPKI is EC Public Key or EC DH; and

2. If key usage is present, it sets key agreement bit; and

3. If EKU is present, it contain e-mail protection OID.

On 2, an argument can be made that if algorithm OID is EC Public Key and key
usage is absent, the key should not be used.  Hopefully producers (i.e.,
CAs) always put key usage in general or when SPKI is EC public key.

-----Original Message-----
From: Spasm [mailto:[email-masked]] On Behalf Of Henning Krause
Sent: Monday, November 16, 2020 12:24 PM
To: Jonathan Hammell <[email-masked]>
Cc: LAMPS WG <[email-masked]>; Cooley, Dorothy E <[email-masked]>; Deb
Cooley <[email-masked]>; Michael Richardson <[email-masked]>
Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ?

Hi Jonathan,

indeed NIST says we must not use the same keys, but the RFCs are not that
clear:

RFC 8813 disallows keyEncipherment or dataEncipherment in general ECC
certificates certificates (i.e. with algorithm identifier id-ecPublicKey,
but also with id-ecDH or id-ecMQV).

But the encryption with ECC uses ECDH, and per RFC 5280, ECDH should fall
under the keyAgreement usage, or am I wrong? 

I can't find anything in those RFC that would forbid me to use the same
certificate for signature and encryption. 

Kind regards,
Henning

> ECDH. I've also created a prototype in C# to the same thing and was 
> able to decrypt the message created by OpenSSL.
> >
> > The key can then be used to create a certificate signing request and 
> > the
> actual cert.
> >
> > static

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Nov 2020 15:19:23 -0500

> CAs) always put key usage in general or when SPKI is EC public key.

Thanks for this!  This seems like a useful bit of guidance to include in
draft-dkg-lamps-e2e-mail-guidance.  I've added some approximation of it
in git in the "Peer Certificate Selection" section, over at:
https://gitlab.com/dkg/e2e-mail-guidance.git -- i've included the text below.

Could you take a look and suggest edits if something could be improved?

--------
#### Peer Certificate Selection {#peer-cert-selection}

When composing an encrypted message, the MUA needs to select a certificate for each recipient that is capable of encryption.

To select such a certificate for a given destination e-mail address, the MUA should look through all of its known certificates and verify that *all* of the conditions below are met:

- The certificate must be valid, not expired or revoked.
- It must have a subjectAltName of type rFC822Name whose contents exactly match the destination address.
- The algorithm OID in the certificate's SPKI is known to the MUA and capable of encryption.
  Examples include (TODO: need OIDs)
  - RSA
  - EC Public Key
  - EC DH
- If keyUsage is present, the key agreement bit must be set
- If extendedKeyUsage is present, the e-mail protection OID must be present.

TODO: If OID is EC Public Key and keyUsage is absent, what should happen?

TODO: what if multiple certificates meet all of these criteria for a given recipient?
--------

Regards,

        --dkg

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 16 Nov 2020 15:50:37 -0500

DKG,

Thanks.

I would revise item 3 to permit anyExtendedKeyUsage and thus item 3 would
read as follows:

3. If EKU is present, it contains at least one of the following OIDs: e-mail
protection, anyExtendedKeyUsage.

-----Original Message-----
From: Daniel Kahn Gillmor [mailto:[email-masked]] 
Sent: Monday, November 16, 2020 3:19 PM
To: Santosh Chokhani <[email-masked]>; 'LAMPS WG'
<[email-masked]>

On Mon 2020-11-16 12:44:09 -0500, Santosh Chokhani wrote:
> Below is the logic S/MIME Encrypting client should use to determine if 
> a EC public key in a X.509 certificate can be used to create a recipient
token.
> On 2, an argument can be made that if algorithm OID is EC Public Key 
> and key usage is absent, the key should not be used.  Hopefully 
> producers (i.e.,

Thanks for this!  This seems like a useful bit of guidance to include in
draft-dkg-lamps-e2e-mail-guidance.  I've added some approximation of it in
git in the "Peer Certificate Selection" section, over at:
https://gitlab.com/dkg/e2e-mail-guidance.git -- i've included the text
below.

--------

When composing an encrypted message, the MUA needs to select a certificate
for each recipient that is capable of encryption.

To select such a certificate for a given destination e-mail address, the MUA
should look through all of its known certificates and verify that *all* of
the conditions below are met:

- The certificate must be valid, not expired or revoked.
- It must have a subjectAltName of type rFC822Name whose contents exactly
match the destination address.
- The algorithm OID in the certificate's SPKI is known to the MUA and
capable of encryption.
  Examples include (TODO: need OIDs)
  - RSA
  - EC Public Key
  - EC DH
- If keyUsage is present, the key agreement bit must be set
- If extendedKeyUsage is present, the e-mail protection OID must be present.

TODO: what if multiple certificates meet all of these criteria for a given
recipient?
--------

Regards,

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 16 Nov 2020 16:07:06 -0500

> protection, anyExtendedKeyUsage.

Thanks, revised in Git.  I've added you and Deb to the Acknowledgements
section.

        --dkg

---

From: Jonathan Hammell <[email-masked]>
Date: Tue, 17 Nov 2020 02:08:19 -0500

DKG,

Small correction to your Peer Certificate Selection text below.

> - If extendedKeyUsage is present, the e-mail protection OID must be present.

The criteria "If keyUsage is present, the key agreement bit must be
set" only applies to EC Public Key and ECDH.  In the case of an RSA
certificate, the keyUsage should have the key encipherment bit set
instead (since it is used to encrypt the content encryption key).

Jonathan

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Nov 2020 02:47:26 -0500

> instead (since it is used to encrypt the content encryption key).

Thanks for the suggestion, Jonathan.  I've updated it to the text below.

Please keep the feedback coming!

       --dkg

-----------

- The certificate must be valid, not expired or revoked.
- It must have a subjectAltName of type rFC822Name whose contents exactly match the destination address.
- The algorithm OID in the certificate's SPKI is known to the MUA and capable of encryption.
  Examples include (TODO: need OIDs)
  - RSA, with keyUsage present and the "key encipherment" bit set
  - EC Public Key, with keyUsage present and the "key agreement" bit set
  - EC DH, with keyUsage present and the "key agreement" bit set

- If extendedKeyUsage is present, it contains at least one of the following OIDs: e-mail protection, anyExtendedKeyUsage.

---

From: Deb Cooley <[email-masked]>
Date: Tue, 17 Nov 2020 04:08:14 -0500

I would not include the anyExtendedKeyUsage EKU....  The pro/con of the
anyEKU is that you can use the key/cert for anything.  If that is what you
desire - it is a 'pro'.  If you wish to constrain the use of a key/cert, it
is a 'con'.

My current employer does not allow the anyEKU to be populated.  We consider
it to be a 'con'.  YMMV

Deb Cooley

On Tue, Nov 17, 2020 at 2:08 AM Jonathan Hammell <[email-masked]>
wrote:

> > To select such a certificate for a given destination e-mail address, the
> MUA should look through all of its known certificates and verify that *all*
> of the conditions below are met:
> >

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Nov 2020 06:46:03 -0500

>        interoperability among S/MIME-enabled e-mail implementations.

I'm withdrawing this proposed charter amendment in favor of the
amendment proposed in Message-ID: [email-masked],
which covers both draft-dkg-lamps-samples and
draft-dkg-lamps-e2e-mail-guidance.

Regards,

        --dkg

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 Nov 2020 10:08:41 -0500

Deb,

This conversation is about consumer of the certificate and not producer.  What I wrote in the revised one is the semantics per definition of the anyExtendedKeyUsage OID and that is how COTS work.

The consumer semantics cannot be dictated by what someone may wish.

From: Deb Cooley [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2020 4:08 AM
To: LAMPS WG <[email-masked]>
Cc: Daniel Kahn Gillmor <[email-masked]>; Santosh Chokhani <[email-masked]>; Jonathan Hammell <[email-masked]>
Subject: Re: [lamps] WG adoption of draft-dkg-lamps-samples ?

I would not include the anyExtendedKeyUsage EKU....  The pro/con of the anyEKU is that you can use the key/cert for anything.  If that is what you desire - it is a 'pro'.  If you wish to constrain the use of a key/cert, it is a 'con'.  

My current employer does not allow the anyEKU to be populated.  We consider it to be a 'con'.  YMMV

Deb Cooley

On Tue, Nov 17, 2020 at 2:08 AM Jonathan Hammell <[email-masked] <mailto:[email-masked]> > wrote:

DKG,

Jonathan

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 17 Nov 2020 13:29:46 -0500

On Tue 2020-11-17 10:08:41 -0500, Santosh Chokhani wrote:

> This conversation is about consumer of the certificate and not
> producer.  What I wrote in the revised one is the semantics per
> definition of the anyExtendedKeyUsage OID and that is how COTS work.
>

no, but they *can* influence the guidance we give to certificate
producers, and at some point certain semantics do need to be deprecated.
we can't just claim that they'll work at all times.

One of the best ways to discourage producers from taking certain actions
is to ensure that those actions won't be accepted by some noticable
portion of consumers, so pushing for changing consumer semantics isn't
(or shouldn't be) out of bounds as we try to move the network to better
cryptographic practices.

That said, for the purposes of draft-dkg-lamps-e2e-mail-guidance today
in 2020, i propose to document the current semantics for the consumer
(that is, accepting anyExtendedKeyUsage as documented), but also to
encourage the MUA implementer to warn the user (and encourage them to
complain to their CA?)  if their *own* certificate has such a flag set
(or has multiple usage flags set that indicate that the same
cryptographic material would be used for more than one purpose).

How does that sound?

    --dkg

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 17 Nov 2020 15:02:43 -0500

DKG,

For producers, if you like, I can define recommended and not recommended
syntax.  For example I would recommend the use of EC Public key and NOT
recommend ECDH in order to enhance interoperability.  For key usage I would
recommend inclusion of the extension with criticality set and with key
agreement bit set and DS bit may be set for dual use, but not recommended.
Other bits must not be set. For EKU, I would recommend criticality not set
and inclusion of e-mail protection OID and recommend NOT including
anyExtendedKeyUsage OID.  Other EKU OIDs may be included consistent with Key
Usage and intended usage of the certificate.

-----Original Message-----
From: Daniel Kahn Gillmor [mailto:[email-masked]] 
Sent: Tuesday, November 17, 2020 1:30 PM
To: Santosh Chokhani <[email-masked]>; 'Deb Cooley'
<[email-masked]>; 'LAMPS WG' <[email-masked]>
Cc: 'Jonathan Hammell' <[email-masked]>
Subject: RE: [lamps] WG adoption of draft-dkg-lamps-samples ?

> The consumer semantics cannot be dictated by what someone may wish.

no, but they *can* influence the guidance we give to certificate producers,
and at some point certain semantics do need to be deprecated.
we can't just claim that they'll work at all times.

One of the best ways to discourage producers from taking certain actions is
to ensure that those actions won't be accepted by some noticable portion of
consumers, so pushing for changing consumer semantics isn't (or shouldn't
be) out of bounds as we try to move the network to better cryptographic
practices.

That said, for the purposes of draft-dkg-lamps-e2e-mail-guidance today in
2020, i propose to document the current semantics for the consumer (that is,
accepting anyExtendedKeyUsage as documented), but also to encourage the MUA
implementer to warn the user (and encourage them to complain to their CA?)
if their *own* certificate has such a flag set (or has multiple usage flags
set that indicate that the same cryptographic material would be used for
more than one purpose).

How does that sound?

    --dkg

---

From: Jonathan Hammell <[email-masked]>
Date: Wed, 18 Nov 2020 00:18:43 -0500

Dear Henning,

> Did I overlook something?

No, I am not aware of any RFC that prohibits using an ECC certificate
for both signing and encryption.  As I pointed out earlier, RFC 5480
says that any combination of the key usage bits MAY be present,
subject to the restrictions previously discussed.  Those restrictions
do not forbid using digitalSignature and keyAgreement together.
However, NIST SP 800-57-1 is an informative reference in RFC 5480, so
I still recommend following that guidance despite it not being
explicitly required or recommended in the RFCs to do so.  The PKIX
RFCs are not BCPs.

The CA/Browser Forum has recently established an S/MIME Certificate WG
to create baseline requirements for this use case.  I am not involved,
but I believe that one of the LAMPS chairs, Tim Hollebeek, may
participate in that WG.  I will be surprised if they will not require
separate certificates for signing and encryption, but Tim may be able
to comment.

Best regards,
Jonathan