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

[Mike Ounsworth <[e-mail]>]

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.

 

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.

 

 

 

> 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.

 

 

 

> 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.

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. Just because their key is in my truststore does not mean that I trust them to name themselves.

 

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.

 

 

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

---

Mike Ounsworth

 

From: Orie Steele <[e-mail]> 
Sent: Tuesday, January 16, 2024 3:42 PM
To: scitt <[e-mail]>; LAMPS <[e-mail]>
Cc: Mike Ounsworth <[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$>