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

[Orie Steele <[e-mail]>]

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

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


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>