Subject: [lamps] draft-ietf-lamps-samples: what certs should go in the PKCS#12 objects?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 14 May 2021 19:34:21 -0400

Hi LAMPS people--

One outstanding question I have for the WG about
draft-ietf-lamps-samples is what CA certificates should be included in
the PKCS#12 objects.

Alice and Bob's certs are certified by the RSA CA, and Carlos and Dana's
certs are certified by the Ed25519 CA.

Both sample CAs now cross-certify each other, so there are four CA
certificates:

  ca.rsa.crt (a self-signed root cert)
  ca.25519.crt (a self-signed root cert)
  ca.rsa.cross.crt (intermediate, issued by the Ed25519 CA)
  ca.25519.cross.crt (intermediate, issued by the RSA CA)

Which CA certificate(s) belong in the PKCS#12 objects for Alice, Bob,
Carlos, and Dana?

Why do we include CA certificate(s) in the PKCS#12 bundle?  I see at
least two possible reasons:

 a) help the bundle owner load a root CA cert that they should trust,
    because it is "their" CA.

 b) provide intermediate CA cert(s) that will help the bundle's owner's
    peers with path building to validate the owner's certs.

draft -03 (as with all previous drafts) sort of implies that (a) is the
reason (e.g. Alice's PKCS#12 ships with ca.rsa.crt, Carlos's ships
ca.25519.crt).  But as i write this message, i think (b) is more
plausible (e.g., maybe Alice's should ship ca.rsa.cross.crt instead).

Or, maybe both (a) and (b) are valid reasons and we should include both
certs?  Or maybe there are other reasons?

RFC 7292 doesn't offer much guidance on what *should* go into one of
these files that i could see.

Alternately, perhaps draft-ietf-lamps-samples should just drop the
PKCS#12 objects entirely?

I included them because i found a few MUAs and S/MIME utilities that
preferred to *only* load secret keys from in that format, and i thought
having a canonical, WG-reviewed PKCS#12 bundle for use with S/MIME would
help flush out bugs in that tooling (indeed, i found
https://dev.gnupg.org/T5407 while working on it).  I currently think
they're useful, but if the WG forms a consensus to drop them, i'll
follow the group.

          --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 18 May 2021 17:31:55 -0400

> plausible (e.g., maybe Alice's should ship ca.rsa.cross.crt instead).

Hearing no feedback from the otherwise-active WG on this question, I'm
going with my instincts about (b) -- i'll put the
intermediate/cross-signed CA certs into the PKCS#12 bundles for revision
-04 of the draft instead of the root/self-signed CA certs.

If anyone has any objections to this, or an argument about some
alternate way to structure the PKCS#12 objects in the draft, please
speak up!

        --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 18 May 2021 16:30:44 -0600

> alternate way to structure the PKCS#12 objects in the draft, please

Apologies for the silence. The answer is largely (b).

In theory, the implementation will consult the available certificates to
assist in chain building, although this is definitely a comparability gap
that CAs have flagged in the past: that implementations such as S/MIME
don’t robustly implement path building in the style of RFC 4158.

Ultimately, implementations (both sender and receiver) shouldn’t assume
that all the necessary certificates are in the bundle, because the valid
path(s) can change over time (as old roots/intermediates expire and new
versions/trust anchors are introduced). However, including all
(potentially) relevant certificates can help optimize verification, so it’s
a good to do.

(A) is sometimes relevant when there isn’t a pre-existing trust
relationship, and the email itself introduces the trust framework, but that
model is fairly rare, simply because constraining that introduced trust
anchor is quite complex (are you introducing a TA for just that email
address? For all mailboxes at that domain? For that domain namespace?)
Obviously, such situations are basically TOFU and thus have all the usual
risks, but some systems do practice it. However, (b) is the dominant use
case.