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

[Orie Steele <[e-mail]>]

No, as long as you use a COSE Sign 1 to encode the signature.

You would use the x5t header parameter to point to your cert... of course
it's possible that no transparency service will accept that signed
statement and issue a receipt, because you used a self signed cert.

OS

On Wed, Jan 17, 2024 at 12:36 PM Dick Brooks <
[e-mail]> wrote:

> Does this also exclude self-signed artifacts using X.509?
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
>
>
> *Active Member of the CISA Critical Manufacturing Sector, *
>
> *Sector Coordinating Council – A Public-Private Partnership*
>
>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* Orie Steele <[e-mail]>
> *Sent:* Wednesday, January 17, 2024 1:35 PM
> *To:* Stein, A.J. Mr. (Fed) <[e-mail]>
> *Cc:* [e-mail]; scitt <[e-mail]>
> *Subject:* Re: [SCITT] [EXTERNAL] Issuers: Lamps <> Scitt
>
>
>
> Since you mentioned SSH... Those keys are also not supported in the
> architecture.
>
> To be clear, when SCITT describes identity documents it is describing some
> "trusted name for a public key, that can verify cose sign 1".
>
> When SCITT describes "Signed Statements and Receipts", those are COSE Sign
> 1...
>
> Which means not PGP, and not DER encoded signatures from OpenSSL, or any
> other signature format.
>
> For examples of things that exist in the wild that produce signatures that
> are not compatible with the SCITT architecture:
>
> - JWS: https://github.com/panva/jose
> - GPG Signatures: https://www.gnupg.org/gph/en/manual/x135.html
> - SSH Signatures: https://www.agwa.name/blog/post/ssh_signatures
> - OpenSSL Signatures:
> https://www.zimuel.it/blog/sign-and-verify-a-file-using-openssl
> - DSSE: https://github.com/secure-systems-lab/dsse
>
> Regards,
>
> OS
>
>
>
> On Wed, Jan 17, 2024 at 12:13 PM Stein, A.J. Mr. (Fed) <
> [e-mail]> wrote:
>
> Dick,
>
>
>
> Your point is apt but many open source projects use OpenPGP reluctantly
> for an ironic reason, it's the only option from a package manager or
> artifact repository service and there is no required certificate authority;
> it's a feature, not a bug, and this gives way to the web of trust model.
> Many packaging systems use it because it is the only reliable zero-cost
> option for free/open software and that last bit, the WoT, is up to the
> developer and downstream users to deal with, end of story. (Everyone in the
> Maven ecosystem has essentially only that option for public libraries).
>
>
>
> So why is that?
>
>
>
> The Web of Trust notions in OpenPGP are related, but different, from
> X.509's hierarchical model, and both systems are earlier realizations of
> what should be possible *with/alongside *SCITT services (not within, last
> time this was mentioned others rightfully mentioned this is not in the IETF
> SCITT charter, implementations aside): transparency services facilitate
> checking artifacts themselves, artifact maker, issuer, verifier, relying
> parties et cetera identifiers and *give building blocks for verifiers and
> RPs to decide whether they will bind them to identities humans care about*.
> I'd argue that OpenPGP has never really succeeded at this (and I had been a
> very avid user in my personal life for years) and why it is the elephant in
> the room. It is why OpenPubKey and SigStore started in the software supply
> chain space. I say this regrettably as someone who likes OpenPGP (and there
> are many hardline critics who say it should go away).
>
>
>
> More importantly, as Orie points out, it is not easy to port keying and
> cert material between the two, if possible. Quick Googling confirmed
> responses from "why would you do that?" to "you cannot really do that, this
> isn't like PGP/OpenSSH key translation when you SSH into a server."
>
>
>
> As far as SCITT is concerned, someone could make the same recommendations
> in something alongside the architecture and use identifiers and OpenPGP
> signatures, but that is outside of the scope of the architecture, and this
> higher level goal in italics is out of scope generally for SCITT (and Orie
> has made it sound like it is really part of the Key Trans
> <https://datatracker.ietf.org/wg/keytrans/about/> work). Rest of the
> list: I am right in this interpretation?
>
>
>
> Best,
> A.J.
>
>
>
> --
>
> A.J. Stein
>
> IT Cybersecurity Specialist
>
> Secure Components and Mechanisms Group
> <https://www.nist.gov/itl/csd/security-components-and-mechanisms>
>
> NIST ITL Computer Security Division
>
> Email: [e-mail]
> Cell: [phone]
> Matrix: @aj-stein-nist-619d4e9d6da03739848b2b5a:gitter.im
> <https://matrix.to/#/@aj-stein-nist-619d4e9d6da03739848b2b5a:gitter.im>
>
> GitHub: github.com/aj-stein-nist
>
>
>
> Need to chat? Click this link to book time with me
> <https://outlook.office.com/bookwithme/user/[e-mail]?anonymous&ep=plink>
> .
>
> Who am I and what am I working on? Read more in my GitHub bio
> <https://github.com/aj-stein-nist/#work>.
> ------------------------------
>
> *From:* SCITT <[e-mail]> on behalf of Dick Brooks <
> [e-mail]>
> *Sent:* Wednesday, January 17, 2024 12:54 PM
> *To:* 'Orie Steele' <[e-mail]>
> *Cc:* 'scitt' <[e-mail]>
> *Subject:* Re: [SCITT] [EXTERNAL] Issuers: Lamps <> Scitt
>
>
>
> Thanks for the feedback, Orie.
>
>
>
> I think it’s more important to support X.509 and PKCS #1 given current
> software supply chain practices. However, many open source projects issue
> OpenPGP signatures. This could introduce a barrier to adoption.
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
>
>
> *Active Member of the CISA Critical Manufacturing Sector, *
>
> *Sector Coordinating Council – A Public-Private Partnership*
>
>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* Orie Steele <[e-mail]>
> *Sent:* Wednesday, January 17, 2024 12:50 PM
> *To:* [e-mail]
> *Cc:* scitt <[e-mail]>
> *Subject:* Re: [SCITT] [EXTERNAL] Issuers: Lamps <> Scitt
>
>
>
> Dropping lamps and oauth to discuss openpgp with cose.
>
> I don't see how we can possibly support OpenPGP with COSE.
>
> There is no way to bind a COSE Sign 1 to an OpenPGP Key or Certificate ( I
> think OpenPGP has their own concept of certificates?).
>
> OpenPGP is typically used to produce OpenPGP Signatures, which are not
> compatible with the SCITT architecture, which states that both a "Signed
> Statement" and a "Receipt" are based on COSE Sign 1.
>
> Regards,
>
> OS
>
> On Wed, Jan 17, 2024 at 11:42 AM Dick Brooks <
> [e-mail]> wrote:
>
> Anything that will enable support for X.509 and PKCS #1 signatures would
> be good. The same is true for OpenPGP.
>
>
>
> Thanks,
>
>
>
> Dick Brooks
>
>
>
> *Active Member of the CISA Critical Manufacturing Sector, *
>
> *Sector Coordinating Council – A Public-Private Partnership*
>
>
>
> *Never trust software, always verify and report!
> <https://reliableenergyanalytics.com/products>* ™
>
> http://www.reliableenergyanalytics.com
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* SCITT <[e-mail]> *On Behalf Of *Orie Steele
> *Sent:* Wednesday, January 17, 2024 12:40 PM
> *To:* Mike Ounsworth <[e-mail]>
> *Cc:* scitt <[e-mail]>; LAMPS <[e-mail]>; oauth <
> [e-mail]>
> *Subject:* Re: [SCITT] [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 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
>
> [image: Image removed by sender.] <https://transmute.industries/>
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
>
> [image: Image removed by sender.] <https://transmute.industries/>
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
>
> [image: Image removed by sender.] <https://transmute.industries/>
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
>
> [image: Image removed by sender.] <https://transmute.industries/>
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>