Subject: [lamps] header-protection test vectors: should they include intermediate CA?

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 May 2021 18:00:26 -0400

Hey LAMPS folks--

An open question about the test vectors for
draft-ietf-lamps-header-protection:

The sample messages all include the signer's signing certificate and
encryption certificate.  They do *not* include the issuing authority's
root certificate (ca.rsa.crt) or the cross-signed cert
(ca.rsa.cross.crt) that would allow the end-entity certificates to be
validated by an different authority.

I don't think it makes any sense to include ca.rsa.crt in the messages
-- if the peer doesn't know about that certificate already, then it
won't trust it.  But ca.rsa.cross.crt is potentially useful for building
a path to a different known, trusted root.

This is similar in some sense to the question about what CA
certificate(s) to include in the PKCS#12 objects from
draft-ietf-lamps-samples, but now i'm asking it about PKCS#7 CMS blobs.

In draft-ietf-lamps-header-protection-04, no intermediate certificates
are included in the PKCS#7.

I'm considering adding ca.rsa.cross.crt to the PKCS#7 blobs for -05.

This will increase the size of the draft but not the complexity of it.
Any objections to this proposal?  Any counterproposals?

   --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 27 May 2021 20:08:45 -0400

> a path to a different known, trusted root.

There is a slight benefit, although in the context of S/MIME and CMS, it's
far more esoteric, particularly for S/MIME.

To use Windows as an example, Windows has a built-in root store (generally,
stored as a resource within crypt32.dll as a CMS message), and has the
ability to update that root store (known as "AuthRoot"). The auto-update
mechanism is via delivery of a PKCS#7 message that has a list of root
hashes and attributes that affect the trust of the associated certificate
(such as trust purposes or restrictions), as well as an encoded version of
the issuer name. Notably, however, this file does not contain all the root
certificates themselves.

If Windows isn't able to find the encoded issuer name and the issuer hash,
it will attempt to download the full certificate from Microsoft's CDN, in
order to complete the chain verification (it includes the root certificate
as part of the chain for purposes such as viewing certificates). It also
applies restrictions-from-extensions in that certificate (unless the
extensions were overridden by AuthRoot).

The mechanism for getting an AuthRoot update can differ from the mechanism
of fetching the certificate (I'm heavily handwaving the details here;
process impersonation tokens re: LSASS factor in here, as well as the
complexity of WinHTTP proxy settings for the invoking process). The net
result is you can have a current AuthRoot update, but be lacking the
associated certificate with the trust anchor, and this can cause validation
to fail, even if you might otherwise "trust" the certificate.

For something like TLS, the risk/benefits here are generally such that
including the root is a waste of bytes, because you're in an online system
doing online negotiation. It *can* fail, and we do see failures from users
(interestingly, particularly with respect to India and Brazil, for reasons
I can only speculate about) that can be traced to "AuthRoot  failing to
update/fetch the cert". However, for something like CMS or S/MIME, in which
you may actively be offline when attempting to perform the verification of
the signed artifact, it may have some benefit to including.

Obviously, this is a trade-off of artifacts, and depends on the nature and
implementation of your relying parties. Certainly, if your PKI is assuming
that the client must check revocation (a generally unreliable assumption,
but one frequently made nonetheless), you may find yourself going through
those same networking paths in CryptNet on Windows, and so you're doomed
either way. But if you're trying to enable a fully offline verification,
there may be some slight benefit to the inclusion.  Even outside of
Window's systems, the inclusion or omission can improve or harm path
building characteristics (e.g. avoiding a lookup on a slow medium, such as
spindle-disk, if your network is fast-cheap)

This is certainly one of the complexities of certificate-using-systems, and
whether or not to omit everything, something, or nothing, depends on a
number of variables regarding your client/RP assumptions, both now and
future. I think your gut instinct re: root is reasonably justified, but I
also think including it (and other paths) could also be reasonably
justified. I don't think your work necessarily needs to capture all of this
nuance and complexity, and this was just one RP example. So I think you're
fine "either way", and can make a judgement call mostly based on how much
complexity you want to deal with.

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 27 May 2021 21:15:58 -0400

Hi Ryan--

> far more esoteric, particularly for S/MIME.

Thanks for the detailed breakdown of the processing, update, and
verification model used by Windows.  fwiw, i'm not expecting that any
MUA receiving these messages would even consider updating their stance
toward what roots are trusted just to process the message -- that would
be a strange (and dangerous) tradeoff.

From the sender's perspective, whether the receiving party has a known
set of trusted roots, or a subscription to a service (like "AuthRoot")
that provides just-in-time delivery of system-trusted roots seems
basically indistinguishable to the sender.

So, I don't see anything in your description that gives me any reason to
think i should ship any root certificates in the PKCS#7 bundle.  The
draft won't do that unless someone else on the list presents a strong
counterargument for doing so.

Given that we don't know who the relying party is going to be, though,
and it's not always clear even to the microsoft CDN how to find a
particular intermediate cert, i don't think this analysis lands on the
same conclusion for shipping the certificate of an intermediate CA,
which is what i was proposing.

So far, it looks like the next draft (-06) *will* go ahead and ship the
cross-signed intermediate cert, so that any receiving party that is
already willing to rely on either of the two example root CAs can
validate the message without needing to chase down any intermediate
cert.

I hope folks will speak up here on the list if they think this is a bad
idea!

        --dkg

---

From: Russ Housley <[email-masked]>
Date: Fri, 28 May 2021 08:47:30 -0400

I agree.  RFC 5652 says:

      certificates is a collection of certificates.  It is intended that
      the set of certificates be sufficient to contain certification
      paths from a recognized "root" or "top-level certification
      authority" to all of the signers in the signerInfos field.  There
      may be more certificates than necessary, and there may be
      certificates sufficient to contain certification paths from two or
      more independent top-level certification authorities.  There may
      also be fewer certificates than necessary, if it is expected that
      recipients have an alternate means of obtaining necessary
      certificates (e.g., from a previous set of certificates).  The
      signer's certificate MAY be included.  The use of version 1
      attribute certificates is strongly discouraged.

To me, that says that trust anchors are not carried in the message.

Russ

> On May 27, 2021, at 6:00 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 
> Signed PGP part
> Hey LAMPS folks--
>