Re: [lamps] [EXTERNAL] Issuers: Lamps <> Scitt

[Mike Ounsworth <[e-mail]>]

Seems reasonable to me.

 

---

Mike Ounsworth

 

From: Orie Steele <[e-mail]> 
Sent: Wednesday, January 17, 2024 11:40 AM
To: Mike Ounsworth <[e-mail]>
Cc: scitt <[e-mail]>; LAMPS <[e-mail]>; oauth <[e-mail]>
Subject: Re: [EXTERNAL] Issuers: Lamps <> Scitt

 

It seems OAUTH has a draft that also addresses the binding of `iss` to certificates: > If the iss value contains a DNS name encoded as a URI using the DNS URI scheme [RFC4501]. In this case, the DNS name MUST match a dNSName Subject Alternative 



It seems OAUTH has a draft that also addresses the binding of `iss` to certificates:

> If the iss value contains a DNS name encoded as a URI using the DNS URI scheme [RFC4501]. In this case, the DNS name MUST match a dNSName Subject Alternative Name (SAN) [RFC5280] entry of the leaf certificate.

- https://datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-01#section-3.5 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-oauth-sd-jwt-vc-01*section-3.5__;Iw!!FJ-Y8qCqXTj2!e5gbyBK2NCboiiepdQg3PUBWmMCAYNhJ6zcy3DkfXpIblka0OO7UTMW3yxZkHYA33vtB06LX9GaGomFY8gHLlBS0svk$> 

It seems that based on the OAUTH guidance, the SCITT guidance should match the OAUTH guidance.

Regards,

OS

 

On Tue, Jan 16, 2024 at 7:46 PM Orie Steele <[e-mail]> wrote:

There are 3 things that make up the SCITT ecosystem:

1. Signed Statements (COSE Sign 1 based signatures over arbitrary content, with CWT Claims in the header).
2. Receipts (COSE Sign 1 based counter signatures with inclusion proofs for transparency logs)
3. Identity Documents (certificates or public keys delivered from a trust store)


In a way, Signed Statements are a bit like a CSR with evidence, and Receipts are like a Certificate.

The goal with Signed Statements was to make them really easy to create, and not have any identity specific blocks for creating them (such as DIDs or x509)... 
Issuer's should be able to start using them without waiting for approval, but a (conservative / rigorous) Transparency Service might require extra vetting before they will provide a Receipt for one.

When you get a software artifact with a signed statement and a receipt, you actually have the following, encoded in the "Transparent Statement":

Software Producer Identity  ( identifier to key binding )
  issues --> Signed Statement ( signature over the artifact / statement, proving that content has not been tampered with, signed by the "issuer" / software vendor )

Transparency Service Identity ( identifier to key binding )
  issues --> Receipt ( proof of inclusion, signed by the transparency service, proving a Signed Statement, was valid according to their policy at the time it was included in their log )

So these questions regarding x5t and iss / sub apply to both Receipts and Signed Statements, and SCITT is designed today, such that the identity infrastructure could be the same or different for both.

We should be able to use federated workload identity, x509 and blockchain if that is required, or just x509 if that does the job.

Also, it's possible to have multiple receipts for the same signed statement, this proves a signed statement is in multiple transparency logs.

Inline for the rest, this time with a CSR analogy:

 

On Tue, Jan 16, 2024 at 4:40 PM Mike Ounsworth <[e-mail] <mailto:[e-mail]> > wrote:

Hi,

 

As Orie mentioned, we’ve discussed this. I am an X.509 PKI guy, so I see all problems through X.509-coloured glasses (interpret that with whatever feelings of joy, excitement, disgust, or rage as you see fit).

 

We have decades of experience of handling the UI aspects of this (and of training user behaviour) through the Windows Code Signing and Linux package manager ecosystems. When you see a popup saying “Do you want to install “firefox.exe” which is verified by “Mozilla Corporation”?”, or “Do you want to add the GPG key for “cURL Project” to apt sources?” users know what to expect; that there is some level of trust in that naming information – in Windows, the CA verified that the person requesting the cert is actually Mozilla Corporation. In Linux package managers we put that responsibility onto distro maintainers or end users, but there’s still a vetting process to bind keys to names.

 

What’s important to me is that SCITT is building on this history and maintaining the user experience expectations. If a holder of a trusted key is allowed to put whatever name they want for themself in the ‘iss’ field of a signed SCITT object, then that would no longer be in keeping with the historical precedent of other code signing ecosystems.


How is a SCITT Signed Statement different from an integrity protected CSR here?

If the iss, sub, or any other claims in the Signed Statement, do not match the Transparency service policy, which covers both the verification material the transparency service has in its trust store, and the claims, then no Receipt will be issued by the TS.

I suppose this is similar to a CSR request with claims that the CA does not support?

 

Aside – I’m not a SCITT expert so I don’t know what the semantics of ‘sub’ are in SCITT, but I imagine that refers to the object being signed, and not to the entity doing the signing? I don’t see how ‘sub’ has anything to do with the x5t.

 

 

That's right, sub is a text string, it's the identifier about which the issuer is making assertions, regardless of which key verifies the assertions... iss is just another assertion, only this time, it's a self assertion regarding an identifier for the "entity" that controls the signing key, that's used to make assertions about the subject.
 

 

 

> When `x5t` is present, iss MUST match subjectAltName in the resulting certificate.

 

This one is an interesting point in that an X.509 cert can contain a whole list of names in the DN: CN, and in the SANs list. I would amend Orie’s sentence to:

 

“When `x5t` is present, iss MUST match either the CN or one of the subjectAltNames in the referenced certificate.” 

 

In that case, ‘iss’ is providing value because it allows you to choose which of the multiple verified names you want displayed in the UI.

 

 

agreed.
 

 

 

> Requiring the text value of `iss` to match the `subjectAltName`, and considering any message where they conflict invalid, does not change the fact that all claims (including iss, and sub) are ONLY reliable, when you trust a key that verifies them.

Yeah, I disagree with that. 

I think that’s taking an overly simplified view of “trust”.

I mean, that’s necessary, but not sufficient to have trust.

You have to trust that key AND you have to trust how that key has been bound to a name string.

 

Right, in the case of a cert in a trust store, you trust the "multiple verified names", when you install the cert in your trust store.

You can install multiple certs for the same names (right?), if "iss" maps to multiple certs, each containing multiple names, either all the certs will verify the message, or some will, or none will.

In the case of a trust store that is a database that maps an "identifier" to a "key", like key transparency, you trust the name for the key based on the KT structure as opposed to the cert and trust store structure.

 

I can trust both the signing certs for Mozilla, and for the maintainers of the Sublime Text Editor to sign their own software. What I don’t trust is for the Sublime Project certificate to sign a firefox.exe claiming to be Mozilla.

 

But of course anyone with a signing capability can create such a signature, and it is up to policy to decide if it's acceptable.
 

Just because their key is in my truststore does not mean that I trust them to name themselves.


This is why Receipts matter, a receipt is a counter signature that says basically "some vendor signed this software, we (the TS) authenticated them, and the iss, sub, and details of the software met our policy, that's why we issued a Receipt."

In a way, the issuer proposes the iss and sub, and TS accepts those proposals by issuing a Receipt. ( similar to CSR? )

Because of this, there will likely be strong industry pressure to pick identifiers for issuers (iss) and identifiers for artifacts (sub) that multiple independent transparency services will accept.

Unfortunately, I don't think SCITT knows what those identifiers will be at this point in time.... it's looking like an open ended graph problem.
 

 

Or, phrased a different way; we’re talking about cryptography, right? That means that it’s in-scope to consider dishonest parties. Let’s say I incorporate Mike’s Software Funhouse, inc and I buy a publicly-trusted Windows code signing cert (the only requirement for which is to be a registered company). Now, it turns out that my business is setting malware, so I very much intended to sign a firefox.exe that’s full of malware. You should trust my cert to correctly identify me as Mike’s Software Funhouse, inc, and you should absolutely not trust my cert to sign a firefox.exe claiming to be from Mozilla.

 

If you get a Receipt from Mozilla that says they have made a Signed Statement, "transparent", from your build server, the iss for the Signed Statement will be an identifier for your build server bound to some ( hopefully hardware backed ) key Mozilla trusted enough to issue a Receipt.... and the Receipt's iss will be an identifier for Mozilla's transparency service, regardless of if they are using x509, key transparency, or something new to handle the identity to public key binding.


The prompt to the user will be: "Do you still trust Mozilla to issue Transparency Receipts? Mike's Software Funhouse has a Receipt from Mozilla for this custom Firefox build".

The prompt might also mention some receipts from other transparency services that you don't trust yet, in case Mozilla is the only issuer of receipts you have installed currently.

You won't need to install a cert / public key for every software producer / signed statement issuer, you will only need to install keys for transparency services, and let them do their job of vetting the software artifact and statement issuer's.

If you really want to, you can install keys for both the transparency service and the issuer, and check the inclusion proof, the signature on the receipt, the signature on the signed statement, and the hash of the artifact, in case it was extremely large.

And it will work regardless of if the identity layer (just imagine if there was only one) is KT, x509, DIDs, or a filesystem directory on your android phone with "iss" values as vendor names, and jwk.json and key.cbor files inside them, that you sync over nfc at the hotel bar every ietf.

 

 

 

PS – Orie, don’t think you’re gonna pull me into being a full member of the SCITT WG. Nice try.


My usual strategy is to threaten terrible design, but in the case of x509, I don't have enough experience to tell if it's working.

---

Mike Ounsworth

 

From: Orie Steele <[e-mail]> 
Sent: Tuesday, January 16, 2024 3:42 PM
To: scitt <[e-mail] <mailto:[e-mail]> >; LAMPS <[e-mail] <mailto:[e-mail]> >
Cc: Mike Ounsworth <[e-mail] <mailto:[e-mail]> >
Subject: [EXTERNAL] Issuers: Lamps <> Scitt

 

Hello, We've been evolving the SCITT architecture, and taking advantage of some newer work in COSE. - https: //datatracker. ietf. org/doc/draft-ietf-cose-cwt-claims-in-headers/ As a result, SCITT now has the potential to have "Signed 

Hello,

We've been evolving the SCITT architecture, and taking advantage of some newer work in COSE.

- https://datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-cose-cwt-claims-in-headers/__;!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvwYgR_YJA$> 

As a result, SCITT now has the potential to have "Signed Statement" cose headers that look like this:

{
  / alg: ES256                   / 1: -7,                  
  / x5t: 10:B9:24:...:1D:8B:93   / 34: h'10b924...1d8b93', 
  / CWT Claims in Headers        / 15: {
  / iss: some text string / 1: software.vendor.example,
  / sub: some text string / 2: pkg:nuget/EnterpriseLibrary.Common@6.0.1304 
  }
}



The question is this:

When `x5t` is present:

How should `iss` and `sub` in https://www.iana.org/assignments/cwt/cwt.xhtml <https://urldefense.com/v3/__https:/www.iana.org/assignments/cwt/cwt.xhtml__;!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvw8PSGnBE$> 

Relate to `issuer` and `subjectAltName` in https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.6 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5280*section-4.1.2.6__;Iw!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvw6CrPo4w$>  ?

I initially asked Mike O, what normative requirements should SCITT have regarding this possible header structure, and which list should I ask this on? 

I'll summarize some of the background, and then pitch what I think SCITT should say on this subject (pun intended), any mistakes are my fault, not Mike's.

First a quick recap on what putting `x5t` in a COSE / JOSE header means (let's assume we are not interested in "is SHA-1 safe to use these days")... :

- https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.7 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc7515*section-4.1.7__;Iw!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvwu769voA$> 
- https://datatracker.ietf.org/doc/html/rfc9360#section-2 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc9360*section-2__;Iw!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvwWqvWdmY$> 

> x5t: This header parameter identifies the end-entity X.509 certificate by a hash value (a thumbprint). The 'x5t' header parameter is represented as an array of two elements. The first element is an algorithm identifier that is an integer or a string containing the hash algorithm identifier corresponding to the Value column (integer or text string) of the algorithm registered in the "COSE Algorithms" registry (see <https://www.iana.org/assignments/cose/ <https://urldefense.com/v3/__https:/www.iana.org/assignments/cose/__;!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvw4CfWJ84$> >). The second element is a binary string containing the hash value computed over the DER-encoded certificate.

Let's consider the common UI experience where a user is prompted to agree they trust a software producer who signed a binary before installing it, based on certificates in the user's trust store:

Today, a user attempts to install a binary, and a dialog shows up displaying the "Are you sure you want to install software from: software.vendor.example?", where "software.vendor.example" is the subjectAltName of the certificate in the trust store.


The signed software has hints about the software producer ( iss / kid / x5t ) and they help software (such as an operating system) find a public key (certificate with subjectAltName), in a trust store, which verifies the binary, and then the user can be prompted to confirm they are comfortable proceeding.


With SCITT, there is a possibility that the software verifies without using a certificate, in which case, the UI would have nothing to display, since there is no "subjectAltName" in the trust store, if the trust store is just a set of COSE Keys or JWKs.

In this case, (***after verification***) the UI could display any of the fields in the SCITT header to the user.

This could lead to a public key being used to sign binaries, where the `iss` is different in each message (signed binary), even if the public key is the same.

It is possible for the same certificate (discovered by x5t) to be used with different `iss` values, so binaries signed by the same cert with "subjectAltName: software.vendor.example", might display a prompt that looked like:

"Are you sure you want to install software from (iss: vendor.example, subjectAltName: software.vendor.example)?"

"Are you sure you want to install software from (iss: software.vendor.example, subjectAltName: software.vendor.example)?"

"Are you sure you want to install software from (iss: distributor.example, subjectAltName: software.vendor.example)?"


Regardless of the text we write, let's agree this will happen, now that it's possible for it to happen.

With this context out of the way, I hope we are ready to discuss the guidance the SCITT Architecture should provide.

Implementation Guidance:

1. Only display verified claims (iss, sub, etc...).

Claims in the header or payload MUST NOT be displayed until after they have been verified.

This guidance unifies the hint processing enabled by x5t with hint processing enabled by `kid`.
If you don't have a key that verifies the message, you see "this software is not trusted".
If you cannot verify the message (because you don't have a cert or a public key in your "trust store"), you will never see any potentially incorrect information.
If you have a cert in your trust store, you see the iss, that was signed by the cert that verifies the binary.
If you have a COSE Key in your trust store, you see the `iss` that was signed by the COSE Key that verifies the binary.

2. Forbid conflicting identifiers (Redundant)

When `x5t` is present, iss MUST match subjectAltName in the resulting certificate.

This would ensure that the same "software producer identifier" is displayed, regardless of if the message is a COSE Sign 1 SCITT message, or an existing binary signed with x509.

This will cause validation policies to throw errors, after verification succeeds, and requires comparing the verified headers to the certificate used to verify them.

3. Forbid conflicting identifiers (Exclusive)

When `x5t` is present, iss and kid MUST be absent.

This will cause validation policies to throw errors, after verification succeeds, and will cause complex UI that attempts to resolve the "verified issuer label" from different data structures.

SCITT Security Considerations:

I think SCITT should call out that 2 and 3 do not actually give you any security improvement, and if implemented incorrectly, could lead to "trust without verify" bypass at the policy layer... and I think 2 and 3 should not be included in the architecture.

In the case that the trust store is compromised, it can already contain a certificate that can match any `iss` or `x5t` in the binary.

In the case that the trust store is uncompromised, and filled with keys and certificates that can verify messages:

Requiring the text value of `iss` to match the `subjectAltName`, and considering any message where they conflict invalid, does not change the fact that all claims (including iss, and sub) are ONLY reliable, when you trust a key that verifies them.

Consider an alternative proposal, where SCITT mandates that `kid` always be equal to a specific identifier, for example: "did:example:123#key-42", or equivalently, { iss: did:example:123, kid: 42 }

If there is no way to get a certificate or key from this "custom identifier hint", there is nothing that can possibly be displayed to the user, since there are no certificates, or claims signed by a public key that is trusted.

Headers are "hints", nothing about a header or a payload should be evaluated by a policy until after a verification succeeds, at which point, you are looking at what the issuer intended to sign, arguing that software vendors should implement specific string matching rules when "upgrading" to SCITT, after verifying, seems like a recipe for lots of validation errors, that are not actually providing any value, or even worse, deep / expensive / complex validation before verification (aka https://cwe.mitre.org/data/definitions/502.html <https://urldefense.com/v3/__https:/cwe.mitre.org/data/definitions/502.html__;!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvwKK_KUNY$>  )

Now please tell me everything I got wrong : )

OS

-- 

 

ORIE STEELE
Chief Technology Officer
 <https://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvwbYBl6kM$> www.transmute.industries

 <https://urldefense.com/v3/__https:/transmute.industries__;!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvwJ7Pdhgs$> 




 

-- 

 

ORIE STEELE
Chief Technology Officer
www.transmute.industries <https://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!e5gbyBK2NCboiiepdQg3PUBWmMCAYNhJ6zcy3DkfXpIblka0OO7UTMW3yxZkHYA33vtB06LX9GaGomFY8gHLyFJn3-g$> 

 <https://urldefense.com/v3/__https:/transmute.industries__;!!FJ-Y8qCqXTj2!e5gbyBK2NCboiiepdQg3PUBWmMCAYNhJ6zcy3DkfXpIblka0OO7UTMW3yxZkHYA33vtB06LX9GaGomFY8gHLv6NfKY4$> 




 

-- 

 

ORIE STEELE
Chief Technology Officer
www.transmute.industries <https://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!e5gbyBK2NCboiiepdQg3PUBWmMCAYNhJ6zcy3DkfXpIblka0OO7UTMW3yxZkHYA33vtB06LX9GaGomFY8gHLyFJn3-g$> 

 <https://urldefense.com/v3/__https:/transmute.industries__;!!FJ-Y8qCqXTj2!e5gbyBK2NCboiiepdQg3PUBWmMCAYNhJ6zcy3DkfXpIblka0OO7UTMW3yxZkHYA33vtB06LX9GaGomFY8gHLv6NfKY4$>