Subject: Re: [Acme] Registering a PEM Content-Type

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sun, 12 Mar 2017 12:35:50 -0700

I've got a PR adding application/pem-certificate-chain:
https://github.com/ietf-wg-acme/acme/pull/276.

Note that I chose "pem-certificate-chain" rather than "pem-cert-list",
because it has different semantics. A certificate chain MUST start with
an end-entity certificate, while a certificate list (which has no MIME
type defined at present) can have any type of certificates in any order.
For instance, it's common to have a list of trust anchors in PEM format
concatenated in a single file. That would be considered a "certificate
list" but not a "certificate chain."

What do you all think?

Thanks,
Jacob

On 02/16/2017 06:57 PM, Clint Wilson wrote:
>
> +1 for application/pem-cert-list.
>
>
> On Thu, Feb 16, 2017, 5:11 PM Salz, Rich <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I think you need application/pem-cert-list, which is a collection
>     of PEM certificates as defined in RFC 7468.
>
>     Should be easy to add that as an appendix to the draft.
>
>     I suggest cert-list not chain, to show that no ordering is implied.
>
>     _______________________________________________
>     Acme mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/acme
>
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 12 Mar 2017 19:50:40 +0000

What about saying each certificate SHOULD be a signer on *A* preceding certificate?  This allows us to serve a single cert chain for both MD5  and SHA1, for example.  (Contrived examples of course.)

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Sun, 12 Mar 2017 12:54:25 -0700

> What about saying each certificate SHOULD be a signer on *A* preceding certificate?  This allows us to serve a single cert chain for both MD5  and SHA1, for example.  (Contrived examples of course.)
I think the current language (copied from TLS 1.3) conveys that, though
it's a bit subtle:

> Each following certificate SHOULD directly certify one preceding it.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Mar 2017 14:19:28 -0700

On Sun, Mar 12, 2017 at 12:54 PM, Jacob Hoffman-Andrews <[email-masked]>
wrote:

> > What about saying each certificate SHOULD be a signer on *A* preceding
> certificate?  This allows us to serve a single cert chain for both MD5  and
> SHA1, for example.  (Contrived examples of course.)

Note: this used to be a MUST-level requirement, but due to the complexities
of the deployed
PKI, in 1.3 it was relaxed to be a SHOULD.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 12 Mar 2017 22:46:05 +0000

> > Each following certificate SHOULD directly certify one preceding it.

Okay.  Overly terse but fine.:)