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

[Orie Steele <[e-mail]>]

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]>
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]>; 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
> www.transmute.industries
> <https://urldefense.com/v3/__http:/www.transmute.industries__;!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvwbYBl6kM$>
>
> [image: Image removed by sender.]
> <https://urldefense.com/v3/__https:/transmute.industries__;!!FJ-Y8qCqXTj2!fjzKqcSRy4mYBet3i43Yz5aytF4UHea6E3zd8XFtXK9Me93OWcXe4vEb1B1_uzJzphtPPAnsi8Zj45dTiMvwJ7Pdhgs$>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>