[TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[David Benjamin]

Hi all,

We just published a document on certificate negotiation. It's a TLS
extension, which allows the client to communicate which trust anchors it
supports, primarily focused on use cases like the Web PKI where trust
stores are fairly large. There is also a supporting ACME extension, to
allow CAs to provision multiple certificate chains on a server, with enough
metadata to match against what the client sends. (It also works in the
other direction for client certificates.)

The hope is this can build towards a more agile and flexible PKI. In
particular, the Use Cases section of the document details some scenarios
(e.g. root rotation) that can be made much more robust with it.

It's very much a draft-00, but we're eager to hear your thoughts on it!

David, Devon, and Bob

-- Forwarded message -
From: 
Date: Thu, Oct 19, 2023 at 11:36 AM
Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt
To: Bob Beck , David Benjamin , Devon
O'Brien 


A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has
been
successfully submitted by David Benjamin and posted to the
IETF repository.

Name: draft-davidben-tls-trust-expr
Revision: 00
Title:TLS Trust Expressions
Date: 2023-10-19
Group:Individual Submission
Pages:35
URL:
https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt
Status:   https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
HTML:
https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr


Abstract:

   This document defines TLS trust expressions, a mechanism for relying
   parties to succinctly convey trusted certification authorities to
   subscribers by referencing named and versioned trust stores.  It also
   defines supporting mechanisms for subscribers to evaluate these trust
   expressions, and select one of several available certification paths
   to present.  This enables a multi-certificate deployment model, for a
   more agile and flexible PKI that can better meet security
   requirements.



The IETF Secretariat
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Ilari Liusvaara]

On Thu, Oct 19, 2023 at 11:38:33AM -0400, David Benjamin wrote:
> Hi all,
> 
> We just published a document on certificate negotiation. It's a TLS
> extension, which allows the client to communicate which trust anchors it
> supports, primarily focused on use cases like the Web PKI where trust
> stores are fairly large. There is also a supporting ACME extension, to
> allow CAs to provision multiple certificate chains on a server, with enough
> metadata to match against what the client sends. (It also works in the
> other direction for client certificates.)
> 
> The hope is this can build towards a more agile and flexible PKI. In
> particular, the Use Cases section of the document details some scenarios
> (e.g. root rotation) that can be made much more robust with it.
> 
> It's very much a draft-00, but we're eager to hear your thoughts on it!

Some quick thoughts:

- The multiple certificates from one ACME order really scares me. It
  seems to me that can lead to all sorts of trouble.
- If there can be only one certificate, one could send all the chains
  in one go via fist sending the certificate, then issuer chains each
  ended by entry describing the trust anchor.
- The latest version and previous version stuff seems pretty confusing
  to me.
- I am not sure this is useful for the client->server direction.



What I think is a simpler version that might work:


Information from root program to CA:

- Root program name.
- For each trust anchor:
  * Trust anchor certificate.
  * First version TA appeared in.
  * Expiry time
  * List of indices.

Indices can be reused after all TAs using those have expired.


Information from CA to TLS server for each TA:

- For each root program:
  * Root program name
  * The first version TA appeared in.
  * List of indices.

CA MUST NOT include entries that expire before the certificate.


Information from TLS client to TLS server:

- Root program name.
- Root program version.
- List of revoked indices.

The revoked indices specifies TAs that have been recently removed
before expiry (there could still be unexpired certificates out
there).


Chain is usable if it includes an entry where:
 
a) Root program name matches, AND
b) Root program version is at least the first version, AND
c) Intersection of indices and revoked indices is empty.

If TLS server has multiple configured certificates, it should skip ones
that have no usable chains. If no certificate has usable chain, it
should act like the extension was not sent.



> -- Forwarded message -
> From: 
> Date: Thu, Oct 19, 2023 at 11:36 AM
> Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt
> To: Bob Beck , David Benjamin , Devon
> O'Brien 
> 
> Name: draft-davidben-tls-trust-expr
> Revision: 00
> Title:TLS Trust Expressions
> Date: 2023-10-19
> Group:Individual Submission
> Pages:35
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
> HTML:
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr
 



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Colm MacCárthaigh]

This is very awesome. Just some quick thoughts:

This extension seems very useful in internal environments with their
own proprietary PKI. The first bullet in the intro does get at this,
but I think it still undersells just how compelling this extension
would be. FSIs/Banks, Governments, technology companies often have CAs
with validities in short durations and have to perform rotations very
often. This extension makes that so much more manageable and safer.  I
think there's a strong internet stability argument here ... many large
outages of organizations have been caused by mishandling these
rotations.

In the security / privacy considerations:   1.  Since this extension
can appear in the CH in the clear, should we consider the case where
network operators may use it to "enforce" support of particular trust
anchors? For example, a firewall may reject connections based on
anchors that do or don't support.  and 2. Is this another fingerprint,
at least at system level?  For example; corporate user's whose
organizations who add their own TAs may become finger-printable as
coming from those organizations.

Why sort TrustStores first by name-length, and then lexicographically?
Just seems a little unnecessarily complex and unfriendly to indices.





On Thu, Oct 19, 2023 at 8:38 AM David Benjamin  wrote:
>
> Hi all,
>
> We just published a document on certificate negotiation. It's a TLS 
> extension, which allows the client to communicate which trust anchors it 
> supports, primarily focused on use cases like the Web PKI where trust stores 
> are fairly large. There is also a supporting ACME extension, to allow CAs to 
> provision multiple certificate chains on a server, with enough metadata to 
> match against what the client sends. (It also works in the other direction 
> for client certificates.)
>
> The hope is this can build towards a more agile and flexible PKI. In 
> particular, the Use Cases section of the document details some scenarios 
> (e.g. root rotation) that can be made much more robust with it.
>
> It's very much a draft-00, but we're eager to hear your thoughts on it!
>
> David, Devon, and Bob
>
> -- Forwarded message -
> From: 
> Date: Thu, Oct 19, 2023 at 11:36 AM
> Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt
> To: Bob Beck , David Benjamin , Devon 
> O'Brien 
>
>
> A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has been
> successfully submitted by David Benjamin and posted to the
> IETF repository.
>
> Name: draft-davidben-tls-trust-expr
> Revision: 00
> Title:TLS Trust Expressions
> Date: 2023-10-19
> Group:Individual Submission
> Pages:35
> URL:  https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
> HTML: 
> https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr
>
>
> Abstract:
>
>This document defines TLS trust expressions, a mechanism for relying
>parties to succinctly convey trusted certification authorities to
>subscribers by referencing named and versioned trust stores.  It also
>defines supporting mechanisms for subscribers to evaluate these trust
>expressions, and select one of several available certification paths
>to present.  This enables a multi-certificate deployment model, for a
>more agile and flexible PKI that can better meet security
>requirements.
>
>
>
> The IETF Secretariat
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--
Colm

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[David Benjamin]

Thanks for the comments! Responses inline.

On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara 
wrote:

> Some quick thoughts:
>
> - The multiple certificates from one ACME order really scares me. It
>   seems to me that can lead to all sorts of trouble.
>

Certainly open to different mechanisms, though could you elaborate on
the trouble? We started with this one because it's actually just fixing a
mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit:

   The server MAY provide one or more link relation header fields
   [RFC8288] with relation "alternate".  Each such field SHOULD express
   an alternative certificate chain starting with the same end-entity
   certificate.  This can be used to express paths to various trust
   anchors.  Clients can fetch these alternates and use their own
   heuristics to decide which is optimal.

https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2

Whether anyone has ever used this, I don't know. The "and use their own
heuristics to decide which is optimal" bit is quite absurd. :-) Relative to
that, all we've done is:

- Go ahead and define some format for a chain + properties... I like PEM
much, but hey if ACME does that, we can just mimick that.
- Fix the heuristic. You don't need heuristics when you have robust
negotiation.

But I suspect we'll want to define one where you make multiple orders too.
That would probably work better for, e.g., Merkle Tree certs where the two
issuances complete at very different times. But then, conversely, when the
two paths actually share an end-entity certificate, I imagine a single
order would be better so the CA knows it only needs to generate one
signature. And then when they don't share an end-entity certificate but are
similar enough in lifetime and issuance time, either seems fine, so we
figured this was a reasonable starting point.


> - If there can be only one certificate, one could send all the chains
>   in one go via fist sending the certificate, then issuer chains each
>   ended by entry describing the trust anchor.
>

I'm not quite sure if I've parsed this right, but are you thinking of one
file that somehow describes all alternatives together? That's plausible
too. Like I said, we mostly did this one because ACME already did it, so we
inferred that was The ACME Way. :-)


> - The latest version and previous version stuff seems pretty confusing
>   to me.
>

Yeah, it took us many iterations to find a good way to describe it, and I'm
sure we haven't gotten it right yet. It's all to deal with version skew
cleanly, when the relying party references a newer trust store than what
the subscriber knew about at the time the certificate was issued. Since it
seems your suggestion below relates to this, maybe some of the discussion
below will help us clear it up and get to a better description?


> - I am not sure this is useful for the client->server direction.
>

Eh, it costs ~nothing to define it in both directions, just a global
s/client/relying party/ and s/server/subscriber/ across the document. :-) I
figure we may as well define it in both directions, and if some client
certificate deployments find it useful, cool. On the Chrome side, if the
operating systems could give us something like this, with pre-made paths
and unambiguous rules for when to send each, I would be overjoyed. We spend
quite a lot of time helping people debug misconfigurations and quirks
around client certificate selection.


> What I think is a simpler version that might work:
>
>
> Information from root program to CA:
>
> - Root program name.
> - For each trust anchor:
>   * Trust anchor certificate.
>   * First version TA appeared in.
>   * Expiry time
>   * List of indices.
>
> Indices can be reused after all TAs using those have expired.
>
>
> Information from CA to TLS server for each TA:
>
> - For each root program:
>   * Root program name
>   * The first version TA appeared in.
>   * List of indices.
>
> CA MUST NOT include entries that expire before the certificate.
>
>
> Information from TLS client to TLS server:
>
> - Root program name.
> - Root program version.
> - List of revoked indices.
>
> The revoked indices specifies TAs that have been recently removed
> before expiry (there could still be unexpired certificates out
> there).
>
>
> Chain is usable if it includes an entry where:
>
> a) Root program name matches, AND
> b) Root program version is at least the first version, AND
> c) Intersection of indices and revoked indices is empty.
>
> If TLS server has multiple configured certificates, it should skip ones
> that have no usable chains. If no certificate has usable chain, it
> should act like the extension was not sent.
>

If I'm parsing this right, I think the main issue here is this presumes a
removed CA will stop issuing certificates:

Suppose some CA is in v2 and then was removed in v3. We need to ensure
certificates issued by that CA don't match a v3 client, so the server will
send a different one. Immediately after removal, 

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[David Benjamin]

On Fri, Oct 20, 2023 at 4:07 PM David Benjamin 
wrote:

> Thanks for the comments! Responses inline.
>
> On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara 
> wrote:
>
>> Some quick thoughts:
>>
>> - The multiple certificates from one ACME order really scares me. It
>>   seems to me that can lead to all sorts of trouble.
>>
>
> Certainly open to different mechanisms, though could you elaborate on
> the trouble? We started with this one because it's actually just fixing a
> mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit:
>
>The server MAY provide one or more link relation header fields
>[RFC8288] with relation "alternate".  Each such field SHOULD express
>an alternative certificate chain starting with the same end-entity
>certificate.  This can be used to express paths to various trust
>anchors.  Clients can fetch these alternates and use their own
>heuristics to decide which is optimal.
>
> https://datatracker.ietf.org/doc/html/rfc8555#section-7.4.2
>
> Whether anyone has ever used this, I don't know. The "and use their own
> heuristics to decide which is optimal" bit is quite absurd. :-) Relative to
> that, all we've done is:
>
> - Go ahead and define some format for a chain + properties... I like PEM
> much, but hey if ACME does that, we can just mimick that.
>

Sorry, I meant to write "I *don't* like PEM much". :-)


> - Fix the heuristic. You don't need heuristics when you have robust
> negotiation.
>
> But I suspect we'll want to define one where you make multiple orders too.
> That would probably work better for, e.g., Merkle Tree certs where the two
> issuances complete at very different times. But then, conversely, when the
> two paths actually share an end-entity certificate, I imagine a single
> order would be better so the CA knows it only needs to generate one
> signature. And then when they don't share an end-entity certificate but are
> similar enough in lifetime and issuance time, either seems fine, so we
> figured this was a reasonable starting point.
>
>
>> - If there can be only one certificate, one could send all the chains
>>   in one go via fist sending the certificate, then issuer chains each
>>   ended by entry describing the trust anchor.
>>
>
> I'm not quite sure if I've parsed this right, but are you thinking of one
> file that somehow describes all alternatives together? That's plausible
> too. Like I said, we mostly did this one because ACME already did it, so we
> inferred that was The ACME Way. :-)
>
>
>> - The latest version and previous version stuff seems pretty confusing
>>   to me.
>>
>
> Yeah, it took us many iterations to find a good way to describe it, and
> I'm sure we haven't gotten it right yet. It's all to deal with version skew
> cleanly, when the relying party references a newer trust store than what
> the subscriber knew about at the time the certificate was issued. Since it
> seems your suggestion below relates to this, maybe some of the discussion
> below will help us clear it up and get to a better description?
>
>
>> - I am not sure this is useful for the client->server direction.
>>
>
> Eh, it costs ~nothing to define it in both directions, just a global
> s/client/relying party/ and s/server/subscriber/ across the document. :-) I
> figure we may as well define it in both directions, and if some client
> certificate deployments find it useful, cool. On the Chrome side, if the
> operating systems could give us something like this, with pre-made paths
> and unambiguous rules for when to send each, I would be overjoyed. We spend
> quite a lot of time helping people debug misconfigurations and quirks
> around client certificate selection.
>
>
>> What I think is a simpler version that might work:
>>
>>
>> Information from root program to CA:
>>
>> - Root program name.
>> - For each trust anchor:
>>   * Trust anchor certificate.
>>   * First version TA appeared in.
>>   * Expiry time
>>   * List of indices.
>>
>> Indices can be reused after all TAs using those have expired.
>>
>>
>> Information from CA to TLS server for each TA:
>>
>> - For each root program:
>>   * Root program name
>>   * The first version TA appeared in.
>>   * List of indices.
>>
>> CA MUST NOT include entries that expire before the certificate.
>>
>>
>> Information from TLS client to TLS server:
>>
>> - Root program name.
>> - Root program version.
>> - List of revoked indices.
>>
>> The revoked indices specifies TAs that have been recently removed
>> before expiry (there could still be unexpired certificates out
>> there).
>>
>>
>> Chain is usable if it includes an entry where:
>>
>> a) Root program name matches, AND
>> b) Root program version is at least the first version, AND
>> c) Intersection of indices and revoked indices is empty.
>>
>> If TLS server has multiple configured certificates, it should skip ones
>> that have no usable chains. If no certificate has usable chain, it
>> should act like the extension was not sent.
>>
>
> If I'm parsing this rig

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Ilari Liusvaara]

On Fri, Oct 20, 2023 at 04:07:21PM -0400, David Benjamin wrote:
> Thanks for the comments! Responses inline.
> 
> On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara 
> wrote:
> 
> > Some quick thoughts:
> >
> > - The multiple certificates from one ACME order really scares me. It
> >   seems to me that can lead to all sorts of trouble.
> >
> 
> Certainly open to different mechanisms, though could you elaborate on
> the trouble? We started with this one because it's actually just fixing a
> mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit:
>
>The server MAY provide one or more link relation header fields
>[RFC8288] with relation "alternate".  Each such field SHOULD express
>an alternative certificate chain starting with the same end-entity
>certificate.  This can be used to express paths to various trust
>anchors.  Clients can fetch these alternates and use their own
>heuristics to decide which is optimal.

Note the part "the same end-entity certificate.". The way I interpretted
the draft, returning different end-entity certificates would be allowed.


> Whether anyone has ever used this, I don't know. The "and use their own
> heuristics to decide which is optimal" bit is quite absurd. :-) Relative to
> that, all we've done is:

Yes, that gets sometimes used.


> But I suspect we'll want to define one where you make multiple orders too.
> That would probably work better for, e.g., Merkle Tree certs where the two
> issuances complete at very different times. But then, conversely, when the
> two paths actually share an end-entity certificate, I imagine a single
> order would be better so the CA knows it only needs to generate one
> signature. And then when they don't share an end-entity certificate but are
> similar enough in lifetime and issuance time, either seems fine, so we
> figured this was a reasonable starting point.

Well, I do not think it is feasible to use the normal ACME issuance
mechanism for Merkle Tree certificates. The issuance is just too slow.

And things like ACME ARI (which is required for actually handling
revocations) inherently assume each order can only result one 
certificate.
 
 
> > - If there can be only one certificate, one could send all the chains
> >   in one go via fist sending the certificate, then issuer chains each
> >   ended by entry describing the trust anchor.
> >
> 
> I'm not quite sure if I've parsed this right, but are you thinking of one
> file that somehow describes all alternatives together? That's plausible
> too. Like I said, we mostly did this one because ACME already did it, so we
> inferred that was The ACME Way. :-)

Yes, one file describing all alternatives together. I think that is
easier to work with than the existing alternatives mechanism (I don't
think most clients even support that).


> > - I am not sure this is useful for the client->server direction.
> >
> 
> Eh, it costs ~nothing to define it in both directions, just a global
> s/client/relying party/ and s/server/subscriber/ across the document. :-) I
> figure we may as well define it in both directions, and if some client
> certificate deployments find it useful, cool. On the Chrome side, if the
> operating systems could give us something like this, with pre-made paths
> and unambiguous rules for when to send each, I would be overjoyed. We spend
> quite a lot of time helping people debug misconfigurations and quirks
> around client certificate selection.

How useful it is is different from how difficult it is to specify. :-)


> > What I think is a simpler version that might work:
> >
> >
> > Information from root program to CA:
> >
> > - Root program name.
> > - For each trust anchor:
> >   * Trust anchor certificate.
> >   * First version TA appeared in.
> >   * Expiry time
> >   * List of indices.
> >
> > Indices can be reused after all TAs using those have expired.
> >
> >
> > Information from CA to TLS server for each TA:
> >
> > - For each root program:
> >   * Root program name
> >   * The first version TA appeared in.
> >   * List of indices.
> >
> > CA MUST NOT include entries that expire before the certificate.
> >
> >
> > Information from TLS client to TLS server:
> >
> > - Root program name.
> > - Root program version.
> > - List of revoked indices.
> >
> > The revoked indices specifies TAs that have been recently removed
> > before expiry (there could still be unexpired certificates out
> > there).
> >
> >
> > Chain is usable if it includes an entry where:
> >
> > a) Root program name matches, AND
> > b) Root program version is at least the first version, AND
> > c) Intersection of indices and revoked indices is empty.
> >
> > If TLS server has multiple configured certificates, it should skip ones
> > that have no usable chains. If no certificate has usable chain, it
> > should act like the extension was not sent.
> >
> 
> If I'm parsing this right, I think the main issue here is this presumes a
> removed CA will stop issuing certificates:
> 
> Suppose

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[David Benjamin]

On Fri, Oct 20, 2023 at 2:15 PM Colm MacCárthaigh  wrote:

> This is very awesome. Just some quick thoughts:
>
> This extension seems very useful in internal environments with their
> own proprietary PKI. The first bullet in the intro does get at this,
> but I think it still undersells just how compelling this extension
> would be. FSIs/Banks, Governments, technology companies often have CAs
> with validities in short durations and have to perform rotations very
> often. This extension makes that so much more manageable and safer.  I
> think there's a strong internet stability argument here ... many large
> outages of organizations have been caused by mishandling these
> rotations.
>

Yeah, my colleagues on the server end have had their share of nightmares
dealing with certificate transitions on Google properties. We like to talk
about PKIs as if they're these big, consistent things, but once you
actually get down to it, this fiction breaks down very fast. Relying
parties vary a bit, and we should take that into account when designing
systems.


> In the security / privacy considerations:   1.  Since this extension
> can appear in the CH in the clear, should we consider the case where
> network operators may use it to "enforce" support of particular trust
> anchors? For example, a firewall may reject connections based on
> anchors that do or don't support.  and 2. Is this another fingerprint,
> at least at system level?  For example; corporate user's whose
> organizations who add their own TAs may become finger-printable as
> coming from those organizations.
>

Re (2), section 10 talks about this. It's hard to avoid saying what CAs you
trust without, well, saying what CAs you trust. Which means you should only
use this in contexts where you're willing to do that. For something like a
web browser, I would expect that we'd by default only advertise the
browser-vendor-managed roots. That only reveals what browser you're
running, which is thoroughly revealed by the entire web. That does
unfortunately leave browser-adjacent private PKIs in the fallback path, and
so servers still need to divine which to use. It's no worse than the status
quo, but it is a bit disappointing to leave that problem unsolved.

One could imagine an enterprise policy for administrators to say "yes, I
want robust negotiation and am willing to reveal this part of my clients'
trust anchor list". Or perhaps one filtered down to a particular set of
name patterns that will stay within an intranet? I dunno. One way or
another though, I think this is kinda fundamental to trying to help the
server pick certificates, at least for any solution that looks like the
standard client-offer / server-select TLS flow. (I could imagine
alternative solutions with different tradeoffs, like the server presenting
a list and the client picking, though that will add different complications
such as extra round-trips or dependency on a DNS record that may not be as
accessible. But I think any solution like that should be separate work. If
we find we need a couple of these, it's more moving parts, but there's no
reason they can't coexist.)

Re (1), I think this mostly falls out of (2) and where you try to use this.
We're scoping this to the subset of your trust anchor list that you
*are* willing
to reveal. In the browser-vendor-managed roots case, this ultimately just
reveals what browser or browser family you are (which is already thoroughly
revealed for better or worse). I won't speculate on what misguided network
operators may try to filter on, but it wouldn't be a new capability. Happy
to take a PR to add some extra text if you think it's worth talking about
though.

Additionally, any aspect of your trust anchor list that isn't revealed
won't be affected. Ultimately, this doesn't change what the relying party
*actually* accepts. This just allows the relying party to communicate
something about it (just like, but more compactly than, the existing
certificate_authorites extension) in hopes of better navigating this mess
of sometimes overlapping but ultimately disparate PKIs.


> Why sort TrustStores first by name-length, and then lexicographically?
> Just seems a little unnecessarily complex and unfriendly to indices.
>

Do you mean in section 5.1? It was just arbitrary. I wasn't sure if
"lexicographically", in IETF documents, was canonically defined to be
length first or "a" before "ab" before "b". (Wikipedia seems to suggest
there are variants
.)
So I just picked a disambiguation that didn't take very many words to say.
:-)

But I'm fine with whatever order. The goal was to just pick *some* defined
sort order, so that it's easy to find dupli

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[David Benjamin]

On Sat, Oct 21, 2023 at 5:41 AM Ilari Liusvaara 
wrote:

> On Fri, Oct 20, 2023 at 04:07:21PM -0400, David Benjamin wrote:
> > On Thu, Oct 19, 2023 at 3:17 PM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> > > - The multiple certificates from one ACME order really scares me. It
> > >   seems to me that can lead to all sorts of trouble.
> > >
> >
> > Certainly open to different mechanisms, though could you elaborate on
> > the trouble? We started with this one because it's actually just fixing a
> > mechanism ACME *already has*. RFC 8555, 7.4.2 has this bit:
> >
> >The server MAY provide one or more link relation header fields
> >[RFC8288] with relation "alternate".  Each such field SHOULD express
> >an alternative certificate chain starting with the same end-entity
> >certificate.  This can be used to express paths to various trust
> >anchors.  Clients can fetch these alternates and use their own
> >heuristics to decide which is optimal.
>
> Note the part "the same end-entity certificate.". The way I interpretted
> the draft, returning different end-entity certificates would be allowed.
>
>
> > Whether anyone has ever used this, I don't know. The "and use their own
> > heuristics to decide which is optimal" bit is quite absurd. :-) Relative
> to
> > that, all we've done is:
>
> Yes, that gets sometimes used.
>
>
> > But I suspect we'll want to define one where you make multiple orders
> too.
> > That would probably work better for, e.g., Merkle Tree certs where the
> two
> > issuances complete at very different times. But then, conversely, when
> the
> > two paths actually share an end-entity certificate, I imagine a single
> > order would be better so the CA knows it only needs to generate one
> > signature. And then when they don't share an end-entity certificate but
> are
> > similar enough in lifetime and issuance time, either seems fine, so we
> > figured this was a reasonable starting point.
>
> Well, I do not think it is feasible to use the normal ACME issuance
> mechanism for Merkle Tree certificates. The issuance is just too slow.
>
> And things like ACME ARI (which is required for actually handling
> revocations) inherently assume each order can only result one
> certificate.
>

The note about sharing an EE cert is just a SHOULD, not a MUST. RFC 8555
doesn't say why, but our interpretation was, like you note, this was mostly
a concern for things like accounting for renewals and revocations. We tried
to firm that up a bit by saying this makes sense when you're willing to
issue and renew all the variants together. For something like ARI, I was
imagining the ACME client would just check all of them (we're already
assuming the ACME client has been updated) and, if it needs to renew any of
them, it goes ahead and renews all of them. Slightly wasteful if renewal
was triggered by one of them getting revoked, rather than them all expiring
together. But I expect that's not common enough to be worth optimizing for.

Do you think multiple orders would be better? A multi-order flow is
probably more complex than fits in this document (this ACME change is
pretty small), so we didn't start with it. Plus this initial version seemed
natural to us based on what ACME had already defined. But we're much more
interested in making this kind of multi-certificate deployment model
possible than any of the particular details. Happy to adjust things based
on what turns out to work best. (One nuisance with a multi-order flow is
that the CA will have a harder time linking the requests together, which
opens a can of worms around whether they do separate validations or not.)



> > > - If there can be only one certificate, one could send all the chains
> > >   in one go via fist sending the certificate, then issuer chains each
> > >   ended by entry describing the trust anchor.
> > >
> >
> > I'm not quite sure if I've parsed this right, but are you thinking of one
> > file that somehow describes all alternatives together? That's plausible
> > too. Like I said, we mostly did this one because ACME already did it, so
> we
> > inferred that was The ACME Way. :-)
>
> Yes, one file describing all alternatives together. I think that is
> easier to work with than the existing alternatives mechanism (I don't
> think most clients even support that).
>

I think having to do a round of updating existing clients is fine here.
We'd already need to teach them to implement this thing. But if we think
putting them in one bundle is more convenient, that's fine by me too. I
don't actually care.

Exploring that direction a bit, won't that make issues around ARI and
different issuance rates worse? Bundling them means the system is further
inclined to treat them as one unit, but a lot of these problems come from
wanting to be able to treat each path separately, be it different renewal
times, different issuance times, potentially even different private keys
associated, etc. I also worry it'll get a bit thorny as i

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Carl Wallace]

ection 
doesn't seem necessary.

 

In Appendix A, the type field may be better as a group socket than text. Do you 
intend to make Appendix A normative at some point?

 

From: TLS  on behalf of David Benjamin 

Date: Thursday, October 19, 2023 at 11:38 AM
To: "" 
Cc: Devon O'Brien , 
Subject: [TLS] Fwd: New Version Notification for 
draft-davidben-tls-trust-expr-00.txt

 

Hi all,

We just published a document on certificate negotiation. It's a TLS extension, 
which allows the client to communicate which trust anchors it supports, 
primarily focused on use cases like the Web PKI where trust stores are fairly 
large. There is also a supporting ACME extension, to allow CAs to provision 
multiple certificate chains on a server, with enough metadata to match against 
what the client sends. (It also works in the other direction for client 
certificates.)

The hope is this can build towards a more agile and flexible PKI. In 
particular, the Use Cases section of the document details some scenarios (e.g. 
root rotation) that can be made much more robust with it.

It's very much a draft-00, but we're eager to hear your thoughts on it!

David, Devon, and Bob

-- Forwarded message -
From: 
Date: Thu, Oct 19, 2023 at 11:36 AM
Subject: New Version Notification for draft-davidben-tls-trust-expr-00.txt
To: Bob Beck , David Benjamin , Devon 
O'Brien 



A new version of Internet-Draft draft-davidben-tls-trust-expr-00.txt has been
successfully submitted by David Benjamin and posted to the
IETF repository.

Name: draft-davidben-tls-trust-expr
Revision: 00
Title:TLS Trust Expressions
Date: 2023-10-19
Group:Individual Submission
Pages:35
URL:  https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.txt
Status:   https://datatracker.ietf.org/doc/draft-davidben-tls-trust-expr/
HTML: https://www.ietf.org/archive/id/draft-davidben-tls-trust-expr-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr


Abstract:

   This document defines TLS trust expressions, a mechanism for relying
   parties to succinctly convey trusted certification authorities to
   subscribers by referencing named and versioned trust stores.  It also
   defines supporting mechanisms for subscribers to evaluate these trust
   expressions, and select one of several available certification paths
   to present.  This enables a multi-certificate deployment model, for a
   more agile and flexible PKI that can better meet security
   requirements.



The IETF Secretariat


___ TLS mailing list TLS@ietf.org 
https://www.ietf.org/mailman/listinfo/tls 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fwd: New Version Notification for draft-davidben-tls-trust-expr-00.txt

[Ilari Liusvaara]

On Mon, Oct 23, 2023 at 03:04:05PM -0400, David Benjamin wrote:
> 
> The note about sharing an EE cert is just a SHOULD, not a MUST. RFC 8555
> doesn't say why, but our interpretation was, like you note, this was mostly
> a concern for things like accounting for renewals and revocations. We tried
> to firm that up a bit by saying this makes sense when you're willing to
> issue and renew all the variants together. For something like ARI, I was
> imagining the ACME client would just check all of them (we're already
> assuming the ACME client has been updated) and, if it needs to renew any of
> them, it goes ahead and renews all of them. Slightly wasteful if renewal
> was triggered by one of them getting revoked, rather than them all expiring
> together. But I expect that's not common enough to be worth optimizing for.

I think ACME client are expected to pick one of the alternates and
discard the rest.

 
> Do you think multiple orders would be better? A multi-order flow is
> probably more complex than fits in this document (this ACME change is
> pretty small), so we didn't start with it. Plus this initial version seemed
> natural to us based on what ACME had already defined. But we're much more
> interested in making this kind of multi-certificate deployment model
> possible than any of the particular details. Happy to adjust things based
> on what turns out to work best. (One nuisance with a multi-order flow is
> that the CA will have a harder time linking the requests together, which
> opens a can of worms around whether they do separate validations or not.)

Multi-order flow is no more complex for ACME. It is also just requesting
extended information.

However, I think that the design space is severly constrained by TLS
server configuration. I do not think any TLS server is capable of
handling either flow without drastic changes to how certificate
configuration works.

What I think could work is shipping one certificate with its default
issuer chain, plus alternate chains with trust expression info, all
in one package. This would avoid the highly problematic variable
grouping of certificates.

When using certificate, the TLS server could select a certificate and
then change to alternate chain depending on the RP support.

 
> I think having to do a round of updating existing clients is fine here.
> We'd already need to teach them to implement this thing. But if we think
> putting them in one bundle is more convenient, that's fine by me too. I
> don't actually care.

I think that depending on the design, the TLS server changes may be less
than fine.

And at simplest designs, the ACME client changes could be just adding
accept to certficate fetches and updating the type whitelists to accept
the chain override info.

 
> Exploring that direction a bit, won't that make issues around ARI and
> different issuance rates worse? Bundling them means the system is further
> inclined to treat them as one unit, but a lot of these problems come from
> wanting to be able to treat each path separately, be it different renewal
> times, different issuance times, potentially even different private keys
> associated, etc. I also worry it'll get a bit thorny as it passes through
> the layers. E.g. if the TLS serving software expects one PEM file to be one
> certificate chain, but the TLS library secretly turns it into multiple
> alternative chains, the rest of the logic will break. (E.g. imagine if the
> serving software knows to set up OCSP stapling or otherwise associate data
> with the cert it's serving.)

Normal OCSP and SCT will work just fine even if TLS library secretly
turns PEM files into multiple chains. The stuff that would break is
quite exotic (e.g., multi-OCSP). And I expect vast majority of even
such exotic stuff to work okay if TLS library just drops all the
problematic stuff on chain override (e.g., downgrading multi-OCSP to
normal OCSP).

In contrast, if there are multiple distinct certificates or chains,
those need to be handled as unit. Which is not something present TLS
servers are capable of doing, because nothing else requires that.

 
> Ah, this is "expiry" in the sense of actually removing the root from v2?
> I.e. distinct from what our draft (somewhat confusingly) calls expiry. (Our
> "expiry" relates to this cross-version issue.)

Expiry in sense of removing the root from all versions.

I have heard some roots are considering limiting the root certificate
lifetime. So individual root programs might have different expiry
date from the one contained in the root certificate (and there may be
multiple versions of the same root with different lifetimes!). 

 
> Yeah, we don't have that right now. Though I think most cases don't need
> explicit expiry information. Since this is used for negotiation, not trust,
> it doesn't actually matter if v2 contains some roots that have expired, as
> long as both RP and CA agree on when this happens. I.e. *for negotiation
> purposes*, it makes no difference whether a