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 <orie@transmute.industries> 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 <mike.ounswo...@entrust.com> > 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 <orie@transmute.industries> >> *Sent:* Tuesday, January 16, 2024 3:42 PM >> *To:* scitt <sc...@ietf.org>; LAMPS <sp...@ietf.org> >> *Cc:* Mike Ounsworth <mike.ounswo...@entrust.com> >> *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>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth