I found the CDDL in the appendix intriguing:
https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#appendix-A
In SCITT, we've been kicking around a related concept...
It's had several names, all of which have led to confusion, so I will not
repeat them here, but I want to overlay how they have been related in SCITT:
trust-anchor = { ; cose sign1 of some key (JWK/PGP/COSE) or certificate
type: text,
* text => any,
}
trust-store-entry = { ; a receipt from a transparency service, proving a
trust anchor in included in a log (like CT/KT)
id: text,
labels: [+ uint],
max_lifetime: uint,
* text => any,
}
trust-store-version = { ; an aggregation of receipts, based on some query,
for example, all receipts for trust anchors signed by the same key.
timestamp: int,
entries: [+ trust-store-entry],
* text => any,
}
trust-store-manifest = { ; cose sign 1 of an aggregation of receipts,
related to some subject, for example, a software bill of materials, where
each receipt is for a specific software dependency
name: text,
max_age: uint,
trust_anchors: {+ text => trust-anchor},
versions: [+ trust-store-version],
* text => any,
}
One of the interesting topics we have discussed is producing stable
identifiers for these structures, building on URI templates and thumbprints.
In the examples I can see in the trust expressions draft, you have data by
value instead of data by reference.
Consider the following URI Template for expressing versions of a trust
store:
https://{service-provider}/{trust-store-manifest.name}/versions -> all
versions of a trust store by name
https://{service-provider}/{trust-store-manifest.name}/versions/1672531200
-> all receipts for certs in a trust store version (certs by reference) ->
list of signatures ( certs by value )
We had wondered if it would be valuable to assign a naming convention and
content addressed names to resources,
so that you could ask an arbitrary scitt transparency service for details
regarding any artifact that you might be holding as bytes.... for example:
https://{service-provider}/{trust-store-manifest.name}/trust_anchors/{thumbprint(A1)}
-> all versions of a trust store by name containing A1.
Obviously these names are not cross protocol friendly, we looked into URNs
for that (don't throw things at me, I know this is a sensitive subject in
the IETF).
The concept of SCITT Receipts seems close to the purpose of intermediate
ellison here:
https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-intermediate-elision
The idea was that if you had stable receipts from a transparency service
you trusted, you might not need to care about all the parts of a cert chain
that they validated before including the cert in their transparency log.
I'd be interested in prototyping a SCITT mapping for this, if I can wrap my
head around the use case a bit more.
OS
On Thu, Feb 29, 2024 at 6:31 PM David Benjamin <[email protected]>
wrote:
> Oh, I should have added: I put together an informal "explainer"-style
> document to try to describe the high-level motivations and goals a bit
> better. The format is adapted more from the web platform end, which likes
> to have separate explainer and specification documents, but it seemed a
> good style for capturing, at a high level, what we're trying to accomplish.
> https://github.com/davidben/tls-trust-expressions/blob/main/explainer.md
>
> It's largely a copy of the start of this email thread, but I figured it'd
> be useful to have a more canonical home for it. (We'll probably adapt some
> of that text back into the draft, after some more wordsmithing.)
>
>
> On Thu, Feb 29, 2024 at 7:18 PM David Benjamin <[email protected]>
> wrote:
>
>> Circling back to this thread, we're now looking at prototyping the TLS
>> parts in BoringSSL, on both the client (Chrome) and the server side. Let us
>> know if you have any thoughts on the proposal!
>>
>> (Nothing that would prevent us from changing details, of course. But as
>> there are a lot of pieces here, we'd like to get some experience with
>> things.)
>>
>> On Thu, Jan 25, 2024 at 5:00 PM David Benjamin <[email protected]>
>> wrote:
>>
>>> Hi all,
>>>
>>> Now that the holidays are over, I wanted to follow up on
>>> draft-davidben-tls-trust-expr and continue some of the discussions from
>>> Prague:
>>>
>>>
>>> https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html
>>>
>>>
>>> https://datatracker.ietf.org/meeting/118/materials/slides-118-tls-tls-trust-expressions-00
>>>
>>> First, I wanted to briefly clarify the purpose of excluded_labels
>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-trust-expressions>:
>>> it is primarily intended to address version skew: if the certificate is
>>> known to match (example, v10) and the client says (example, v11), the
>>> server doesn’t know whether v11 distrusted or retained the CA. We resolve
>>> that with a combination of excluded_labels and TrustStoreStatus.
>>> excluded_labels is not intended for user-specific removals. I’ve
>>> reworked the Privacy Considerations
>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-privacy-considerations>
>>> section to discuss this more clearly.
>>>
>>> Second, I wanted to take a step back and try to better articulate our
>>> goals. I think the best way to look at this draft is in three parts:
>>>
>>> 1. A new multi-certificate deployment model (the overall goal)
>>>
>>> 2. Selecting certificates within that model (the TLS parts of the draft)
>>>
>>> 3. Provisioning certificates (the ACME parts of the draft)
>>>
>>> We’d most like to get consensus on the first, as it’s the most
>>> important. Trust expressions are a way to achieve that goal, but we’re not
>>> attached to the specific mechanism if there’s a better one. We briefly
>>> discuss this in the introduction
>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-introduction>,
>>> but I think it is worth elaborating here:
>>>
>>> The aim is to get to a more flexible and robust PKI, by allowing servers
>>> to select between multiple certificates. To do this, we need a way for the
>>> servers to reliably select the correct certificate to use with each client.
>>> In doing so, we wish to minimize manual changes by server operators in the
>>> long run. Most ongoing decisions should instead come from TLS software,
>>> ACME client software, and ACME servers.
>>>
>>> Why does this matter? PKIs need to evolve over time to meet user
>>> security needs: CAs that add net value to the ecosystem may be added,
>>> long-lived keys should be rotated to reduce risk, and compromised or
>>> untrustworthy CAs are removed. Even a slow-moving, mostly aligned ecosystem
>>> is still made of individual decisions that roll out to individual clients.
>>> This means, whether we like it or not, trust divergence is a fact of life,
>>> if for no other reason than out-of-date clients in the ecosystem. These
>>> clients could range from unupdatable TV set-top boxes to some IoT device to
>>> a browser that could not communicate with its update service.
>>>
>>> Today, the mere existence of old clients limits security improvements
>>> for other, unrelated clients. Consider a TLS client making some trust
>>> change for user security. For availability, TLS servers must have some way
>>> to satisfy it. Some server, however, may also support an older client. If
>>> the server uses a single certificate, that certificate is limited to the
>>> intersection of both clients.
>>>
>>> At the scale of the Internet, the oldest clients last indefinitely. As
>>> servers consider older and older clients, that intersection becomes
>>> increasingly constraining, causing availability and security to conflict.
>>> As a community of security practitioners, I wish I could tell you that
>>> security wins, that those servers can simply be convinced to drop the old
>>> clients, and that this encourages old clients to update. I think we all
>>> know this is not what happens. Availability almost always beats security.
>>> The
>>> result of this conflict is not that old clients get updates, it is that
>>> newer clients cannot improve user security. It takes just one important
>>> server with one important old client to jam everything, with user
>>> security paying the cost.
>>>
>>> We wish to remove this conflict with certificate negotiation, analogous
>>> to TLS version negotiation and cipher suite negotiation. Certificate
>>> negotiation, via trust expressions, means security improvements in new
>>> clients do not conflict with availability for older clients. Servers can,
>>> with the aid of their ACME servers, deliver different chains to different
>>> clients as needed.
>>>
>>> Now, some of these problems can be addressed with cross-signs between
>>> CAs, but this is a partial solution at best. Without negotiation, this
>>> still means sending certificates for the lowest common denominator to all
>>> clients. This wastes bandwidth, particularly with post-quantum
>>> cryptography, where every signature costs kilobytes. Additionally, an
>>> individual server operator cannot unilaterally configure this. Cross-signs
>>> apply to entire intermediate CAs, not just the individual server’s
>>> certificate.
>>>
>>> There’s more to say on this topic, as relieving this conflict solves
>>> many other PKI problems and enables new solutions for relying parties, CAs,
>>> and subscribers. We discuss some of these in the use cases
>>> <https://davidben.github.io/tls-trust-expressions/draft-davidben-tls-trust-expr.html#name-use-cases>
>>> section. But hopefully this helps clarify our goals and is a starting point
>>> for discussion.
>>>
>>> We’d be interested to hear thoughts on these issues or others. Our hope
>>> is to reach enough consensus on the list to determine whether it would make
>>> sense to have a call for adoption around Brisbane.
>>>
>>> Thanks,
>>>
>>> David
>>>
>> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
--
ORIE STEELE
Chief Technology Officer
www.transmute.industries
<https://transmute.industries>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
