Re: [SCITT] [EXT]Re: x5c or x5u

[Orie Steele <[e-mail]>]

Thanks to @Nikos Fotiou <[e-mail]> for sharing a relevant
response in the thread.

I updated our SCITT CLI to support x5c (possibly not correctly)...
Because I've not yet gotten clear guidance on how x5c should be verified,
I opted to put it as the protected header, verify using the protected
header attributes, and log the results as JSON.

https://github.com/transmute-industries/transmute/blob/main/examples/scitt/README.md#verifying-a-signed-statement-with-x5c

This means anything signed with x5c will always verify... this is also true
when you embed JWK in a protected header in JOSE....
I consider this to be unsafe default behavior, but I am not hearing any
better guidance.

In the code we use to generate certificates, we do allow for identifiers
(such as DIDs or URNs) to be present in the cert.

https://github.com/transmute-industries/transmute/blob/main/src/cli/scitt/certificate/create.ts

Verifying the x5c in the protected header does yield a list of "certs" or
"keys", that are either trusted or not trusted.

but they are the "presented identifiers", they are not "reference
identifiers"...

See also:
https://datatracker.ietf.org/doc/html/draft-ietf-uta-rfc6125bis-15#name-verifying-service-identity

I could be completely wrong about everything I just said.

I don't plan to implement x5u,
I don't think there are any software supply chain experts on this list
using it,
but it's possible that use cases for it exist in the wild elsewhere.

I'll ask the OpenSSF slack.

Regards,

OS


On Fri, Oct 27, 2023 at 1:41 PM Dick Brooks <
[e-mail]> wrote:

> Bob,
>
>
>
> SPDX V 2.3 refers to GitBom;
> https://spdx.github.io/spdx-spec/v2.3/how-to-use/#k15-linking-to-a-gitbom
>
>
>
> Does the SPDX spec contain an accurate representation of an OmniBOR
> software identity example:
>
>
>
> *K.1.5 Linking to a GitBOM*
>
> To reference to GitBOM <https://gitbom.dev> formatted security
> information applicable to a package see the example below.
>
> "externalRefs" : [ {
>
>   "referenceCategory" : "PERSISTENT-ID",
>
>   "referenceLocator" :
> "gitoid:blob:sha1:d8bcd58df2b14818b8237bb70c979d62c7df5747",
>
>   "referenceType" : "gitbom"
>
>   "referenceComment" : "GitBOM Object Id for the HeartBleed fix in
> ssl/d1_both.c"
>
> } ,
>
> {
>
>   "referenceCategory" : "PERSISTENT-ID",
>
>   "referenceLocator" :
> "gitoid:blob:sha1:bcb99b819dadaebdf2c8f88d92ee9024c45f9df3",
>
>   "referenceType" : "gitbom"
>
>   "referenceComment" : "GitBOM Object Id for the HeartBleed fix in
> ssl/t1_lib.c"
>
> } ]
>
>
>
>
>
>
>
> 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 *Martin, Robert A
> *Sent:* Friday, October 27, 2023 2:02 PM
> *To:* [e-mail]
> *Subject:* Re: [SCITT] [EXT]Re: x5c or x5u
>
>
>
> OmniBOR used to be call GitBOM I believe.
>
> Yep - https://omnibor.io/ "OmniBOR was formerly known as GitBOM."
>
> Bob
>
> Robert (Bob) Martin
>
> Sr. Software and Supply Chain Assurance Principal Eng.
>
> Cross Cutting Solutions and Innovation Dept
>
> Cyber Solutions Innovation Center
>
> MITRE Labs
>
> MITRE Corporation
>
> 781-271-3001o
>
> 781-424-4095c
>
> On 10/26/23 10:36 AM, Dick Brooks wrote:
>
> 😊 you won this one Charlie. I have no idea what OmniBOR is. • OmniBOR
> provides a strong starting point to pursue Inherent Identifiers. The
> biggest challenge will be fitting OmniBOR identifiers to the varying
> granularities of software
>
> 😊 you won this one Charlie. I have no idea what OmniBOR is.
>
>
>
>
>
> •                 OmniBOR provides a strong starting point to pursue
> Inherent Identifiers. The biggest challenge will be fitting OmniBOR
> identifiers to the varying granularities of software data artifacts that
> need to be annotated.
>
>
>
>
>
> 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]> <[e-mail]> *On
> Behalf Of *Hart, Charlie
> *Sent:* Thursday, October 26, 2023 10:10 AM
> *To:* 'Orie Steele' <[e-mail]>
> <[e-mail]>; [e-mail]
> *Cc:* 'Olle E. Johansson' <[e-mail]> <[e-mail]>; 'Manu
> Fontaine' <[e-mail]> <[e-mail]>; 'scitt'
> <[e-mail]> <[e-mail]>
> *Subject:* Re: [SCITT] [EXT]Re: x5c or x5u
>
>
>
> Going to finally beat Dick to the punch here on one of these news updates:
> CISA just released a software identification proposal for comment. This
> will potentially solve the problem of software identityt we spent a lot of
> time on email discussions a couple of weeks ago:
>
>
>
>
> https://www.cisa.gov/resources-tools/resources/software-identification-ecosystem-option-analysis
> ------------------------------
>
> *From:* SCITT <[e-mail]> on behalf of Dick Brooks <
> [e-mail]>
> *Sent:* Thursday, October 26, 2023 9:32 AM
> *To:* 'Orie Steele' <[e-mail]>
> *Cc:* 'Olle E. Johansson' <[e-mail]>; 'Manu Fontaine' <
> [e-mail]>; 'scitt' <[e-mail]>
> *Subject:* [EXT]Re: [SCITT] x5c or x5u
>
>
>
> My apologies. Please withdraw my response.
>
>
>
> 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://secure-web.cisco.com/1PYbHHDVHYKdrGxpsLufaaL78sJD84bjs8I31qpjn1RKjzcb6ero2h_4oQA7d5shbDsmwlFPRdH-9Os4XdDaQYdTNV8TtIuyNvm-8YFAgC-ZY3qDHY2TjiPlWFwCNaSeVSo08sp5eaiXG4PGmXa-LHR5QXjh4QBo6NBo4jaikibGIP1AVp-009JNoMWI5Y9jLxKfJ_w8q5xt6rqoDiMv9O7RRniWEfMMnbQNy8vU6BWd1DOTrSAopXc_-Dj4p9Oy6uhSs40lDnCyod_-TNpe-6jA9qBhTIpTywiE7bI48FJ2BrDYIkuUU_eMDuV7-_vxm/https%3A%2F%2Freliableenergyanalytics.com%2Fproducts>*
> ™
>
> http://www.reliableenergyanalytics.com
> <http://secure-web.cisco.com/1yAs9_RAhhlv4SiKnYSaI2msMD684I4n-5K-esxT9SqaVyH5FTrrm9RFULZfTeR4L-mMTtUrNF14eZFdVZaoxmRmz7foc4UICs8hK5dAgXlqXYHmbmTlk0tRE5FJa-5ZgwpRvJTWpQHLvIHw392ZnMmb_H5_cVti9ZQhRaX3f39CKfRPWY-gZbNrFkShJZt5gJladmoJbhyZ7SIiT0Ga9YNh1kCZ6_ZWvdmxxv9RssSd6khF6XohnPC0eO9lue1SRac1RuALZUcP_XVp0u7WUrJIhas6Gi77ociHCFGrkoJxrqa0xbmWB0chV2b-WvAlR/http%3A%2F%2Fwww.reliableenergyanalytics.com%2F>
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* Orie Steele <[e-mail]>
> *Sent:* Thursday, October 26, 2023 9:30 AM
> *To:* [e-mail]
> *Cc:* Olle E. Johansson <[e-mail]>; Manu Fontaine <[e-mail]>;
> scitt <[e-mail]>
> *Subject:* Re: [SCITT] x5c or x5u
>
>
>
> I was not looking for examples.
>
> I was looking for API guidance that could help us update our drafts.
>
> This is what I came up with:
>
> The "user / author / CI system service account verification key" as JWK
> with x5c.
>
> ~~~~ json
> {
>   "kty": "EC",
>   "x": "RFFp7pyHz8LNwfzv5Nm9Gj54KRena0ppOP97xwmk11qRks5ETTr4EPizXexJilPx",
>   "y": "DCRpyw6zW8nWeje3tl2KKObt9_vUBVD1uoSEp-kNRzYB3Hfo6DVRgSqE28l-nf1p",
>   "crv": "P-384",
>   "alg": "ES384",
>   "kid":
> "urn:ietf:params:oauth:jwk-thumbprint:sha-256:tsuna-Iyuwy4T_HuTuT8kTGGc7yqmiqinaWkWfmKuZY",
>   "x5t#S256": "y3aITzjZWqXeViSmaCmVyNTllEMkFUSrP3AidYCsR90",
>   "x5c": [
>     "MIIBtDCCAT...vSh7TpsjM=",
>     "MIIBvz...U7PTrX0LQ=="
>   ]
> }
> ~~~~
>
>
> The service identity verification key as COSE Key with x5c and x5t as
> private labels
>
> ~~~~ cbor-diag
>
> {                                   / COSE Key                      /
>
>   1: 2,                             / Type                          /
>
>   2: h'75726e3a...4b755a59',        / Identifier                    /
>
>   3: -35,                           / Algorithm                     /
>
>   -1: 2,                            / Curve                         /
>
>   -2: h'445169ee...498a53f1',       / x public key component        /
>
>   -3: h'0c2469cb...7e9dfd69',       / y public key component        /
>
>   -66667: h'cb76884f...80ac47dd',   / X.509 SHA-256 Thumbprint      /
>
>   -66666: [                         / X.509 Certificate Chain       /
>
>     h'308201b4...b4e9b233',         / X.509 Certificate             /
>
>     h'308201bf...4eb5f42d',         / X.509 Certificate             /
>
>   ],
>
> }
>
> ~~~~
>
>
>
> Here is some trash code I wrote to try to progress the drafts regarding
> x509:
>
> const publicKeyCose =
> cose.cbor.decode(fs.readFileSync('test/keys/x.509.user.publicKey.cose'))
> const privateKeyCose =
> cose.cbor.decode(fs.readFileSync('test/keys/x.509.user.privateKey.cose'))
> const statement = Buffer.from(JSON.stringify({ "hello": 'world' }))
> const signature = await cose.scitt.statement.issue({
>     iss: 'urn:example:123',
>     sub: 'urn:example:456',
>     cty: 'application/json',
>     x5c: publicKeyCose.get(-66666), // there is no cose key label for x5c
>     payload: statement,
>     secretCoseKey: privateKeyCose
> })
>
> // extract the x5c from cose sign 1 header
> const x5c = cose.scitt.statement.x5c(signature)
>
> // this allows us to pretend we are in the past
> // so validFrom and validUntil are acceptable
> const discoveryTime = new Date("2020/01/01 12:00")
>
> // check the certificate chain, produce verification keys
> const jwks = await verifyX5C('ES384', x5c, discoveryTime)
>
> // convert jwk key to cose key
> const verifiedCertificatePublicKey = cose.key.importJWK(jwks.keys[0])
>
> // verify the cose sign 1, with a key that is "trusted" per the verifyX5C
> process...
> const verified = await cose.scitt.statement.verify({
>     statement,
>     signedStatement: signature,
>     publicCoseKey: verifiedCertificatePublicKey
> })
> expect(verified).toBe(true)
>
>
>
> The cert chain verification code I used is probably horribly wrong,
>
> but I post it here so the record can show that I don't care about being
> wrong,
> ... and in case you all fail to point out the flaws now, you didn't know
> any better  : )
>
>
> const crypto = require('crypto');
> const x509 = require("@peculiar/x509");
> const jose = require('jose')
>
> // https://github.com/PeculiarVentures/x509
> <https://secure-web.cisco.com/1vKosKng8jG8YXqDoCTDYav_BZQQV-ZQcaWcf00vFTmP3eb_2nUPHHB5w-rJ3j_Wxtk7ZFcfq09NwoznUkW0kmIXlvyfjzv--rLvP6P4xBinhzB__vxlAyVYRfvKFfAnZ0HbQdlggljJvjBZjhe7UsGuBGr3Koz2ximZMR3yTGkRUIArKsa6ffUuYBYRzE9qCGFKWkMt7ciMBx_K1X0PmhuQqT5ZDyBEQzbU0ts-SbHTF4LbnCUJKnXvymfugi0XtnBAIN4sz6ih4KpR76xoCDSf2iqj6p5cktMzUEFBUgY0ayeVs2Yh-r6WFg0-k9wpC/https%3A%2F%2Fgithub.com%2FPeculiarVentures%2Fx509>
> x509.cryptoProvider.set(crypto);
>
> const x5t = (hash: string, cert: string) =>
> jose.base64url.encode(crypto.createHash(hash).update(Buffer.from(cert,
> 'base64')).digest())
>
> const verifyCertificateChain = async ({ alg, x5c }: any, date: Date) => {
>   const initialValue = {}
>   const accumulated = await x5c.reduce(
>     async (accumulator: any, currentValue: any, currentIndex: any) => {
>       const next = await accumulator;
>       const current = new x509.X509Certificate(currentValue)
>       const currentPublicKey = await jose.importX509(current.toString(),
> alg)
>       const currentPublicKeyJwk = await jose.exportJWK(currentPublicKey)
>       currentPublicKeyJwk.alg = alg
>       currentPublicKeyJwk.kid = await
> jose.calculateJwkThumbprintUri(currentPublicKeyJwk)
>       currentPublicKeyJwk['x5t#S256'] = x5t('sha256', currentValue);
>       currentPublicKeyJwk.x5c = x5c.slice(currentIndex, x5c.length)
>       next.keys = next.keys || [currentPublicKeyJwk]
>       // first key
>       if (next.previous === undefined) {
>         next.previous = currentValue;
>       } else {
>         const previous = new x509.X509Certificate(next.previous)
>         const verified = await previous.verify({
>           date, // verify as of date... defaults to now...
>           publicKey: await current.publicKey.export() // root public key
>         });
>         if (verified) {
>           next.keys.push(currentPublicKeyJwk)
>           next.previous = currentValue;
>         } else {
>           throw new Error('Failed to verify x5c.')
>         }
>       }
>       return next
>     },
>     initialValue
>   );
>   const root = new x509.X509Certificate(accumulated.previous)
>   const rootValid = await root.verify({ date });
>   const isSelfSigned = await root.isSelfSigned()
>   if (!isSelfSigned) {
>     throw new Error('Root certificate must be self signed.')
>   }
>   if (!rootValid) {
>     throw new Error('Root certificate failed to verify.')
>   }
>   delete accumulated.previous;
>   return accumulated
> }
>
> export const verifyX5C = async (alg: string, x5c: string[], discoveryTime:
> Date) => {
>   const jwks = await verifyCertificateChain({ alg, x5c }, discoveryTime)
>   return jwks
> }
>
>
>
> This is what the signature looks like:
>
>
>
> ~~~~ cbor-diag
>
> 18(                                 / COSE Sign 1                   /
>
>     [
>
>       h'a5182182...3a343536',       / Protected                     /
>
>       {},                           / Unprotected                   /
>
>      h'',                          / Detached payload              /
>
>       h'2e35d325...990e8c54'        / Signature                     /
>
>     ]
>
> )
>
> ~~~~
>
>
>
> ~~~~ cbor-diag
>
> {                                   / Protected                     /
>
>   33: [                             / X.509 Certificate Chain       /
>
>     h'308201b4...b4e9b233',         / X.509 Certificate             /
>
>     h'308201bf...4eb5f42d',         / X.509 Certificate             /
>
>   ],
>
>   1: -35,                           / Algorithm                     /
>
>   3: application/json,              / Content type                  /
>
>   4: h'75726e3a...4b755a59',        / Key identifier                /
>
>   13: {                             / CWT Claims                    /
>
>     1: urn:example:123,             / Issuer                        /
>
>     2: urn:example:456,             / Subject                       /
>
>   },
>
> }
>
> ~~~~
>
>
>
> Now tell me everything that is wrong with this.
>
> Regards,
>
> OS
>
>
>
>
>
> On Thu, Oct 26, 2023 at 7:47 AM Dick Brooks <
> [e-mail]> wrote:
>
> Olle,
>
>
>
> I’m not suggesting this be the only supported use case. I am suggesting it
> as one “real world” example of a x5c use case that we may want to consider
> as we discuss design options.
>
>
>
> Orie was looking for examples. This is a real example of an x5c chain of
> trust.
>
>
>
> 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://secure-web.cisco.com/1PYbHHDVHYKdrGxpsLufaaL78sJD84bjs8I31qpjn1RKjzcb6ero2h_4oQA7d5shbDsmwlFPRdH-9Os4XdDaQYdTNV8TtIuyNvm-8YFAgC-ZY3qDHY2TjiPlWFwCNaSeVSo08sp5eaiXG4PGmXa-LHR5QXjh4QBo6NBo4jaikibGIP1AVp-009JNoMWI5Y9jLxKfJ_w8q5xt6rqoDiMv9O7RRniWEfMMnbQNy8vU6BWd1DOTrSAopXc_-Dj4p9Oy6uhSs40lDnCyod_-TNpe-6jA9qBhTIpTywiE7bI48FJ2BrDYIkuUU_eMDuV7-_vxm/https%3A%2F%2Freliableenergyanalytics.com%2Fproducts>*
> ™
>
> http://www.reliableenergyanalytics.com
> <http://secure-web.cisco.com/1yAs9_RAhhlv4SiKnYSaI2msMD684I4n-5K-esxT9SqaVyH5FTrrm9RFULZfTeR4L-mMTtUrNF14eZFdVZaoxmRmz7foc4UICs8hK5dAgXlqXYHmbmTlk0tRE5FJa-5ZgwpRvJTWpQHLvIHw392ZnMmb_H5_cVti9ZQhRaX3f39CKfRPWY-gZbNrFkShJZt5gJladmoJbhyZ7SIiT0Ga9YNh1kCZ6_ZWvdmxxv9RssSd6khF6XohnPC0eO9lue1SRac1RuALZUcP_XVp0u7WUrJIhas6Gi77ociHCFGrkoJxrqa0xbmWB0chV2b-WvAlR/http%3A%2F%2Fwww.reliableenergyanalytics.com%2F>
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* Olle E. Johansson <[e-mail]>
> *Sent:* Thursday, October 26, 2023 8:36 AM
> *To:* [e-mail]
> *Cc:* Orie Steele <[e-mail]>; Manu Fontaine <
> [e-mail]>; scitt <[e-mail]>
> *Subject:* Re: [SCITT] x5c or x5u
>
>
>
>
>
>
>
> On 26 Oct 2023, at 13:54, Dick Brooks <[e-mail]>
> wrote:
>
>
>
> Orie,
>
>
>
> One excellent example of x5c digital signature verification takes place
> when a software product is being installed for Microsoft Windows. The
> signature chain is verified before a software product can be installed
> using the Microsoft Installer.
>
>
>
> I’m guessing some of our Microsoft colleagues can provide more details of
> the digital signature process used by the Microsoft installer.
>
>
>
> That is based on an EV Software SIgning Cert that is chained to the
> web-of-trust managed by the CAB forum. I know,
>
> because I’m a reseller of those certificates since many many years.
>
>
>
> Do we really want to hang the trust on that chain of trust? Are you aware
> of all the CAs you have in your trust store?
>
> If we can find another solution, I would appreciate it.
>
>
>
> The two main choices I see are basing it on CAB forum trust chains or the
> DNS. Any others?
>
>
>
> /O
>
>
>
> 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://secure-web.cisco.com/1PYbHHDVHYKdrGxpsLufaaL78sJD84bjs8I31qpjn1RKjzcb6ero2h_4oQA7d5shbDsmwlFPRdH-9Os4XdDaQYdTNV8TtIuyNvm-8YFAgC-ZY3qDHY2TjiPlWFwCNaSeVSo08sp5eaiXG4PGmXa-LHR5QXjh4QBo6NBo4jaikibGIP1AVp-009JNoMWI5Y9jLxKfJ_w8q5xt6rqoDiMv9O7RRniWEfMMnbQNy8vU6BWd1DOTrSAopXc_-Dj4p9Oy6uhSs40lDnCyod_-TNpe-6jA9qBhTIpTywiE7bI48FJ2BrDYIkuUU_eMDuV7-_vxm/https%3A%2F%2Freliableenergyanalytics.com%2Fproducts>*
>  ™
>
> http://www.reliableenergyanalytics.com
> <http://secure-web.cisco.com/1yAs9_RAhhlv4SiKnYSaI2msMD684I4n-5K-esxT9SqaVyH5FTrrm9RFULZfTeR4L-mMTtUrNF14eZFdVZaoxmRmz7foc4UICs8hK5dAgXlqXYHmbmTlk0tRE5FJa-5ZgwpRvJTWpQHLvIHw392ZnMmb_H5_cVti9ZQhRaX3f39CKfRPWY-gZbNrFkShJZt5gJladmoJbhyZ7SIiT0Ga9YNh1kCZ6_ZWvdmxxv9RssSd6khF6XohnPC0eO9lue1SRac1RuALZUcP_XVp0u7WUrJIhas6Gi77ociHCFGrkoJxrqa0xbmWB0chV2b-WvAlR/http%3A%2F%2Fwww.reliableenergyanalytics.com%2F>
>
> Email: [e-mail]
>
> Tel: [phone]
>
>
>
>
>
> *From:* SCITT <[e-mail]> *On Behalf Of *Orie Steele
> *Sent:* Thursday, October 26, 2023 7:50 AM
> *To:* Manu Fontaine <[e-mail]>
> *Cc:* Olle E. Johansson <[e-mail]>; scitt <[e-mail]>
> *Subject:* Re: [SCITT] x5c or x5u
>
>
>
> What is a good example of a verification API when x5c is present?
>
> Normally:
>
> verified = verify(message, signature, publicKey)
>
> But with x5c the message will always verify... What reference values are
> paired with the presented values to make the authentication check valid?
>
> Is it an allow list of trusted certificate root thumbprints?
>
> verified = verify(message, signature, trustedCertificateThumbprints) ?
>
> OS
>
>
>
> On Thu, Oct 26, 2023 at 4:24 AM Manu Fontaine <[e-mail]> wrote:
>
> Great points, Olle.
>
>
>
> FYI, we are developing a new approach to these problems. We leverage
> Confidential Computing to build a Universal Name System (UNS) and a
> Universal Certificate Authority (UCA). Both are fully end-to-end automated,
> with no human in the middle at all.
>
>
>
> Our perspective is that we need to solve the "global unified namespace"
> and "automated decentralized key management" problems first. Then
> everything else falls into place nicely. That's what we've been working on.
>
>
>
> I will be at IETF 118 Prague, and would love to meet with as many of
> you as possible. I am new to the IETF process and look forward to learning
> how to contribute what we have discovered through our work.
>
>
>
> Will you be there? Thanks!
>
> M
>
>
>
>
>
> On Thu, Oct 26, 2023, 4:01 AM Olle E. Johansson <[e-mail]> wrote:
>
> The whole signature part is a can of worms and everytime I ask the
> question in a software supply chain security context people seems to run
> away…
>
>
>
> We don’t want to base this on the current web of trust. x5u does that. I
> can have my own root that you trust because you
>
> trust the web of trust - the current CAs. Those are based on the DNS. Will
> it lead to an identifier we want and trust? Maybe.
>
>
>
> We can base it on DNSsec/DANE. But many don’t use it. That’s also based on
> DNS.
>
>
>
> We can base it on x5c - a standard PKI. But who certifies what in that PKI
> for a global solution?
>
>
>
> We have everything from corporations to public authorities and groups
> without any legal body producing artefacts.
>
>
>
> Easiest way out is to allow both x5c and x5u and possible x5dane if anyone
> registers it. Then we make
>
> the problem invisible by applying Douglas Adams’ SEP field to it and make
> it someone else’s problem to solve.
>
>
>
> Then my question is “who’s someone else”? …and now I see many run away… :-)
>
>
>
> /O
>
>
>
>
>
>
>
> On 25 Oct 2023, at 20:37, Orie Steele <[e-mail]> wrote:
>
>
>
> Hello,
>
>
> If SCITT has to support x509... does it have to support both x5c and x5u?
>
> Or just one?
>
> https://github.com/ietf-wg-scitt/draft-ietf-scitt-architecture/issues/125
> <https://secure-web.cisco.com/1JbANJDRMZbRsAaJBv17OZvpLgVzYA6nQwA5h5GO6FxE69PtflSgaFJPxiqVwS1LRC0WNTsl3thLK6HFxJCdqNusYBroPPf4vL6fUrKukKhE0zG90Qzeu9k1KgqiRbxvhSQ2dOWZZOPBg1qqZZqO7_z5Kbcm1DIF_5n4dAa1EfUMdyppjZ_v591gS0XvZhJD6JxefH2SuuGOWMlVqWMxrpWu4Omj3VUAsxSVLwf12fqyIA3ndNJzuWWrD5zGPCTJDLLgfA3gbFUCxqwXrUyHKA9yjCLgIP1rRSMxwxN6reDQpAnmiNbxvRCsF_qaWAgom/https%3A%2F%2Fgithub.com%2Fietf-wg-scitt%2Fdraft-ietf-scitt-architecture%2Fissues%2F125>
>
>
>
> Regards,
>
> OS
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
> <http://secure-web.cisco.com/1Ia2kXsQbsI97O6yW88o5xDtu5RvDgkaI5pJN6fUMbXFUQWtDg1vEa1I8psq2XT5WnA0QhMpNg_kaFmXkcPLCZxO2rcB1m3fGdNTpeimdcSvlkhAQOKDF_lDLFuclKv2Smo-koIlP5KkES-gPFN8u47Y5krH61Q_7OOkwBO-2QLiGy9PZQHfro3y8NApYohy6l3NAX0_2NrsRhTXE8sPSAWU5kaZLKpkIKWGuBw5zdxqcaIAJgxF4GJAbjmYtdTmXEr5eH9ZYYiN6HGigbi5LiFhcz6s8u84ewY3qUD93VRpWZ-5L2yQnXH5EPLeYJDBb/http%3A%2F%2Fwww.transmute.industries%2F>
>
>
> <https://secure-web.cisco.com/1_IyhCyYDLqhg5fQt57DtYE1xhKeF8eWcoG-qv8LBf1zNEe6bOtdrrMaifKJo3vmEGjxwnbCh71DEq-p7tSGAkwdlRDZP_4gDxhTGMHprHZmrkSEeLyuqu_LkYuwLOTTmHxpaa6hw_1BK7QVGPuTwgBHQ7bWKZZ6Qbgz1ViTJY_W8LRgq1jO_tb4e4pQpMbGS28vbxVqOUZNaSbKM3BzhR4EJYYBHl89pOfRXHZv4ZU85Mj8FoljQu-KWpPo64kpygkj4BsqVNBGT0i5vrUd9m-ZE4C9C01OoVke0s7SwM5-9Nyk84CpglyQt2dHV8O-V/https%3A%2F%2Ftransmute.industries%2F>
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
> <https://secure-web.cisco.com/1VoSgyVyBHSBuCGB0y-omhirPxbPPDrdqrv-5dhUlMgUPNe2oQRcF8_3WvEGLaqLjEGmFZSn7u26mYJDQmG2RB0BXWxFOJ3P4uOzhp-ftmz3N3mx9FZuAPbifY6lUuU0eMHL6dW_0AOhUlhYf4A1AD8iFNohbsZeSoK8-kt8167p45NyNzq6vl9H8Kh9rzzy5NP-mt7nI3i2c44yOtgXLpfkReu0kV4yTSZPbHvKvvGoCJQT-T-479i0lKsd_fwb1BJY4LVOnibOfklLNfvmn3QAgZ_2goW6N70vW6ciSdcvvhKA8bevUBMtHS1pviwJh/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscitt>
>
>
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
> <https://secure-web.cisco.com/1VoSgyVyBHSBuCGB0y-omhirPxbPPDrdqrv-5dhUlMgUPNe2oQRcF8_3WvEGLaqLjEGmFZSn7u26mYJDQmG2RB0BXWxFOJ3P4uOzhp-ftmz3N3mx9FZuAPbifY6lUuU0eMHL6dW_0AOhUlhYf4A1AD8iFNohbsZeSoK8-kt8167p45NyNzq6vl9H8Kh9rzzy5NP-mt7nI3i2c44yOtgXLpfkReu0kV4yTSZPbHvKvvGoCJQT-T-479i0lKsd_fwb1BJY4LVOnibOfklLNfvmn3QAgZ_2goW6N70vW6ciSdcvvhKA8bevUBMtHS1pviwJh/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscitt>
>
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
> <http://secure-web.cisco.com/1Ia2kXsQbsI97O6yW88o5xDtu5RvDgkaI5pJN6fUMbXFUQWtDg1vEa1I8psq2XT5WnA0QhMpNg_kaFmXkcPLCZxO2rcB1m3fGdNTpeimdcSvlkhAQOKDF_lDLFuclKv2Smo-koIlP5KkES-gPFN8u47Y5krH61Q_7OOkwBO-2QLiGy9PZQHfro3y8NApYohy6l3NAX0_2NrsRhTXE8sPSAWU5kaZLKpkIKWGuBw5zdxqcaIAJgxF4GJAbjmYtdTmXEr5eH9ZYYiN6HGigbi5LiFhcz6s8u84ewY3qUD93VRpWZ-5L2yQnXH5EPLeYJDBb/http%3A%2F%2Fwww.transmute.industries%2F>
>
>
> <https://secure-web.cisco.com/1_IyhCyYDLqhg5fQt57DtYE1xhKeF8eWcoG-qv8LBf1zNEe6bOtdrrMaifKJo3vmEGjxwnbCh71DEq-p7tSGAkwdlRDZP_4gDxhTGMHprHZmrkSEeLyuqu_LkYuwLOTTmHxpaa6hw_1BK7QVGPuTwgBHQ7bWKZZ6Qbgz1ViTJY_W8LRgq1jO_tb4e4pQpMbGS28vbxVqOUZNaSbKM3BzhR4EJYYBHl89pOfRXHZv4ZU85Mj8FoljQu-KWpPo64kpygkj4BsqVNBGT0i5vrUd9m-ZE4C9C01OoVke0s7SwM5-9Nyk84CpglyQt2dHV8O-V/https%3A%2F%2Ftransmute.industries%2F>
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
> <https://secure-web.cisco.com/1VoSgyVyBHSBuCGB0y-omhirPxbPPDrdqrv-5dhUlMgUPNe2oQRcF8_3WvEGLaqLjEGmFZSn7u26mYJDQmG2RB0BXWxFOJ3P4uOzhp-ftmz3N3mx9FZuAPbifY6lUuU0eMHL6dW_0AOhUlhYf4A1AD8iFNohbsZeSoK8-kt8167p45NyNzq6vl9H8Kh9rzzy5NP-mt7nI3i2c44yOtgXLpfkReu0kV4yTSZPbHvKvvGoCJQT-T-479i0lKsd_fwb1BJY4LVOnibOfklLNfvmn3QAgZ_2goW6N70vW6ciSdcvvhKA8bevUBMtHS1pviwJh/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscitt>
>
>
>
>
>
>
>
> --
>
>
>
>
> *ORIE STEELE*Chief Technology Officer
> www.transmute.industries
>
> [image: Image removed by sender.]
> <https://secure-web.cisco.com/1_IyhCyYDLqhg5fQt57DtYE1xhKeF8eWcoG-qv8LBf1zNEe6bOtdrrMaifKJo3vmEGjxwnbCh71DEq-p7tSGAkwdlRDZP_4gDxhTGMHprHZmrkSEeLyuqu_LkYuwLOTTmHxpaa6hw_1BK7QVGPuTwgBHQ7bWKZZ6Qbgz1ViTJY_W8LRgq1jO_tb4e4pQpMbGS28vbxVqOUZNaSbKM3BzhR4EJYYBHl89pOfRXHZv4ZU85Mj8FoljQu-KWpPo64kpygkj4BsqVNBGT0i5vrUd9m-ZE4C9C01OoVke0s7SwM5-9Nyk84CpglyQt2dHV8O-V/https%3A%2F%2Ftransmute.industries%2F>
>
>
>
> --
> SCITT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/scitt
>


-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>