[{"author": "Sean Turner", "text": "

Hi! If you need something spoken at the mic please preface it with \"mic:\"

", "time": "2024-03-18T07:32:03Z"}, {"author": "Sean Turner", "text": "

Hi! If you need something spoken at the mic please preface it with \"mic:\"

", "time": "2024-03-18T07:37:20Z"}, {"author": "Eric Rescorla", "text": "

I doubt that overloading x5u will work any better in terms of interop with the installed base, and might be slightly worse

", "time": "2024-03-18T07:48:05Z"}, {"author": "Orie Steele", "text": "

i suggest not overloading, and not offering multiple options

", "time": "2024-03-18T07:51:52Z"}, {"author": "Orie Steele", "text": "

if thats possible

", "time": "2024-03-18T07:51:57Z"}, {"author": "Ben Campbell", "text": "

Orie, is that for the \"mic:\"?

", "time": "2024-03-18T07:55:36Z"}, {"author": "Eric Rescorla", "text": "

https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.6

", "time": "2024-03-18T07:57:26Z"}, {"author": "Sean Turner", "text": "

he's sitting right to me ;)

", "time": "2024-03-18T07:57:36Z"}, {"author": "Alec Fenichel", "text": "

I was referring to x5u: https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.5

", "time": "2024-03-18T07:58:16Z"}, {"author": "Eric Rescorla", "text": "

Sorry, I keep forgettingto take myself off queue

", "time": "2024-03-18T07:59:04Z"}, {"author": "Alec Fenichel", "text": "

The example x5u URL in https://datatracker.ietf.org/doc/html/draft-peterson-stir-certificates-shortlived-05 should not should not end in \".cer\"

", "time": "2024-03-18T07:59:51Z"}, {"author": "Alec Fenichel", "text": "

Sorry, I copied the wrong URL, I meant OSCP document: https://www.ietf.org/archive/id/draft-ietf-stir-certificates-ocsp-07.html

", "time": "2024-03-18T08:00:37Z"}, {"author": "Sean Turner", "text": "

@Alec this bit from s5.1:

\n

{ \"typ\":\"passport\",
\n \"alg\":\"ES256\",
\n \"x5u\":\"https://www.example.com/cert.cer\" }

", "time": "2024-03-18T08:03:34Z"}, {"author": "Alec Fenichel", "text": "

@Sean yes

", "time": "2024-03-18T08:03:57Z"}, {"author": "Sean Turner", "text": "

got it!

", "time": "2024-03-18T08:05:12Z"}, {"author": "Alec Fenichel", "text": "

The trusted root list tells you which root certificates to trust. CT provides a log of every end entity certificate issued. Parties can monitor this log to know if a CA issued a certificate with their information that they didn't request. The point of CT is to detect rouge CA behavior.

", "time": "2024-03-18T08:07:23Z"}, {"author": "Sean Turner", "text": "

@Alec yep. One does not negate the need for the other.

", "time": "2024-03-18T08:08:48Z"}, {"author": "Alec Fenichel", "text": "

I think CT is needed for SPC (service provider) certificates.

", "time": "2024-03-18T08:09:46Z"}, {"author": "Simon Castle", "text": "

Ah, I understand now - thanks. (Sort of undermines the 'trusted' part of 'trusted CA list' but understand the fact that may be needed regardless)

", "time": "2024-03-18T08:10:09Z"}, {"author": "Alec Fenichel", "text": "

Yes, the point is to trust CAs less :)

", "time": "2024-03-18T08:10:38Z"}, {"author": "Victor Pascual", "text": "

is this the document that was just mentioned? https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-00

", "time": "2024-03-18T08:10:57Z"}, {"author": "Orie Steele", "text": "

KT monitoring deployment mode: https://datatracker.ietf.org/doc/html/draft-ietf-keytrans-architecture-01#name-contact-monitoring

", "time": "2024-03-18T08:10:58Z"}, {"author": "Russ Housley", "text": "

I just sent email to the stir mail llist about the format of x5u.

", "time": "2024-03-18T08:11:12Z"}, {"author": "Sean Turner", "text": "

Thanks Russ. You multitask well ;)

", "time": "2024-03-18T08:11:33Z"}, {"author": "Orie Steele", "text": "

SCITT helped COSE lift the proof system RFC9162, its currently being specified for COSE in https://datatracker.ietf.org/doc/draft-ietf-cose-merkle-tree-proofs/

", "time": "2024-03-18T08:14:36Z"}, {"author": "Simon Castle", "text": "

Chris mentioned he had a question that wanted resolving, whether we needed any mechanisms listed other than <something>. Anyone able to fill in what that <something> was for the notes? I missed it.

", "time": "2024-03-18T08:14:46Z"}, {"author": "Orie Steele", "text": "

in case you want just the \"SCT\" bit without the rest of 9162 that folks didn't implement.

", "time": "2024-03-18T08:15:03Z"}, {"author": "Eric Rescorla", "text": "

For those who are interested, some stuff on the logic of CT and similar systems https://educatedguesswork.org/posts/transparency-part-1/

", "time": "2024-03-18T08:18:13Z"}, {"author": "Eric Rescorla", "text": "

https://educatedguesswork.org/posts/transparency-part-2/

", "time": "2024-03-18T08:18:40Z"}, {"author": "Alec Fenichel", "text": "

The verification service must required the SCT to be in the cert. This prevents rouge CAs from just not logging the misused certs

", "time": "2024-03-18T08:18:56Z"}, {"author": "Orie Steele", "text": "

This use case is the same as SCITT use case for signed software binaries.

", "time": "2024-03-18T08:20:41Z"}, {"author": "Alec Fenichel", "text": "

Yes, new step that is mandatory

", "time": "2024-03-18T08:21:38Z"}, {"author": "Orie Steele", "text": "

See the architecture here: https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-06#name-transparent-statements

", "time": "2024-03-18T08:21:46Z"}, {"author": "Orie Steele", "text": "

+1 EKR

", "time": "2024-03-18T08:22:33Z"}, {"author": "Orie Steele", "text": "

as far as I can tell, the KT use case matches up with what is STIR is trying to achieve by looking at CT, but the monitor is either the device owner, or enterprises that provision numbers to devices.

", "time": "2024-03-18T08:26:47Z"}]