Subject: Re: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)

From: "Salz, Rich" <[email-masked]>
Date: Sun, 1 Aug 2021 14:56:28 +0000

I agree with Ryan, the contortions OpenSSL has to go through to get those old broken algorithms supported… shudder.

Perhaps an update to PKCS12 that specifies DER and modern crypto makes sense?

---

From: Russ Housley <[email-masked]>
Date: Sun, 1 Aug 2021 11:12:25 -0400

> On Aug 1, 2021, at 10:56 AM, Salz, Rich <rsalz=[email-masked]> wrote:
> 

RFC 7292 includes an IESG Note that says:

   The IESG thanks RSA Laboratories for transferring change control to
   the IETF.  Enhancements to this specification that preserve backward
   compatibility are expected in an upcoming IETF Standards Track
   document.

So, it appears that only the IETF can address this topic.  it is not clear to me whether this would go in LAMPS or a separate group.

Russ

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Sun, 1 Aug 2021 18:03:46 +0000

+1 on mandating DER for PKCS12.

Modern crypto won't hurt either, but DER is crucial. 

Regards,
Uri

> On Aug 1, 2021, at 10:57, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Aug 2021 16:47:16 -0400

What should we replace pkcs12 with?

It seems to be the only way to get client certificates into Firefox, Chrome and
Java/Tomcat's keystore.
(I hate it)

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

---

From: Ryan Sleevi <[email-masked]>
Date: Sun, 1 Aug 2021 19:54:01 -0400

> It seems to be the only way to get client certificates into Firefox,

What? No, that's not true.

PKCS#7 is widely supported and avoids the "many forms" of PKCS#12's
silliness. Or just import directly (e.g. PEM and PKCS#8).

---

From: Deb Cooley <[email-masked]>
Date: Mon, 2 Aug 2021 12:01:10 -0400

Indeed - use PKCS#7.  Why are we importing keys and certs in this day and
age???

As for definite length over indefinite length encode - DER for the win.  I
agree w/ Ryan.

Updates to PKCS#12?  yuck.

As for RC2.... I'm sure 3keyTDES is better.  LOL  (note:  that was sarcasm)

Deb Cooley
[email-masked]

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 02 Aug 2021 21:54:49 -0400

> silliness. Or just import directly (e.g. PEM and PKCS#8).

What i'm getting from this thread is that including any attempt at the
PKCS#12 form of the objects in this draft might be a mistake.

I'm pretty much certain now that even if a PKCS#12 object is included in
this draft, it should come with warnings that this format is NOT
RECOMMENDED.

If we drop the PKCS#12 objects entirely, the draft will be shorter, but
will still retain all the same information.  But I confess i don't know
how to import a corresponding secret key into some clients.

For example, Thunderbird appears to *only* support pkcs#12 import for
secret keys:

   https://bugzilla.mozilla.org/show_bug.cgi?id=1723617

Thunderbird can clearly handle PKCS#7 itself (it can render the contents
of encrypted and signed messages, and can even extract and import
certificates included in a message's certificate list), but i can't see
how to use PKCS#7 to get a secret key into its data store.

How would you use PKCS#7 to transport secret keys between two clients?

To the WG more broadly:

What approach do you prefer we take on this draft?  I see three options
(i welcome hearing suggestions for others):

 a) Drop PKCS#12 from this draft entirely

 b) Keep the PKCS#12 objects as they are but explicitly warn against
    their use due to interoperability concerns.

 c) Adjust the creation of the PKCS#12 objects so that they have the
    double OCTET STRING wrapper (one for RFC 5652 and one for RFC 7972),
    without moving them into the indefinite encoding.  (maybe also warn
    against PKCS#12 use here?)

Do folks have a preference on what should happen with the draft?

   --dkg

---

From: Tomas Gustavsson <[email-masked]>
Date: Tue, 3 Aug 2021 06:19:26 +0000

> Indeed - use PKCS#7.  Why are we importing keys and certs in this day and age???

Is there another way to use client keys and certificates in browsers (all browsers) and email clients, apart from using hardware tokens or MS autoenrollment, or another 3rd party softare doing the import for you?
Is there a sample of a CMS (PKCS#7) file with certs and private keys that can be imported in browsers? I'd love to try that.
________________________________
From: Spasm <[email-masked]> on behalf of Deb Cooley <[email-masked]>
Sent: Monday, August 2, 2021 6:01 PM
To: Ryan Sleevi <[email-masked]>
Cc: LAMPS WG <[email-masked]>; Michael Richardson <[email-masked]>; Daniel Kahn Gillmor <[email-masked]>
Subject: Re: [lamps] draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [email-masked] with any questions.

Indeed - use PKCS#7.  Why are we importing keys and certs in this day and age???

As for definite length over indefinite length encode - DER for the win.  I agree w/ Ryan.

Deb Cooley
[email-masked]<mailto:[email-masked]>

On Sun, Aug 1, 2021 at 7:54 PM Ryan Sleevi <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Aug 1, 2021 at 4:47 PM Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

PKCS#7 is widely supported and avoids the "many forms" of PKCS#12's silliness. Or just import directly (e.g. PEM and PKCS#8).
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C9e036c9936074230baa308d955cedf7a%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637635169285960046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Fpge1jL8RtUWgPh8MQYs1%2Fl%2BY8X1LNlBCCqz0k18GZY%3D&reserved=0>

---

From: "David Woodhouse" <[email-masked]>
Date: Tue, 3 Aug 2021 11:15:31 -0000

>> Indeed - use PKCS#7.  Why are we importing keys and certs in this day

Hm, should I add PKCS#7 to the list in
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html (which
already needs
updating for TPMv2 "----- BEGIN TSS2 KEY BLOB-----" wrapped keys now that
those are
standardised between different implementations)?

Slightly closer to the original question, IIRC, I have a bunch of torture
tests for
PKCS#12 and other formats in the OpenConnect test suite at
http://git.infradead.org/users/dwmw2/openconnect.git/tree/HEAD:/tests/certs
(generated by rules in tests/Makefile.am).

I feel quite strongly that any userspace application should JustWork™ when
the user
presents it with a cert+key in any fairly reasonable form (any half-sane
file type
or URI). And users don't have much control over *what* form their keys are
issued
in.

(Apologies if this ends up being a resend)
-- 
dwmw2

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 3 Aug 2021 14:12:34 +0200

Here is the link to the repo of valid PKCS#12 files used in Red Hat for
regular testing.
https://github.com/redhat-qe-security/keyfile-corpus

They include both ancient and up-to-date algorithms, so I'd suggest to take
some examples here

On Sun, Aug 1, 2021 at 4:56 PM Salz, Rich <rsalz=[email-masked]>
wrote:

> I agree with Ryan, the contortions OpenSSL has to go through to get those
> old broken algorithms supported… shudder.
>
>
>

-- 
SY, Dmitry Belyavsky

---

From: Michael Richardson <[email-masked]>
Date: Tue, 03 Aug 2021 09:07:06 -0400

> https://bugzilla.mozilla.org/show_bug.cgi?id=1723617

As I mentioned.
I suspect that one some OSes, it may support and OS-specific keystore.

The JAVA Keytool only supports importing in pkcs12 format as well.
There are a multitude of SSL interfaces for Tomcat, and some support PKCS7/PKCS8,
etc. private key files, but not all.

    > their use due to interoperability concerns.

Probably this.

    > against PKCS#12 use here?)

Does this possible changes in code in existing systems?
I don't think that they will change.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 03 Aug 2021 18:58:50 -0400

On Tue 2021-08-03 17:55:56 -0400, Daniel Kahn Gillmor wrote:
> I've been using GnuTLS to generate the objects in the draft thus far,
> and they've been open to code changes that i've suggested in the past
> based on input from this WG.

I should note that i'm not stuck on using GnuTLS to generate the pkcs12
objects for this draft, though i would prefer to make them deterministic
(that is, byte-for-byte reproducible from the tooling), and GnuTLS has
been friendlier to reproducibility than other certificate/key management
tools i've encountered.

If someone wants to suggest a different way to generate the PKCS#12
object with two private keys, two corresponding certificates, and an
intermediate CA cert, i'm all ears.  My current attempts with NSS and
OpenSSL haven't born fruit.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 03 Aug 2021 17:55:56 -0400

I opened this request for them yesterday:

   https://gitlab.com/gnutls/gnutls/-/issues/1259

I don't understand the current ASN.1 codebase in GnuTLS to fix it myself
yet, though.

If anyone wants to poke around in it, i suspect it's in either
lib/pkix.asn (which then requires re-build of lib/pkix_asn1_tab.c) or in
lib/x509/pkcs12*.c.

Regards,

   --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 4 Aug 2021 12:12:08 -0400

> been friendlier to reproducibility than other certificate/key management

Hey Daniel,

Sorry for letting this thread slip by. First, an apology for some confusion
due to my earlier reply, but that I see others have picked up on and
clarified (namely, PKCS#8 for private keys, PKCS#7/PEM/DER for certs)

As it relates to the double OCTET STRING, I didn't reply because I thought
Russ' more detailed reply had covered that I'd overlooked something,
namely, the indefinite length encoding issue, caused by NSS preferring BER.
When you're indefinite length-encoding an OCTET string, you end up having
an "outer" indefinite length octet string, and then bound chunks of data in
"inner" OCTET strings, followed by the EOC indicator. So the double
layering I mentioned is an artifact of the BER encoding Russ pointed out,
that I had overlooked.

Dmitry's reply provides a lot of wonderful insight into more of these
PKCS#12 quirks from different libraries, if you haven't had a chance to
review yet. It also helps highlight the "PKCS#12 is wildly different for
different folks". Have you had a chance to run those files through the
different implementations, to see if you can determine an interoperable
encoding for your target?

To some degree, this highlights the value of having some references for
interoperability. At the same time, it suggests, unfortunately, the need to
spend a lot of time with the decoders of these various tools and libraries,
to assess the interoperability problem and determine whether it's one of
malformed input or misbehaving implementation. Unfortunately, as I
mentioned, PKCS#12 is enough of a hell format that I've managed to
professionally stay away from it as much as possible, so I'm stumbling just
as you are here.

NSS using BER should definitely not be the reference example, even if BER
is valid (in PKCS#12 and CMS), simply because we know better now :) As it
relates to using tooling for determinism, I think the historic approach has
been to work directly from the specs building up the binary sequences by
hand, according to what's valid in the spec, rather than using an existing
OSS library and assuming it's correct, especially for a spec as
historically complex and unloved as PKCS#12.

When I compare the examples mentioned by Dmitry, it does seem that both NSS
and OpenSSL expect the PKCS#7 data (1.2.840.113549.1.7.1) to be an OCTET
STRING with the encoded SEQUENCE, rather than the SEQUENCE itself. As Russ
and I both noticed, it would appear bob.p12 is going directly to a
SEQUENCE, rather than OCTET STRING -> SEQUENCE. Dmitry's examples of what
GnuTLS generates also suggests GnuTLS outputs PKCS#7 data as OCTET STRING,
so I'm a bit curious to understand how you generated the bob.p12 in the
first place? This might help drill down further into the interoperability
issue.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Aug 2021 17:42:57 -0400

> based on input from this WG.

okay, but my point is that it's not the flexible systems that are the
problem, it's the inflexible systems that are keeping us from changing.

====

Now, if rather than fix PKCS12, the IETF were to mark it HISTORICAL with
clear advice on what to use.  Remembering that we have PKCS1 and PKCS8
(RFC5208).
RFC5915/RFC5958.
This contributes to confusion and bits of lack of interoperation.

(Why do we need interoperation for private keys?  Often we don't need that
much, until someone is debugging something, or provisioning keys into an
embedded system via JTAG...)

I would be happy if pkcs12 just died.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 4 Aug 2021 22:28:17 +0000

IMHO:

- PKCS#12 cannot "just die" because there's a ton of software that cannot import private keys, unless they're in .p12 or such.
- I concur that interoperation for private keys is nonsense.

As a side remark - generic use of indefinite-length encoding should be classified as a clinical disorder, and treated accordingly. I'd be happy to call for a DSM update.  ;-)

--
Regards,
Uri
 
There are two ways to design a system. One is to make is so simple there are obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
                                                                                                                                     -  C. A. R. Hoare

On 8/4/21, 17:44, "Spasm on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    ====

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 04 Aug 2021 20:48:42 -0400

Thanks for the ideas and suggestions, everyone.

I hear the consensus of the group that any sample object
included for reference should be in DER form, with no indefinite
lengths.  I will definitely respect that.

On Wed 2021-08-04 12:12:08 -0400, Ryan Sleevi wrote:
> STRING with the encoded SEQUENCE, rather than the SEQUENCE itself.

I might be having a hard time understanding what's in Dmitry's repo.
I can't tell whether it's supposed to represent PKCS#12 objects that are
produced by these tools or consumed by these tools, though README.md
seems to imply that it's kind of both.  I don't see any script that
shows how they were generated.

This repo also doesn't contain any PKCS#12 objects that include multiple
private keys (with matching certificates), which is what would be
appropriate for this draft, as each end entity (Alice, Bob, Carlos,
Dana) needs separate private keys for signing and decryption.

I'll set aside the multiple-key case for now, to focus for the moment on
a single-private-key use case so that we can try to evaluate encodings.

> As Russ and I both noticed, it would appear bob.p12 is going directly
> to a SEQUENCE, rather than OCTET STRING -> SEQUENCE.

The tooling i've been playing with confirms this read.

> Dmitry's examples of what GnuTLS generates also suggests GnuTLS
> outputs PKCS#7 data as OCTET STRING, so I'm a bit curious to
> understand how you generated the bob.p12 in the first place? This
> might help drill down further into the interoperability issue.

   OpenSSL:

      openssl pkcs12 -export -name bob -passout pass:bob \
        -inkey bob.sign.key -in bob.sign.crt \
        -certfile ca.rsa.cross.crt -out bob.openssl.p12

   GnuTLS:

      certtool --to-p12 --p12-name bob --password bob --outder \
        --load-privkey bob.sign.key --load-certificate bob.sign.crt \
        --load-ca-certificate ca.rsa.cross.crt --outfile bob.gnutls.p12

I'm attaching bob.sign.key, bob.sign.crt, and ca.rsa.cross.crt to this
message in case anyone wants to try to replicate.
I'm also attaching the resultant DER-encoded PKCS12 objects.

From what i can tell, both of these PKCS12 objects are in the definite
form (good), but both also appear to show only one layer of OCTET STRING
encoding around the SEQUENCE.  Can you confirm?

Interestingly, macOS's Keychain Access (KA) *does* let me import both
bob.openssl.p12 and bob.gnutls.p12.

So, if my analysis is correct, maybe the issue isn't about layers of
OCTET STRING but rather something about the struture of the PKCS#12
object itself inside those layers?

bob.laundered.p12 has multiple secret keys with corresponding
certificates, and KA can import both at once, so i don't think that KA
is incapable of dealing with multiple secret keys.

So i'm looking for other differences.

Maybe it's about the structure instead?  I'll represent a "Certificate"
or encrypted-pkcs8 object with CONTENTS:FNAME:KEYID where CONTENTS is
the name of the corresponding input file, FNAME is the embedded
"friendlyName" and KEYID is a placeholder that represents the embedded
"localKeyID".  if a FNAME or KEYID are absent, those parameters aren't
present for that object in the bundle.

 - bob.p12 has 5 bags:
   - [0] encrypted([cert]) (bob.encrypt.crt:"bob":X)
   - [1] encrypted([cert]) (bob.sign.crt::Y)
   - [2] encrypted([cert]) (ca.rsa.cross.crt::)
   - [3] encrypted-pkcs8 (bob.encrypt.key:"bob":X)
   - [4] encrypted-pkcs8 (bob.sign.key:"bob":Y)

 - bob.laundered.p12 has 4 bags, some of which have multiple certs in them:
   - [0] encrypted-pkcs8 (bob.sign.key:"bob":X)
   - [1] encrypted([cert,cert]) (ca.rsa.cross.crt:"Sample LAMPS RSA Certification Authority":,bob.sign.crt:"bob":X)
   - [2] encrypted-pkcs8 (bob.encrypt.key:"bob":Y)
   - [3] encrypted([cert,cert]) (ca.rsa.cross.crt"Sample LAMPS RSA Certification Authority":,bob.encrypt.crt:"bob":Y)

Some theories worth testing:

 a) The order of the certificates and encrypted pkcs8 blobs might
    matter.

 b) The absence of the friendlyName on bob.p12[bag[1]] might matter.

Are there rules for how a PKCS#12 interpreter is supposed to associate
private keys with certificates that depend on both friendlyName and
localKeyID matching within the bundle?

       --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Aug 2021 08:17:02 -0400

> - I concur that interoperation for private keys is nonsense.

I think i understand the sentiment about wanting PKCS#12 to die, given
what a disaster the implementations are and how poorly we collectively
understand the format.

However, i don't understand how interoperation for private keys is
nonsense.

Many people with e-mail accounts use multiple mail user agents to access
the same account (e.g. one MUA on their phone, another on a laptop).  If
those accounts are supposed to be able to use end-to-end secure
communication then at least one of them needs to be able to export its
private key material and the other needs to be able to import it.

For myself, I only use a single MUA.  So my personal workflow would be
entirely satisfied if we as a standards body were to declare that there
is no interop need for private keys.  But if we want to ensure that
end-to-end cryptographic protections are usable and secure for actual
e-mail users, then we need to figure out the interop issues for private
key material, even if each e-mail user only encounters this interop
scenario once, as they provision their second MUA.

The only way I understand S/MIME to work today is for all the MUAs
attached to a given e-mail account to have access to the same private
keys, at the very least for those private keys used for message
decryption.

Assuming that we want people to be able to read their encrypted e-mail
in any MUA in which they read e-mail, the other two usable architectural
alternatives i see are:

 a) private keys are only ever stored on a hardware token which moves
    between devices with the user.

 b) different MUAs use different private keys for decryption, and the
    sender of an e2e encrypted e-mail encrypts each message to *all* the
    encryption-capable certificates it knows about for the user.

(a) still requires us to standardize private key interop, though it's
more of the PKCS#11-style than PKCS#12.  And it requires work on
hardware interfaces too.

(b) is a major systems change, requiring MUAs to change what
certificates they advertise for the user (each MUA *must* learn about
the other MUAs attached to the account and advertise the corresponding
encryption certificates as well), and all senders to adjust behavior by
sending messages encrypted to multiple keys per recipient.

Compared to either of these, standardizing software-based private key
interop seems like an easy lift.

I sympathize with the grumbling about it, but I'd hope that the experts
in the IETF LAMPS WG can at least come to a consensus that there is
value in standardizing interop for decryption-capable private keys.

       --dkg

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Aug 2021 13:33:26 +0100

Hiya,

> value in standardizing interop for decryption-capable private keys.

We tried that before [1] but it might be worth
another shot. The previous attempt got wrapped
up in a then-fashionable transport that never
really took off and was also affected by now-
expired IPR.

That'd need to be a separate WG though. Not
sure if it'd be better scoped to mail or to be
more broad.

I think the critical question, then as now, is
whether or not applications would adopt.

Cheers,
S.

[1] https://tools.ietf.org/wg/sacred/

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 5 Aug 2021 12:45:08 +0000

I have dreamt for a long time that there would be an interoperable data exchange format for keys and certificates (think Token/HSM backup/restore). Something more efficient and user friendly than individual PKCS#8 and PEM files. I think it potentially could advance things that is imho held back by lack of interoperability and lock-in. Whether applications would adopt is a good question however. I don't represent a token vendor, just a user who think I see a benefit, so...

Cheers,
Tomas
________________________________
From: Spasm <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Thursday, August 5, 2021 2:33 PM
To: Daniel Kahn Gillmor <[email-masked]>; LAMPS WG <[email-masked]>
Subject: Re: [lamps] On the need for standardization of software-based interoperable private keys [was: Re: draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)]

Hiya,

Cheers,
S.

[1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fwg%2Fsacred%2F&amp;data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C9f66bfa597fd4ceb346c08d9580d4501%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637637636287867009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=2D43V9LfLHXtkzRWZnAfF0HlLSOySFTWHKyldxE3moc%3D&amp;reserved=0

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 5 Aug 2021 14:48:58 +0200

Dear Daniel,

> shows how they were generated.

It's not my repo, it's a Red Hat PKCS12 test corpse :)

I asked my colleagues for more details.

The certs in that repo were generated by openssl, gnutls or NSS, but some
of them were generated by modifying the sources of those libraries
so that's why there is no script to generate them.

They also say there is no single implementation that can import all of them.
Quoting them,
"basically it's a set of pkcs#12 files that to the best of our knowledge
are well formed (with the exception of the NSS files with unicode
passwords)."

These files mostly demonstrate various encryption options.

> a single-private-key use case so that we can try to evaluate encodings.

I've never seen PKCS12 with multiple private keys so I totally agree with
you.

-- 
SY, Dmitry Belyavsky

---

From: Carl Wallace <[email-masked]>
Date: Thu, 05 Aug 2021 08:52:04 -0400

Given everyone has a hardware crypto module in their pocket these days and setting aside key escrow concerns, another way to get at this would be to encrypt for more than one key and forego exporting and sharing keys. That might not even require new protocol work but just better use of what we have now.

From: Spasm <[email-masked]> on behalf of Tomas Gustavsson <tomas.gustavsson=[email-masked]>
Date: Thursday, August 5, 2021 at 8:45 AM
To: Stephen Farrell <[email-masked]>, Daniel Kahn Gillmor <[email-masked]>, LAMPS WG <[email-masked]>
Subject: Re: [lamps] On the need for standardization of software-based interoperable private keys [was: Re: draft-ietf-lamps-samples: PKCS12 expertise needed (including objects for comparison)]

Cheers,

Tomas

Hiya,

Cheers,
S.

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

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 5 Aug 2021 15:33:39 +0200

Dear Carl,

Even in this case you have to implement some sort of bootstrapping on the
new device...

On Thu, Aug 5, 2021 at 2:52 PM Carl Wallace <[email-masked]>
wrote:

> Given everyone has a hardware crypto module in their pocket these days and
> setting aside key escrow concerns, another way to get at this would be to
> encrypt for more than one key and forego exporting and sharing keys. That
> might not even require new protocol work but just better use of what we
> have now.
>
>
>
> *From: *Spasm <[email-masked]> on behalf of Tomas Gustavsson
> <tomas.gustavsson=[email-masked]>
> *Date: *Thursday, August 5, 2021 at 8:45 AM
> *To: *Stephen Farrell <[email-masked]>, Daniel Kahn Gillmor <
> [email-masked]>, LAMPS WG <[email-masked]>
> *Subject: *Re: [lamps] On the need for standardization of software-based
> interoperable private keys [was: Re: draft-ietf-lamps-samples: PKCS12
> expertise needed (including objects for comparison)]
>
>
>
> I have dreamt for a long time that there would be an interoperable data
> exchange format for keys and certificates (think Token/HSM backup/restore).
> Something more efficient and user friendly than individual PKCS#8 and PEM
> files. I think it potentially could advance things that is imho held back
> by lack of interoperability and lock-in. Whether applications would adopt
> is a good question however. I don't represent a token vendor, just a user
> who think I see a benefit, so...
>
>
>
> Cheers,
>
> Tomas
> ------------------------------
>
> *From:* Spasm <[email-masked]> on behalf of Stephen Farrell <
> [email-masked]>
> *Sent:* Thursday, August 5, 2021 2:33 PM
> *To:* Daniel Kahn Gillmor <[email-masked]>; LAMPS WG <
> [email-masked]>
> *Subject:* Re: [lamps] On the need for standardization of software-based
> interoperable private keys [was: Re: draft-ietf-lamps-samples: PKCS12
> expertise needed (including objects for comparison)]
>
>
>
> CAUTION: External Sender - Be cautious when clicking links or opening
> attachments. Please email [email-masked] with any questions.
>
>
> Hiya,
>
> [1]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fwg%2Fsacred%2F&amp;data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C9f66bfa597fd4ceb346c08d9580d4501%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637637636287867009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=2D43V9LfLHXtkzRWZnAfF0HlLSOySFTWHKyldxE3moc%3D&amp;reserved=0
>
> _______________________________________________ Spasm mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/spasm

-- 
SY, Dmitry Belyavsky

---

From: Carl Wallace <[email-masked]>
Date: Thu, 05 Aug 2021 09:36:10 -0400

Of course. We have a potpourri of certificate enrollment protocols at our disposal. 

Dear Carl,

Even in this case you have to implement some sort of bootstrapping on the new device...

On Thu, Aug 5, 2021 at 2:52 PM Carl Wallace <[email-masked]> wrote:

Cheers,

Tomas

Hiya,

Cheers,
S.

 

-- 

SY, Dmitry Belyavsky

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 5 Aug 2021 13:47:29 +0000

Am I the only one who thinks there's a difference between protocols and data formats?

--
Regards,
Uri

On 8/5/21, 08:18, "Spasm on behalf of Daniel Kahn Gillmor" <[email-masked] on behalf of [email-masked]> wrote:

           --dkg

---

From: Eliot Lear <[email-masked]>
Date: Thu, 5 Aug 2021 16:52:08 +0200

I REALLY hope not.  Are we REALLY struggling with that point?

Eliot

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 5 Aug 2021 11:03:46 -0400

> The tooling i've been playing with confirms this read.

Right, but bob.p12 does not appear to match this (it goes data -> SEQUENCE,
not data -> OCTET STRING -> SEQUENCE, unless I'm truly holding things
wrong), and that's why I was trying to understand the process for that
being generated.

> encoding around the SEQUENCE.  Can you confirm?

Right, my previous message tried to explain that this is expected from DER
encoding. The single layer of OCTET STRING is the correct form, the
multiple layers I mentioned were a quirk of how indefinite BER (which NSS
was generating, and which I overlooked) was generating. So we should ignore
this as being the cause here - it was very much PEBKAC on my part for
overlooking the indefinite length on the BER.

> object itself inside those layers?

Yes

> localKeyID matching within the bundle?

I don't see any such rules about matching, period, in RFC 7292.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 5 Aug 2021 15:07:15 +0000

Since in this discussion people repeatedly call PKCS#12 a “protocol”, I think that we do.

--
Regards,
Uri

 
    On 8/4/21, 17:44, Michael Richardson wrote:
    >     I would be happy if pkcs12 just died.
 
    On Wed 2021-08-04 22:28:17 +0000, Blumenthal, Uri - 0553 - MITLL wrote:
    > - PKCS#12 cannot "just die" because there's a ton of software that cannot import private keys, unless they're in .p12 or such.
    > - I concur that interoperation for private keys is nonsense.

 

 

 

 
 
           --dkg

---

From: Michael Richardson <[email-masked]>
Date: Thu, 5 Aug 2021 11:23:46 -0400

> However, i don't understand how interoperation for private keys is

+1

> private key material and the other needs to be able to import it.

Also, keys might get backed up differently from the rest of "C:",
(I've printed them to QRcode for instance), and when the disk is 
restored, sometimes software is different versions, or one chooses 
different software, or as you say, different MUAs.

The need to go back to my key twenty years ago and reload it so that I 
can decrypt old email.

With multiple mail user agents, I like to have different signing keys.

> For myself, I only use a single MUA.  So my personal workflow would be

My situation is a single MUA with ssh access, but also scripts that move 
where my MUA is... but different keys... so if I have to decrypt I have 
to ssh.

>      between devices with the user.

unreliable in the long-term.  Physical interfaces change over the years.

>      encryption-capable certificates it knows about for the user.

Not mutually exclusive to (a).

> sending messages encrypted to multiple keys per recipient.

This is still worthwhile doing, even if we don't fix pkcs12.

> interop seems like an easy lift.

My preference is to say, in an RFC, that PKCS12 is obsolete, and that 
PKCS8 is the right answer.  Then we can beat up the Java/NSS/etc. 
vendors who are still stuck on PKCS12.

Also, whatever we do, it will need some variety of PQC algorithms/OIDs 
added.   I also have operational concerns about the read-modify-write
cycle needed by HSS.   Cold-storage/backup of HSS keys could be an 
operational nightmare, and while it hopefully will never affect mail 
user agents, doing code signing on a desktop is completely realistic for 
smaller companies.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 5 Aug 2021 11:28:20 -0400

On 2021-08-05 8:33 a.m., Stephen Farrell wrote:

> [1] https://tools.ietf.org/wg/sacred/

Wow.

That effort is old enough to have a driver's license and outside of the 
US, drink.

RFC3767 says: "The protocol's payloads are described in XML"
maybe we have to start again with CBOR....  i never read those documents.

Maybe, if we need to do a meeting on this topic, you'll give us an 
overview, and tell us what aspects of this were good ideas worth preserving.
At the time, the dominant desktop was Windows (2000), and the question 
is, did MS not implement, and so it was never used?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 5 Aug 2021 11:31:04 -0400

On 2021-08-05 8:52 a.m., Carl Wallace wrote:
> Given everyone has a hardware crypto module in their pocket these days 

yes, me.  I don't use it much, and not for email at all, although I 
guess it is supported.  I am hesistant because I don't know how to 
recover from loss of token.

But, nobody I know who isn't working at a big company/government has 
one.  And few of them either.

I'm not saying it couldn't change, but I think your assertion is not true.

> and setting aside key escrow concerns, another way to get at this would 
> be to encrypt for more than one key and forego exporting and sharing 
> keys. That might not even require new protocol work but just better use 
> of what we have now.
> 

I share your aspiration.

---

From: Carl Wallace <[email-masked]>
Date: Thu, 05 Aug 2021 11:36:41 -0400

Inline...

On 8/5/21, 11:31 AM, "Spasm on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    I'm not saying it couldn't change, but I think your assertion is not true.
[CW] I was referring to Secure Enclave in iPhones, TEE/Strong Box on Android and TPM on Windows 10 devices. I agree these are not widely used for email decryption, but they could be.  There certainly are enough of them around though.

    I share your aspiration.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 5 Aug 2021 15:47:14 +0000

There are legacy implementations with PKCS12 that are broken in strange and wonderful ways, and cause cryptographic libraries to perform unnatural acts to use algorithms that are no longer secure.

Updating PKCS12 to specify modern algorithms seems easy and in-charter. Updating the RFC to clarify some ambiguities might be harder, but should be considered as well.

The legacy implementations will muddle along. Browsers, maintained crypto libraries and current software that uses them will benefit.

Let's do this.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 5 Aug 2021 15:55:14 +0000

Yes! Let's do that. 

Regards,
Uri

> On Aug 5, 2021, at 11:48, Salz, Rich <rsalz=[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 12:24:57 -0400

Carl Wallace <[email-masked]> wrote:
    CW> I was referring to Secure Enclave in iPhones, TEE/Strong Box on
    CW> Android and TPM on Windows 10 devices. I agree these are not widely
    CW> used for email decryption, but they could be.  There certainly are
    CW> enough of them around though.

Hmm. I wasn't even thinking about my phone as a HSM.

Given that most of these devices are secured against the legal owners, do not
let me (or my IT director) decide what software I run, I'm not sure that I
feel secure enough with them for many uses.  I especially don't know how to
recover/renegated/re-enroll keys do when my phone is dropped in the toilet or
crushed under a bus.

When my previous phoned died hard, I only had two RFC 6238 profiles loaded
into my Google Authenticator.  I had my *Google* backup keys around, the
other one was ARIN, and I could phone them and authenticate.  I now have
about 12 things loaded, and I've taken the approach of *printing* the QRcodes
that initialize these to paper and putting them a file.  I have no idea how
to recover that, and the profiles don't seem to backup to google. (And maybe
that's according to plan).
I used to think like you, back when I ran Cyanogen everywhere, and thought
that we'd outgrow vendor/telco lockin on phones.  I now despair at
opportunities missed.

I don't know how I'd use the TEE in my phone with my laptop/desktop for email.
I imagine that one could run PKCS11 across the USB cable, but I'm unaware of
any actual software to do that.  That sure would be a nice thing to do.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 12:27:08 -0400

Salz, Rich <rsalz=[email-masked]> wrote:
    > There are legacy implementations with PKCS12 that are broken in strange
    > and wonderful ways, and cause cryptographic libraries to perform
    > unnatural acts to use algorithms that are no longer secure.

Agreed.

    > Updating PKCS12 to specify modern algorithms seems easy and
    > in-charter. Updating the RFC to clarify some ambiguities might be
    > harder, but should be considered as well.

    > The legacy implementations will muddle along. Browsers, maintained
    > crypto libraries and current software that uses them will benefit.

This is my point: the legacy stuff is there, we already muddle along and have
built interoperability with the broken stuff.  Yes, using 3DES, etc.

If we can get the legacy guys to open up their code, why fix PKCS12 if they
could just move to PKCS8? (or PKCS1 or...?)

---

From: Bernie Hoeneisen <[email-masked]>
Date: Thu, 5 Aug 2021 18:27:18 +0200 (CEST)

Hi,

On Thu, 5 Aug 2021, Daniel Kahn Gillmor wrote:

> the same account (e.g. one MUA on their phone, another on a laptop). 
> If those accounts are supposed to be able to use end-to-end secure 
> private key material and the other needs to be able to import it. [...] 
> if we want to ensure that end-to-end cryptographic protections are 
> usable and secure for actual e-mail users, then we need to figure out 
> the interop issues for private key material. [...]

For those interested in private key exchange technology: For the use case 
mentioned above, there are already several implementations (pEp KeySync) 
[1], which is working in an e2e manner; however these implementations are 
currenty PGP based (i.e. S/MIME is not yet suported).

We documented the pEp KeySync protocol in:

   https://datatracker.ietf.org/doc/html/draft-pep-keysync

cheers,
  Bernie

[1] https://pep.foundation/pep-software/index.html (last section)

---

From: Carl Wallace <[email-masked]>
Date: Thu, 05 Aug 2021 12:31:58 -0400

<snip>

    I don't know how I'd use the TEE in my phone with my laptop/desktop for email.
    I imagine that one could run PKCS11 across the USB cable, but I'm unaware of
    any actual software to do that.  That sure would be a nice thing to do.
[CW] I was not suggesting that but instead that a message be encrypted for each of your end points. I'm not sure why we are clinging to one encryption key per person. Amongst the keys messages for you are encrypted could be the key that you printed out, for example. I am not suggesting we’d not benefit from improved private key formats, but am suggesting we may be able to do better than slinging private keys around in some cases.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 5 Aug 2021 12:43:22 -0400

On Thu, Aug 5, 2021 at 12:32 PM Carl Wallace <[email-masked]>
wrote:

> [CW] I was not suggesting that but instead that a message be encrypted for
> each of your end points. I'm not sure why we are clinging to one encryption
> key per person. <snip>

Agreed.

In the parallel discussion being had by Michael Richardson and Rich Salz (
https://mailarchive.ietf.org/arch/msg/spasm/puyG9qwhxAQRBGbh8WIFxSZuPDQ/ ),
Michael asks

> could just move to PKCS8? (or PKCS1 or...?)

And I think that closely relates to the point you're making here.
Specifying an interoperable profile for PKCS#12 is a lot of effort, from a
specification side, and doesn't really address the implementation problem
of needing to support, for better or worse, existing keys. That is, it
seems we'll still have legacy producing bad-legacy, and then we'll have new
producing new-good, but implementations will end up needing to support both
paths, because in order for folks to adopt new-good, they'll want to bring
things in from old-legacy. The result of this is that, from an implementer
perspective, supporting/enforcing new-good is purely more work for them,
minimally at the production side (encoding), but if the goal is to reduce
the many mistakes of PKCS#12, then also at consumption side (decoding).

While it's true that old-legacy should be able to accept new-good, by
virtue of DER being compatible with BER, the inverse doesn't hold.

So Michael's question about activation energy is entirely relevant to what
I believe you're getting at, which is: If we're going to do anything,
should we be doing something tangibly better, and leaving this whole
silliness in the past? And yeah, I agree, we can do better, by reducing the
amount of key slinging that is happening, and being comfortable with the
existence of multiple keys. Protocols such as WebAuthN are designed around
this concept, as are the hardware tokens implementing it; the notion of
many keys (a key for origin/application), rather than trying to have One
Key to Rule Them All.

That still has the state change issue of old-legacy to new-good, but makes
it clearer that we're moving to a different system, which ends up being
more explicit that, yes, there are interoperability issues with old/new
expected, because they're unavoidable either way.

As it relates to the question of "Well, how do we deal with legacy", I
remain very much of the opinion of PKCS#8 being "good enough" as a format,
as it's what PKCS#12 uses under the hood still. So every PKCS#12 consumer
has the ability to consume PKCS#8 functionally, and that eliminates a huge
swath of complexity issues, so that works. The question of slinging keys
around becomes something dealt with at the protocol level, rather than the
format level, such as by accepting that a single entity may have many keys.
Yes, key management is hard, but that doesn't mean we should accept that
the solution is to put all of our proverbial eggs in one key basket. That
doesn't simplify the complexity, it just rearranges it (to key protection
and revocation).

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 13:14:35 -0400

Ryan Sleevi <[email-masked]> wrote:
    > things in from old-legacy.

But, bad-legacy -> new-good could be done by a separate executable/tool.

With a very small attack surface, such that it would be less concerned about
tracking latest code.
It could be statically linked against libraries that were specifically "broken"

(Sadly, not something we'd want as a web service...  So really must be
provided by OS vendor to be ubiquitous enough)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Aug 2021 13:12:10 -0400

On Thu 2021-08-05 13:33:26 +0100, Stephen Farrell wrote:
> We tried that before [1] but it might be worth another shot.
>

Thanks for pointing out this history, Stephen.  This predates IETF's
adoption of PKCS#12 (RFC 7292), though, by many years afaict.

The fact remains that there *is* a defacto standard for transfer of
bundled private keys and X.509 certificates, and IETF has formal change
control over it (PKCS#12).  If it doesn't live in LAMPS, despite being
used to exchange certificates and CRLs as well as private keys, i'm not
sure where it would live.  I'm loathe to spin up a new WG.

> I think the critical question, then as now, is whether or not
> applications would adopt.

If we wanted to make it harder to adopt, we could invent something new
from scratch. :)  that doesn't seem like a great idea.

If we wanted to improve existing implementations to enable better
interoperability with the existing defacto standard that we're
responsible for, we could:

 - try to establish a minimal common profile PKCS#12, which is far too
   flexible for its own good, and report bugs against implementations
   which deviate from that profile.  This being the IETF, i'm sure we'd
   come up with more than one "common" profile, but even a half dozen
   profiles would be an improvement over the multidimensional confusion
   that the standard permits.

 - build an interop test suite to identify failures in implementations
   that try to import any of the common profiles.

or,

 - formally deprecate PKCS#12 (e.g. move 7292 from informational to
   historical) and encourage some other standard (a PKZIP file full of
   independent PKCS#8 objects and certificate objects?  that seems
   morally equivalent to PKCS#12 to me, but a much longer lead time to
   get any sort of adoption)

I'll probably end up doing some of this work anyway just because i want
draft-ietf-lamps-samples to contain plausible objects that can be used
by most systems, but i'd be happy to have the WG behind it.

   --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Aug 2021 13:35:04 -0400

>    https://datatracker.ietf.org/doc/html/draft-pep-keysync

For OpenPGP, the Autocrypt project also encourages private key exchange
between MUAs that are used with the same account via the Autocrypt Setup
Message:

   https://autocrypt.org/level1.html#autocrypt-setup-message

Regards,

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Aug 2021 13:41:02 -0400

On Thu 2021-08-05 12:43:22 -0400, Ryan Sleevi wrote:
> we can do better, by reducing the amount of key slinging that is
> happening, and being comfortable with the existence of multiple
> keys. Protocols such as WebAuthN are designed around this concept, as
> are the hardware tokens implementing it; the notion of many keys (a
> key for origin/application), rather than trying to have One Key to
> Rule Them All.

Note that multiple authentication/signing private keys is significantly
easier to manage than multiple message encryption keys.  WebAuthN works
in a different space than encrypted e-mail.

Having an e-mail message delivered that is readable in only one of your
MUAs, when both MUAs are capable of reading *some* of your encrypted
messages, is a terrible UX failure.

Deciding to fix that by fixing all the senders in the world to encrypt
to all the valid encryption-capable certs they have for a recipient (and
ensuring that they actually *do* have all the certificates for a given
peer) is a complex, long-term, systems-level problem to solve.

In the meantime, sharing a decryption-capable private key between MUAs
is a one-time, one-shot fix that the account owner can perform on their
own (or could, if the tooling were actually functional), and even works
to unlock old messages that had already been sent before the new MUA was
brought online.

Signing (of which authentication is a subset) is a different problem
than store-and-forward encryption to a potentially offline peer.

       --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Aug 2021 11:39:48 -0400

> It's not my repo, it's a Red Hat PKCS12 test corpse :)

Thanks for the clarification, and the history about it. :)  It's
distressing to learn that there are no implementations capable of
importing all of the objects in this repo.

Has anyone set up an interoperability test suite to document which tools
fail in which ways, or filed bug reports against the different
implementations that fail?

The four F/LOSS pksc12 implementations that seem straightforward to test
in an automated way are:

 - "certtool --p12-info" from GnuTLS
 - "openssl pkcs12" from OpenSSL
 - "pk12util" and "certutil" from NSS
 - "keytool" from the Java JDK

Are there other tools i should consider testing?  Does anyone know of an
automated way of testing macOS's Keychain Access, or the Windows
equivalent?

> On Thu, Aug 5, 2021 at 2:49 AM Daniel Kahn Gillmor <[email-masked]> wrote:
>
>> I'll set aside the multiple-key case for now, to focus for the moment
>> on a single-private-key use case so that we can try to evaluate
>> encodings.
>
> I've never seen PKCS12 with multiple private keys so I totally agree
> with you.

I encourage you to read draft-ietf-lamps-samples 😉, which has included
these objects since February 17th of this year (back when it was
draft-dkg-lamps-samples-03)!

    --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Aug 2021 14:50:27 -0400

> could just move to PKCS8? (or PKCS1 or...?)

afaict, PKCS8 and PKCS1 both only support transporting a single private
key.

PKCS12 is a bundle, which can support not only a private key, but also a
corresponding certificate and potentially other certs in the relevant
chain.

Additionally, since we want an e-mail user to have multiple certs (one
for signing and one for encryption) they may also want to transfer
multiple private keys.  As i wrote elsewhere in this thread the
decryption-capable private key is the highest-priority private key for
transfer, but there are plausible privacy arguments [0] for wanting to
share signing-keys between MUAs as well.  And once you're transferring
one private key it shouldn't be much harder technically to transfer more
than one.

But It is poor user experience to ask someone to export a multiple PKCS8
and PKCS1 objects from device X, transfer them to device Y, and then
reimport them all individually.  Any reasonable user experience for
end-to-end cryptographic MUAs should involve a bundle format.

afaict, that's what PKCS12 is -- a bundle format that specializes in
transporting PKCS8 objects and X.509 certificates.  Would some other
bundle format be better?  or is there a way to bundle PKCS8 and PKCS1
and X509 that i'm not aware of?  Is the counterproposal to PKCS12 just
to offer a series of concatenated PEM-encoded objects in a text file?

I'm definitely not sold on PKCS12, it looks like a disaster to me.  But
I want to understand what the counterproposals are that people are
seriously considering, so i can mock up what draft-ietf-lamps-samples
would look like with some other bundle format replacing PKCS12.

   --dkg

[0] https://anarc.at/blog/2018-07-27-signal-metadata/ is about receipt
    notifications in an instant messenger client, but anyone sending
    mail might prefer to not have their outbound message leak
    information about the device they composed it on.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 5 Aug 2021 20:57:01 +0200

Dear Daniel,

> importing all of the objects in this repo.

Malformed files were created by NSS and are not expected to be importable
by anything but NSS, so just that alone means no implementation will be
able to import all of them.
The malformed files are there as NSS has special code to handle those
malformed files.
and since those include stuff like aes-128-cbc (i.e. quite sensible choice)
they may happen "in the wild" but realistically only NSS needs to read them.

NSS should accept these files and all the others except those encrypted
with the algorithms unsupported by NSS (seed, blowfish).
GnuTLS also supports only a limited set of algorithms for PKCS#12.

OpenSSL is able to import pretty much all of them and here's a PR for
openssl that tries to include it in the upstream CI:
https://github.com/openssl/openssl/pull/15188

>  - "keytool" from the Java JDK

We do test all those 3 libraries with those files, and file bugs to add
support for missing things
(e.g. https://gitlab.com/gnutls/gnutls/-/issues/723 and
https://gitlab.com/gnutls/gnutls/-/issues/724)

We don't run our tests against the keytool.

> draft-dkg-lamps-samples-03)!

My fault :)

-- 
SY, Dmitry Belyavsky

---

From: David Woodhouse <[email-masked]>
Date: Thu, 05 Aug 2021 20:10:59 +0100

> value in standardizing interop for decryption-capable private keys.

The beautiful thing about standards is that there are so many of them
to choose from.

Users are beholden to their certificate issuer for the precise form in
which their certificates (and, potentially, keys) are generated.

I look at this from the point of view of a VPN client application
author. My users have keys in fairly much every form you can imagine,
and generally lack the technical knowledge to convert them to any "one
true standard". But it isn't so far from the 'multiple MUAs' use case
really.

I have often lamented the fact that none of the popular crypto
libraries give me a way, as an application author, to say "just use
*this* key file/URI that the user gave me". I have literally
*thousands* of lines of code in my application just to do that
supposedly simple job in order to be a well-behaved application and
Just Work™ for my users with whatever cert they were issued.

I even got so annoyed with it that I started writing the draft at 
http://david.woodhou.se/draft-woodhouse-cert-best-practice.html which
outlines the various file and URI forms that I believe applications
*should* accept out of the box without forcing the user to convert.

I kind of baulk at the idea of adding yet *another* standard to that
list. I think I do prefer the idea of encouraging applications to
coherently support the disparate zoo of existing formats that are going
to continue to exist in practice anyway, and perhaps making the crypto
libraries help out a little bit by making it less painful for
application authors to do so.

---

From: David Woodhouse <[email-masked]>
Date: Thu, 05 Aug 2021 20:16:34 +0100

> could just move to PKCS8? (or PKCS1 or...?)

My recollection is that PKCS#8 doesn't actually specify the character
set to be used for the passphrase fed into PBKDF. Even RFC8018
lamentably just refers to UTF-8 as a "possibility".

This makes it kind of awful for interchange.

At least PKCS#12 mandates a BMPString. Not that software generating
PKCS#12 objects has always got *that* right, mind you...

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Aug 2021 20:33:41 +0100

Hiya,

> from scratch. :)  that doesn't seem like a great idea.

Sure, parts of this relate to key container formats, and
variants of p12, despite their awfulness, are as close as
we get to a broadly interoperable and supported thing.

But there's also the way to move key containers from
place to place. I don't recall any proposal that's gotten
near traction from the various MUA developers never mind
more broadly. And I think it's that that's the harder to
figure question TBH.

Cheers,
S.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 5 Aug 2021 15:52:58 -0400

> from scratch. :)  that doesn't seem like a great idea.

There's a lot to unpack here.

RFC 7292 is Informational, so when talking about "defacto standard", we
should make sure we're talking about just that - a rough consensus that
existed long before the IETF published that version, and that
implementations have largely ignored any differences in the IETF version
because they already implemented it to begin with, from "ye old days". The
complaints I mentioned about PFX date to 1998 - these aren't new things
we've learned in the past 7 years, but things we've known for over two
decades :(

The fact that IETF has formal change control over a document doesn't make
it a good basis. Considering all of the fun discussions in this space in
the past, like the complicated history that led to RFC 8894 or RFC 7468.
These are prime examples of specs attempting to document what
implementations mostly did, but not being something that you can hold up as
stone tablets or gold standards. Put differently: If you imagine the goal
of "rough consensus, and running code", these specs are reflections of
"rough consensus in trying to describe running code" - not "running code
trying to match the rough consensus"

You suggest it's easier to adopt nu-PKCS#12 than something new entirely. As
someone who has had his hands in the lower levels of the implementation
space here (e.g. in trying to fuzz NSS's BER decoder, which I absolutely
would not trust for anything sensitive to this day, and debugging the bugs
from it), the problem with trying to adapt any implementation to nu-PKCS#12
is precisely the fact that "There's a ton of legacy here, anything that
breaks anything for anyone with existing files will make them unhappy, and
there's no way to know what badness or interop issues will come out". The
joy (and curse) of new standards is that they are free from the historic
baggage and inertia that comes from an existing chaotic deployed base. Any
challenge you have finding interest in nu-not-PKCS#12 is the same
challenge, or less, than in in adopting nu-PKCS#12, if only because there's
less legacy to deal with.

I'm highly skeptical of adopting revisions to PKCS#12, not because I don't
believe there is value in it, but because I don't believe the value is
significant enough to justify the undesirable risk of dealing with a
terrible format that is, respectfully, for a bit of a niche case. The
problem here is that it tries to solve "too many problems" in that overly
generic way that we design things, but everything we've learned - both of
formats and protocols - in the past 20 years seems to be trending more
towards the "Greater interoperability through greater GREASE" [1]. The
reality is PKCS#12 is a bit rusted. But that skepticism is personal, and I
don't think would necessarily block the IETF from tackling it, if you were
able to find implementors willing to drive convergence and able to execute
on it :)

[1]
https://textslashplain.com/2020/05/18/a-bit-of-grease-keeps-the-web-moving/

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 16:20:40 -0400

> get any sort of adoption)

This.

But, not PKZIP... CBOR array of bstr.
draft-ietf-cose-x509-08

   x5bag:  This header parameter contains a bag of X.509 certificates.
      The set of certificates in this header parameter is unordered and
      may contain self-signed certificates.  Note that there could be
      duplicating certificates.  The certificate bag can contain
      certificates which are completely extraneous to the message.  (An
      example of this would be where a signed message is being used to
      transport a certificate containing a key agreement key.)  As the
      certificates are unordered, the party evaluating the signature
      will need to be capable of building the certificate path as
      necessary.  That party will also have to take into account that
      the bag may not contain the full set of certificates needed to
      build any particular chain.

...

We just need allow PKCS8 objects too.
Call it "pkcs12bag" if you like.
A simple cbor array can be open-coded (no library really needed) way easier
than PKZIP or any other thing.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 16:25:23 -0400

> end-to-end cryptographic MUAs should involve a bundle format.

I accept that it's poor for users.

But, right now they are having "openssl pkcs12" command line inflicted upon them.
It's clear that system operators hate doing this, and they are hardly end users.

    > Is the counterproposal to PKCS12 just

Yes, that's what I was thinking about.

Many daemons accept having the PKCS1/8 and PKCS7 certificates in the "key"
file already.   I tend not to like that configuration, but I understand why
some prefer it.

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 5 Aug 2021 22:27:34 +0200

Dear David,

> PKCS#12 objects has always got *that* right, mind you...

AFAIR, OpenSSL tries both BMP encoding and UTF8, at least on decoding.
If I recall correctly, Russian GOST PKCS#12 specification prescribes UTF8
here.

-- 
SY, Dmitry Belyavsky

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Aug 2021 16:34:22 -0400

> list. I think I do prefer the idea of encouraging applications to

Yeah, so really we need to be removing things from the list, and
where there are issues (like passphrase for PKCS8), then we need to
clarify.

BTW: I think that this all fits into LAMPS.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Aug 2021 20:50:40 -0400

I've just published draft-ietf-lamps-samples-05 after figuring out what
i needed to do to make Keychain Access accept the PKCS#12 objects.

The necessary change was to make the PKCS#12 MAC
(https://www.rfc-editor.org/rfc/rfc7292.html#appendix-A) use SHA1
instead of SHA512.

I have no idea why Keychain Access would fail when the MAC is SHA512
instead.  I have not yet experimented with other digests with Keychain
Access.

Before I figured out that this specifically was the issue, i modified
the certficate generation code in GnuTLS to account for all the
divergences i could account for that were *not* due to indefinite
encoding.

This included these two differences:

>  b) The absence of the friendlyName on bob.p12[bag[1]] might matter.

And all the rest here:

 c) the PKCS-8 keys in the original bob.p12 contain a PKCS#8 Provable
    Seed attribute (1.3.6.1.4.1.2312.18.8.1) to indicate their origin,
    but the laundered form does not retain those attributes.

 d) the original bob.p12 file has a separate bag with just the
    certification authority cert in it, whereas bob.laundered.p12 has
    the CA's cert prepended to both EE bags.

 e) embedded PKCS-8 encryption uses different choices for password-based
    key derivation (both use:
     - laundered: 16 octet salt, 600000 iterations
     - bin: 8 octet salt, 5126 iterations

 f) cert bags use different encryption choices:
     - laundered: PKCS12-RC2-40-SHA1 (1.2.840.113549.1.12.1.6),
       16-octet salt and 6000000 iterations
     - bin: PKCS12-3DES-SHA1 (1.2.840.113549.1.12.1.3),
       8-octet salt and 5301 iterations

 g) overall MAC parameters:
     - laundered:  16-octet salt and 600000 iterations;
     - bin:         8-octet salt and 10240 iterations

There is a tremendous amount of multidimensional flexibility in the
PKCS#12 spec, so i thought it might be worthwhile to publicly note all
the different axes of permutation that i considered before landing on
the quirk specific to this particular implementation.

Anyway, i think this particular issue has been resolved for the draft.
I'll follow up in a separate thread about what i think remains for the
WG here.

    --dkg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 6 Aug 2021 01:10:46 +0000

I wonder if Keychain Access would accept SHA256 MAC.

Because it would be nicer if we could stick with SHA2, not encumbering the stack with SHA1 code (and some implementations might have a requirement to exclude "unblessed" algorithms).

TNX
--
Regards,
Uri

On 8/5/21, 21:05, "Spasm on behalf of Daniel Kahn Gillmor" <[email-masked] on behalf of [email-masked]> wrote:

    And all the rest here:

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 06 Aug 2021 09:52:04 -0400

> I wonder if Keychain Access would accept SHA256 MAC.

Good question.  Attached is a zipfile bob.digests.zip with four variants
of bob.p12, varying only by MAC digest algorithm.  I tested using a MAC
based on:

 - SHA1
 - SHA2-256
 - SHA2-384
 - SHA2-512

Of the above, only the SHA1 file is importable on Keychain Access,
according to my testing.  The other three all fail in the same way.

> Because it would be nicer if we could stick with SHA2, not encumbering
> the stack with SHA1 code (and some implementations might have a
> requirement to exclude "unblessed" algorithms).

I generally agree with this.  I'd prefer to not publish something new
that requires the use of SHA1 to interpret it in 2021.  That said, the
encryption schemas internally are also using PKCS12-3DES-SHA1, so we'd
still be requiring SHA1 on the critical path unless we fix the ciphers
in the PKCS#12 object.

To that end, I tested several different PKCS12 encryption schemes (while
holding the overall MAC to SHA1) and tried to import them into Keychain
Access.  I found that the following schemes would work:

 - PKCS12-3DES-SHA1 (1.2.840.113549.1.12.1.3) (what we've had so far)
 - PKCS12-ARCFOUR-SHA1 (1.2.840.113549.1.12.1.1) 
 - PKCS12-RC2-40-SHA1 (1.2.840.113549.1.12.1.6)

But Keychain Access choked using these schemes:

 - PBES2-3DES-CBC (1.2.840.113549.3.7)
 - PBES2-AES128-CBC (2.16.840.1.101.3.4.1.2)
 - PBES2-AES192-CBC (2.16.840.1.101.3.4.1.22)
 - PBES2-AES256-CBC (2.16.840.1.101.3.4.1.42)

The attached bob.ciphers.zip contains the sample PKCS#12 objects if
anyone wants to experiment with them too.

So if we decide to go ahead and publish using either a SHA2 digest for
MAC and a PBES2-based scheme for encryption, we're basically accepting
that current versions of Keychain Access won't be able to use the
PKCS#12 objects.  (Apple can of course fix Keychain Access to support
these ciphers and MAC algorithms if they choose to).

Any opinion from the rest of the WG on the right thing to do here?

         --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 6 Aug 2021 10:55:28 -0400

> according to my testing.  The other three all fail in the same way.

Correct. SHA-2 was introduced when the IETF took change control (with
7292), but as mentioned, many PKCS#12 implementations haven't been touched
since ~2004/2005 :)

Assuming you're on macOS doing this,
https://opensource.apple.com/source/Security/Security-59754.80.3/OSX/sec/Security/p12import.c.auto.html
is most likely the relevant implementation here for this particular code
path (Keychain Access), and you can see the list of PBE algorithms
supported there in the pkcsOidInfos table.

The p12VerifyMac function is hardcoded for SHA-1.

(That said, as mentioned, Apple has many CMS parsers and thus has many
potential paths for PKCS#12 implementations)

> these ciphers and MAC algorithms if they choose to).

 While I realize you've been focused on Apple, I'll note that NSS shares
the same limitation, which you can see in the current NSS main branch:
https://searchfox.org/nss/rev/590a961f13090ed96ba8d235ca4dd3a1636d56cf/lib/pkcs12/p12dec.c#108-112

---

From: Jonathan Hammell <[email-masked]>
Date: Sat, 7 Aug 2021 10:39:45 -0400

> But, not PKZIP... CBOR array of bstr.

I don't see anyone suggesting use of RFC 5958, despite it obsoleting
RFC 5208 (PKCS #8).  AsymmetricKeyPackage is a SEQUENCE of
OneAsymmetricKey, thus giving a bundle of private keys (and optional
public keys).

The cryptographic protection differs from PKCS #12, since the entire
SEQUENCE would be protected by a CMS structure like AuthEnvelopedData
with PasswordRecipientInfo, for example, rather than each key
encrypted separately within EncryptedPrivateKeyInfo as in PKCS #8 and
PKCS #12.  However, for transporting a key bundle to another MUA, one
would likely prefer to use a single password anyway.

I don't know about adoption of this, but I do not see a reason to
define a new private key bundle format for the use case that DKG is
considering.

Jonathan

---

From: Russ Housley <[email-masked]>
Date: Sat, 7 Aug 2021 11:52:07 -0400

> On Aug 5, 2021, at 1:12 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

RFC 5208 is the PKCS#8 v1.2 specification.

RFC 5985 is an enhancement to PKCS#8 that allows the certificate to be carried along with the private key.  In addition, RFC 5985 provides a content type for PKCS#8.

RFC 4073 defines a way to carry a collection of contents, each with their own type:

      ContentCollection ::= SEQUENCE SIZE (1..MAX) OF ContentInfo

These seem to be the building blocks that are needed to carrya a collection of PKCS#8-protected private keys along with the associated certificate.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 7 Aug 2021 12:00:44 -0400

DKG:

It is clear that you did a lot of work to figure out a way forward.  Thank you!

Russ

> On Aug 5, 2021, at 8:50 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Signed PGP part

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 08 Aug 2021 22:38:28 -0400

Hi Ryan, other LAMPSers--

> supported there in the pkcsOidInfos table.

thanks for digging up the history and some of the source code.  Is there
a reason you chose version 59754.80.3 of Security here?  there seem to
be more recent versions published, and i am unable 

> https://searchfox.org/nss/rev/590a961f13090ed96ba8d235ca4dd3a1636d56cf/lib/pkcs12/p12dec.c#108-112

I do *not* think that NSS has the same limitation.  Using pk12util from
libnss3-tools 2:3.68-1 on debian unstable, i have no problem listing the
contents of any PKCS12 object, using any combination of MAC from
{SHA1,SHA2-256,SHA2-384,SHA2-512} or cipher scheme from
{PBES2-3DES-CBC,PBES2-AES128-CBC,PBES2-AES192-CBC,PBES2-AES256-CBC,PKCS12-3DES-SHA1,PKCS12-ARCFOUR-SHA1,PKCS12-RC2-40-SHA1}

In fact, of the four F/LOSS tools i've tested (NSS's pk12util, GnuTLS's
certtool, openssl pkcs12, and java keytool), only keytool has any
problem with any of the above -- it can't handle PBES2-AES192-CBC or
PBES2-3DES-CBC.  All of them can handle all the SHA2 MACs and all but
keytool can handle all of the cipher schemas.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 09 Aug 2021 12:57:28 -0400

> These seem to be the building blocks that are needed to carrya a collection of PKCS#8-protected private keys along with the associated certificate.

Thanks, Russ!  I appreciate this collection of pointers, but i am not
convinced they belong in draft-ietf-lamps-samples today given that i
don't know of any tooling that is capable of ingesting them.

If someone in the WG wants to assemble such an object from the keys and
certs already in the draft, and other folks in the WG can independently
confirm that it appears to be correct, then i'd be fine with including
it alongside the PKCS#12 objects that the draft currently publishes.
I'd be even more strongly convinced if someone can point to an
implementation that is capable of processing them.

Including such an object in the spec might be a helpful spur for
adoption!  But without other people stepping forward to assemble and
test the pieces and point to implemententations, i'm inclined to leave
this as future work so we can get draft-ietf-lamps-samples out the door.

     --dkg

---

From: Russ Housley <[email-masked]>
Date: Tue, 10 Aug 2021 09:55:41 -0400

> On Aug 9, 2021, at 12:57 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Signed PGP part

I was not suggesting them for lamps-samples.

I was pointing out a simple way to construct an alternative to PKCS#12 for multiple private keys and their certificates.

Russ

---

From: Deb Cooley <[email-masked]>
Date: Thu, 12 Aug 2021 06:11:37 -0400

apologies for being late to this party....

Note:  everything here is about encryption keys:

Hold on a minute.  All fine and good to say that 'a message be encrypted
for each of your end points', but how does the RP get the public key for
all of those end points?  not like we have a directory or anything. Do you
want a signed message from each end point?  Who is going to do that?

It won't work.  If the big directory in the sky had panned out, then one
could push all the public keys you wanted to your directory entry.  A RP
could encrypt to you including all of your encryption keys.  Is there
another way?

Interoperability of private keys does matter.  Key escrow of those private
(encryption) keys does matter - so that they can be imported into whatever
MUA you need.  (where you store the keys on that device is a whole other
conversation).

PKCS#8 will do, as long as the MUA/device/whatever can match up the
certificate w/ the key (sometimes not entirely trivial).

As far as signature keys/certs go - feel free to get a new key for every
device, no problem...

Deb Cooley
[email-masked]

On Thu, Aug 5, 2021 at 12:32 PM Carl Wallace <[email-masked]>
wrote:

> key per person. Amongst the keys messages for you are encrypted could be
> the key that you printed out, for example. I am not suggesting we’d not
> benefit from improved private key formats, but am suggesting we may be able
> to do better than slinging private keys around in some cases.
>
>
>
>
>

---

From: Carl Wallace <[email-masked]>
Date: Thu, 12 Aug 2021 07:19:08 -0400

Inline…

Hold on a minute.  All fine and good to say that 'a message be encrypted for each of your end points', but how does the RP get the public key for all of those end points?  

[CW] Therein lies the work to do.

not like we have a directory or anything. Do you want a signed message from each end point?  Who is going to do that? 

[CW] No, I don’t want a signed message from each end point nor is a signed message necessary, only the certs.

It won't work.  

[CW] This seems premature given “it” is not defined, but if the problem isn’t of interest as a pursuit right now that’s fine.

If the big directory in the sky had panned out, then one could push all the public keys you wanted to your directory entry.  A RP could encrypt to you including all of your encryption keys.  Is there another way?

[CW] I can have a mail server send an out of office note. Why can’t I have a mail server send a set of keys? Maybe for some well-known + appendage, as an example. I don’t know, as I am not saying I have a fleshed out an answer. 

Interoperability of private keys does matter.  

[CW] I did not say interoperability of private keys does not matter and I certainly have no beef with improving or replacing PKCS12. I only questioned why we were focusing exclusively on slinging around private keys and not on a way to avoid the need to do so especially with good hardware crypto modules available to most folks now. 

Key escrow of those private (encryption) keys does matter - so that they can be imported into whatever MUA you need.  (where you store the keys on that device is a whole other conversation).

[CW] I am not sure if escrow of all encryption keys matters or if it only matters that messages are encrypted for a key that is escrowed. Maybe the escrowed key isn’t on any end point that I use but simply corresponds to another key in the set of keys that should be used when encrypting for me.

PKCS#8 will do, as long as the MUA/device/whatever can match up the certificate w/ the key (sometimes not entirely trivial).

As far as signature keys/certs go - feel free to get a new key for every device, no problem... 

[CW] Of course, so can we get there for encryption too? Ultimately, I’d like to copy/export private keys around less and use end-to-end encryption more and this thread was in the general neighborhood of those two aims, hence my comment.

Deb Cooley

[email-masked]

On Thu, Aug 5, 2021 at 12:32 PM Carl Wallace <[email-masked]> wrote:

<snip>

---

From: Deb Cooley <[email-masked]>
Date: Thu, 12 Aug 2021 19:28:55 -0400

Those are fair points.  I made assumptions and you know what they say...

Perhaps I'm not creative enough to see how it would/could work.  Wouldn't
be the first time.  LOL

Deb
[email-masked]

On Thu, Aug 12, 2021 at 7:19 AM Carl Wallace <[email-masked]>
wrote:

> all of those end points?
> not like we have a directory or anything. Do you want a signed message
> from each end point?  Who is going to do that?
>
> [CW] This seems premature given “it” is not defined, but if the problem
> isn’t of interest as a pursuit right now that’s fine.
>
>
>
> If the big directory in the sky had panned out, then one could push all
> the public keys you wanted to your directory entry.  A RP could encrypt to
> you including all of your encryption keys.  Is there another way?
>
> [CW] I can have a mail server send an out of office note. Why can’t I have
> a mail server send a set of keys? Maybe for some well-known + appendage, as
> an example. I don’t know, as I am not saying I have a fleshed out an
> answer.
>
>
>
> [CW] I did not say interoperability of private keys does not matter and I
> certainly have no beef with improving or replacing PKCS12. I only
> questioned why we were focusing exclusively on slinging around private keys
> and not on a way to avoid the need to do so especially with good hardware
> crypto modules available to most folks now.
>
>
>
> Key escrow of those private (encryption) keys does matter - so that they
> can be imported into whatever MUA you need.  (where you store the keys on
> that device is a whole other conversation).
>
> [CW] I am not sure if escrow of all encryption keys matters or if it only
> matters that messages are encrypted for a key that is escrowed. Maybe the
> escrowed key isn’t on any end point that I use but simply corresponds to
> another key in the set of keys that should be used when encrypting for me.
>
>
>
> [CW] Of course, so can we get there for encryption too? Ultimately, I’d
> like to copy/export private keys around less and use end-to-end encryption
> more and this thread was in the general neighborhood of those two aims,
> hence my comment.
>
>
>
> Deb Cooley
>
> [email-masked]
>
>
>
>
>

---

From: Russ Housley <[email-masked]>
Date: Sat, 14 Aug 2021 17:39:10 -0400

> On Aug 12, 2021, at 6:11 AM, Deb Cooley <[email-masked]> wrote:
> 
The updated PKCS#8 syntax (see RFC 5958) now allows the certificate to be included with the private key.

Russ

---

From: Dmitry Belyavsky <[email-masked]>
Date: Sat, 14 Aug 2021 23:50:30 +0200

> included with the private key.

This syntax is not supported by e.g. OpenSSL.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 13 Aug 2021 12:13:07 -0400

On Thu 2021-08-12 07:19:08 -0400, Carl Wallace wrote:
> [CW] I can have a mail server send an out of office note. Why can’t I
> have a mail server send a set of keys? Maybe for some well-known +
> appendage, as an example. I don’t know, as I am not saying I have a
> fleshed out an answer.

Four years ago, the IETF specified RFC 8162 as an experiment in
distributing S/MIME certificates via the DNS using the SMIMEA RR
type. The value of an SMIMEA record is a structure identical to TLSA
records.  The RFC explicitly references §2.1 of RFC 6698 for the wire
format, despite the fact the definitions in that section of 6698 have
multiple references to "the end entity certificate given by the server",
which doesn't make sense in the context of S/MIME.  But hopefully some
S/MIME implementers have figured out what it's supposed to mean?  8162
does some handwaving around that requirement, and also seems to treat
the DNS record as a way to *confirm* a peer's cert as received from
another MUA.  But of course it could also be used as a way to advertise
S/MIME certs for a peer in advance of contacting them.

If used for the purposes of certificate advertising, it seems critical
that the SMIMEA records all use selector 0 (full X.509 certificate),
because without the keyUsage and extendedKeyUsage markers are necessary
to know how to apply the keys.  SPKI alone *might* be sufficient to
distinguish CFRG curves (e.g. OBJECT IDENTIFIER curveEd25519 (1 3 101
112) for signing vs OBJECT IDENTIFIER curveX25519 (1 3 101 110) for
encryption) but for EC and RSA, you'd definitely need the full cert.

Each SMIMEA record distributes at most a single certificate (selector 0)
or SPKI (selector 1). To distribute a set of S/MIME certificates for a
given address via the DNS, you'd need to publish multiple SMIMEA records
for a given address.

This is necessary for the expected case of two certs per user anyway
(one for signing and one for encryption), and seems simple to extend to
multiple certs for encryption, *but* implementers would need to
understand that they should encrypt to both certificates instead of
choosing one.

Has anyone done any work with this experiment (or with other
experiments) to see how existing S/MIME implementations deal with
sending a message in the face of multiple encryption-capable keys for
the intended user?

This is an interesting line of inquiry, but unless we can show some
clear, obvious (and surprising!) already-implemented wins here, i don't
think it's a plausible replacement for standardized interoperable
private keys in the near term.

         --dkg