[{"author": "Jon Geater", "text": "

Hi Deb!

", "time": "2024-03-21T23:35:22Z"}, {"author": "Orie Steele", "text": "

should have gone with ascii art

", "time": "2024-03-21T23:38:40Z"}, {"author": "A.J. Stein", "text": "

PDF is everyone's form of supply chain artifact, bar none.

", "time": "2024-03-21T23:39:08Z"}, {"author": "Jon Geater", "text": "

Sorry Steve. Remember last time the animations really didn't work so I uploaded PDF. Didn't realise you needed the build :-/

", "time": "2024-03-21T23:39:10Z"}, {"author": "Orie Steele", "text": "

glad to see SCITT has solved the trust in internet content problem.. great work everyone... no work for spice.

", "time": "2024-03-21T23:43:33Z"}, {"author": "Michael Prorock", "text": "

orie, that was remarkably spicy

", "time": "2024-03-21T23:44:40Z"}, {"author": "Orie Steele", "text": "

with less snark... SPICE does focus on identity and credentials, but SCITT does not only work with COSE or JOSE based identitities, it also works with certs

", "time": "2024-03-21T23:44:47Z"}, {"author": "Michael Prorock", "text": "

https://datatracker.ietf.org/doc/html/rfc9162#name-merkle-consistency-proofs

", "time": "2024-03-21T23:49:55Z"}, {"author": "Christopher Inacio", "text": "

Thank you for posting the reference

", "time": "2024-03-21T23:51:47Z"}, {"author": "Jon Geater", "text": "

In the minutes now. Thanks Mike

", "time": "2024-03-21T23:52:05Z"}, {"author": "Deb Cooley", "text": "

suggestion: if you want review of a draft, then put it on the list.

", "time": "2024-03-21T23:52:47Z"}, {"author": "Michael Prorock", "text": "

I heard Brent Zundel volunteer to review consistency aspects

", "time": "2024-03-21T23:53:28Z"}, {"author": "Michael Prorock", "text": "

the draft needing review is here:
\nhttps://datatracker.ietf.org/doc/draft-ietf-cose-merkle-tree-proofs/

", "time": "2024-03-21T23:53:37Z"}, {"author": "A.J. Stein", "text": "

Michael Prorock said:

\n
\n

https://datatracker.ietf.org/doc/html/rfc9162#name-merkle-consistency-proofs

\n
\n

I thought we are talking about the cose draft, not the upstream reference from the CT spec (RFC 9162)? Nevermind, Mike sent it as I posted my message.

", "time": "2024-03-21T23:53:41Z"}, {"author": "Michael Prorock", "text": "

@AJ that is correct - but that draft needs eyes reviewing use of the upstream

", "time": "2024-03-21T23:54:14Z"}, {"author": "Orie Steele", "text": "

https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs

", "time": "2024-03-21T23:55:12Z"}, {"author": "Orie Steele", "text": "

This issue specifically: https://github.com/cose-wg/draft-ietf-cose-merkle-tree-proofs/issues/13

", "time": "2024-03-21T23:55:47Z"}, {"author": "Roman Danyliw", "text": "

+1 to Mike Prorock

", "time": "2024-03-21T23:57:09Z"}, {"author": "Orie Steele", "text": "

We have tried hard to align with RATS and OAUTH

", "time": "2024-03-21T23:57:34Z"}, {"author": "Orie Steele", "text": "

it would be nice if they aligned with eachother

", "time": "2024-03-21T23:57:42Z"}, {"author": "A.J. Stein", "text": "

I would assert we still need to clean up terminology usage.

", "time": "2024-03-21T23:57:52Z"}, {"author": "Orie Steele", "text": "

Naming remains hard

", "time": "2024-03-21T23:58:22Z"}, {"author": "Michael Prorock", "text": "

commence humming

", "time": "2024-03-21T23:59:05Z"}, {"author": "Michael Prorock", "text": "

could feed / subject be covered in a separate doument?

", "time": "2024-03-22T00:01:33Z"}, {"author": "A.J. Stein", "text": "

Michael Prorock said:

\n
\n

could feed / subject be covered in a separate doument?

\n
\n

I'd hope, because there is very minimal references in the arch spec in edits from 118->119.

", "time": "2024-03-22T00:03:42Z"}, {"author": "Orie Steele", "text": "

Request to cite NIST 800-63 regarding issuer and subject.

", "time": "2024-03-22T00:04:35Z"}, {"author": "Orie Steele", "text": "

from Justin at the mic line, which I agree with..

", "time": "2024-03-22T00:05:12Z"}, {"author": "Michael Prorock", "text": "

+1 to cite 800-63c

", "time": "2024-03-22T00:05:38Z"}, {"author": "Michael Prorock", "text": "

https://pages.nist.gov/800-63-3/sp800-63c.html

", "time": "2024-03-22T00:06:27Z"}, {"author": "Mike Ounsworth", "text": "

Hi. Tourist here. Is it in-scope for SCITT to define globally unique subject identifiers? IE does SCITT solve the problem of knowing whether two Issuers are talking about the same Subject?

", "time": "2024-03-22T00:06:29Z"}, {"author": "Michael Prorock", "text": "

out of scope i think @Mike O

", "time": "2024-03-22T00:06:44Z"}, {"author": "A.J. Stein", "text": "

OK, I retract my question, I understand now.

", "time": "2024-03-22T00:06:57Z"}, {"author": "Michael Richardson", "text": "

The IESG is not keen on publishing UseCase Documents (each RFC has a $50K price tag in people effort), but encourages us to write down use cases. We can easily pull that text into the protocol/architecture/etc. documents.

", "time": "2024-03-22T00:07:06Z"}, {"author": "A.J. Stein", "text": "

Ignore my misunderstanding of the word publication, ignore me! (I now understand but I was confused by the WGLC but you all reminded me of process stuffs, I stop.)

", "time": "2024-03-22T00:07:09Z"}, {"author": "Michael Richardson", "text": "

In RATS, we did two use case documents, then merged them into Architecture, which became RFC9334, for instance.

", "time": "2024-03-22T00:07:42Z"}, {"author": "Michael Prorock", "text": "

+1 Orie

", "time": "2024-03-22T00:07:47Z"}, {"author": "A.J. Stein", "text": "

I am confused by SCRAPI slide 20/35, we are saying this is an example of something signed?

", "time": "2024-03-22T00:15:52Z"}, {"author": "Orie Steele", "text": "

This is an optional endpoint that shows how to issue CWT on behalf on the issuer

", "time": "2024-03-22T00:16:22Z"}, {"author": "Orie Steele", "text": "

Jon said everything i would have

", "time": "2024-03-22T00:16:46Z"}, {"author": "A.J. Stein", "text": "

Have we actually adjusted our security considerations for this?

", "time": "2024-03-22T00:16:53Z"}, {"author": "Justin Richer", "text": "

subject/issuer reference in GNAP: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-20.html#section-3.4-11

", "time": "2024-03-22T00:17:08Z"}, {"author": "Orie Steele", "text": "

I just merged the PR that updated security considerations

", "time": "2024-03-22T00:17:11Z"}, {"author": "Orie Steele", "text": "

so they are in editors draft, but not on data tracker yet

", "time": "2024-03-22T00:17:25Z"}, {"author": "A.J. Stein", "text": "

Orie Steele said:

\n
\n

I just merged the PR that updated security considerations

\n
\n

I hate when you address the concerns in my questions, stop that! lol

", "time": "2024-03-22T00:17:35Z"}, {"author": "Michael Prorock", "text": "

:)

", "time": "2024-03-22T00:17:51Z"}, {"author": "Steve Lasker", "text": "
\n

Justin Richer
\n10:17
\nsubject/issuer reference in GNAP: https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-20.html#section-3.4-11

\n
", "time": "2024-03-22T00:20:59Z"}, {"author": "Steve Lasker", "text": "

added to the notes

", "time": "2024-03-22T00:21:05Z"}, {"author": "Orie Steele", "text": "

TLDR: DIDs are deprecated in SCITT, you don't need to use them.

", "time": "2024-03-22T00:22:23Z"}, {"author": "Jon Geater", "text": "

:+1:

", "time": "2024-03-22T00:23:14Z"}, {"author": "Orie Steele", "text": "

Speaking of terminology alignment... We will update all uses of endpoints to \"resources\"... even for \"controller style\" REST endpoints ; )

", "time": "2024-03-22T00:24:03Z"}, {"author": "Tim Hollebeek", "text": "

Just wait until someone suggests the \"new technology\" replacement, DID-NT.

", "time": "2024-03-22T00:24:34Z"}, {"author": "A.J. Stein", "text": "

Orie Steele said:

\n
\n

Speaking of terminology alignment... We will update all uses of endpoints to \"resources\"... even for \"controller style\" REST endpoints ; )

\n
\n

Sorry for the notes, they were done or are done.

", "time": "2024-03-22T00:24:36Z"}, {"author": "Thomas McCarthy-Howe", "text": "

I was raising my hand

", "time": "2024-03-22T00:25:05Z"}, {"author": "Orie Steele", "text": "

Monty said he will review

", "time": "2024-03-22T00:25:15Z"}, {"author": "Roy Williams", "text": "

I will commit to reviewing Scrapi

", "time": "2024-03-22T00:25:31Z"}, {"author": "Thomas McCarthy-Howe", "text": "

Do you need another implementation?

", "time": "2024-03-22T00:25:50Z"}, {"author": "Jon Geater", "text": "

Thanks Roy! And yes please Thomas, all are welcome, emulators, real ones, anything to prove interop

", "time": "2024-03-22T00:26:27Z"}, {"author": "Jon Geater", "text": "

RESOURCE!

", "time": "2024-03-22T00:27:04Z"}, {"author": "Thomas McCarthy-Howe", "text": "

The vCon angle for this is pretty interesting.

", "time": "2024-03-22T00:27:26Z"}, {"author": "A.J. Stein", "text": "

So we're not cool with endsourcepointing?

", "time": "2024-03-22T00:27:27Z"}, {"author": "Michael Prorock", "text": "

we love interop test suites personally, especially for resources

", "time": "2024-03-22T00:27:40Z"}, {"author": "Ran Atkinson", "text": "

I believe that interoperability testing would be interesting. The history of conformance testing indicates that multiple conforming implementations might not interoperate.

", "time": "2024-03-22T00:28:14Z"}, {"author": "Orie Steele", "text": "

feel free to go to the mic to talk about vCon as a signed statement, or scitt documents vCon attachements : )

", "time": "2024-03-22T00:29:16Z"}, {"author": "Thomas McCarthy-Howe", "text": "

:)

", "time": "2024-03-22T00:30:02Z"}, {"author": "Orie Steele", "text": "

in JOSE, we sometimes publish cookbooks, I started working on one for HPKE to help implementers: https://datatracker.ietf.org/doc/draft-steele-jose-cose-hpke-cookbook/

", "time": "2024-03-22T00:30:17Z"}, {"author": "Ran Atkinson", "text": "

+1 to cite NIST SP800-63c

", "time": "2024-03-22T00:31:22Z"}, {"author": "Steve Lasker", "text": "

^, thanks for teh pointer, it's added to the notes

", "time": "2024-03-22T00:31:49Z"}, {"author": "A.J. Stein", "text": "

It was the end of the first at 9 PM on a Saturday, but who's counting? lol (I cracked open the second at 10 PM.)

", "time": "2024-03-22T00:35:28Z"}, {"author": "Orie Steele", "text": "

Its in the editors drat

", "time": "2024-03-22T00:36:23Z"}, {"author": "Orie Steele", "text": "

https://ietf-wg-scitt.github.io/draft-ietf-scitt-scrapi/draft-ietf-scitt-scrapi.html

", "time": "2024-03-22T00:36:48Z"}, {"author": "Deb Cooley", "text": "

meetecho: can you move the speaker's camera to the presenter?

", "time": "2024-03-22T00:37:30Z"}, {"author": "A.J. Stein", "text": "

You miss this when remote, this DigiCert thing seems rad, nice work.

", "time": "2024-03-22T00:37:50Z"}, {"author": "Orie Steele", "text": "

it was awesome

", "time": "2024-03-22T00:38:09Z"}, {"author": "Orie Steele", "text": "

what you really missed was the snarky chats about the concisenss of x5chain vs CWT and JWT chains

", "time": "2024-03-22T00:38:42Z"}, {"author": "Orie Steele", "text": "

which spilled over into COSE WG presentations later in the week

", "time": "2024-03-22T00:39:06Z"}, {"author": "A.J. Stein", "text": "

Orie Steele said:

\n
\n

what you really missed was the snarky chats about the concisenss of x5chain vs CWT and JWT chains

\n
\n

Well he seems accepting of the feedback from his perspective. :laughing:

", "time": "2024-03-22T00:39:25Z"}, {"author": "Orie Steele", "text": "

my favorite thing they figured out how to do here, was put the giant bucket of certs in the unprotected header, so its not necessary store it forever

", "time": "2024-03-22T00:39:46Z"}, {"author": "Orie Steele", "text": "

really awesome use of unprotected header

", "time": "2024-03-22T00:40:00Z"}, {"author": "Orie Steele", "text": "

we keep getting reminded of the benefits of COSE unprotected headers, which is validating

", "time": "2024-03-22T00:40:30Z"}, {"author": "A.J. Stein", "text": "

Orie Steele said:

\n
\n

my favorite thing they figured out how to do here, was put the giant bucket of certs in the unprotected header, so its not necessary store it forever

\n
\n

How big does this bucket make it?

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

big

", "time": "2024-03-22T00:41:09Z"}, {"author": "Orie Steele", "text": "

I don't understand the choice of \"-16\" here

", "time": "2024-03-22T00:42:41Z"}, {"author": "Orie Steele", "text": "

we should follow up offline on that

", "time": "2024-03-22T00:42:49Z"}, {"author": "Michael Prorock", "text": "

correct - that looks odd to me

", "time": "2024-03-22T00:42:58Z"}, {"author": "A.J. Stein", "text": "

We could start modeling our meetings and queue feedback as a TS instance, couldn't we? Then we'll all know Hannes is Hannes and he said so.

", "time": "2024-03-22T00:44:36Z"}, {"author": "Christopher Inacio", "text": "

Can remote here Steve?

", "time": "2024-03-22T00:45:27Z"}, {"author": "Jon Geater", "text": "

Yes I could hear him

", "time": "2024-03-22T00:45:59Z"}, {"author": "A.J. Stein", "text": "

Can we flog Orie for mentioning Jenkins? It's been six months since I last heard about it and now I am mad and sad.

", "time": "2024-03-22T00:47:43Z"}, {"author": "Michael Prorock", "text": "

i had serious flashbacks - thanks orie

", "time": "2024-03-22T00:48:29Z"}, {"author": "Mike Ounsworth", "text": "

+1 to Corey: remote signing services are good for smaller dev shops that don't want to manage their own HSMs.

", "time": "2024-03-22T00:49:22Z"}, {"author": "Orie Steele", "text": "

Another interesting dimension of remote signing is using remote KMS systems, which don't necessarily support certificates... and that connects to the credential and identity discussions and SPICE

", "time": "2024-03-22T00:50:53Z"}, {"author": "Orie Steele", "text": "

you can't just drop in a remote KMS API, into the place were you might drop in a remote code signing service, without considering identity and identifiers carefully

", "time": "2024-03-22T00:51:46Z"}, {"author": "Michael Prorock", "text": "

cheers

", "time": "2024-03-22T00:53:08Z"}, {"author": "Orie Steele", "text": "

cheers ADs

", "time": "2024-03-22T00:53:14Z"}, {"author": "Corey Bonnell", "text": "

I am willing to review the architecture doc

", "time": "2024-03-22T00:56:26Z"}, {"author": "Michael Prorock", "text": "

brent zundel raised his hand for record notes

", "time": "2024-03-22T00:56:29Z"}, {"author": "A.J. Stein", "text": "

Michael Prorock said:

\n
\n

brent zundel raised his hand for record notes

\n
\n

One or all for Brent? How mean can I be?

", "time": "2024-03-22T00:56:46Z"}, {"author": "Michael Prorock", "text": "

lol, sorry for review task ;)

", "time": "2024-03-22T00:57:13Z"}, {"author": "Michael Prorock", "text": "

on architecture

", "time": "2024-03-22T00:57:21Z"}, {"author": "Roy Williams", "text": "

I have gone through the Architecture doc and there is some nits or concept references that I want to will send to the mailing list.

", "time": "2024-03-22T00:57:35Z"}, {"author": "Michael Prorock", "text": "

+1 roy - welcome your feedback

", "time": "2024-03-22T00:57:47Z"}, {"author": "Jon Geater", "text": "

Thanks Roy

", "time": "2024-03-22T00:58:02Z"}, {"author": "A.J. Stein", "text": "

I am talking about the next generation of Certificate Transparency:

\n
    \n
  1. sunlight.dev (next generation of RFC9162 version of CT)
  2. \n
  3. a deriviative of that (LiteLogs), from the author of the item above
  4. \n
  5. IETF keytrans work of course
  6. \n
\n

I was talking about 1 and 2 but didn't forget 3

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

See also https://transparency.dev/

", "time": "2024-03-22T01:01:53Z"}, {"author": "A.J. Stein", "text": "

Orie Steele said:

\n
\n

See also https://transparency.dev/

\n
\n

Good call, 1 and 2, are \"housed\" under that.

", "time": "2024-03-22T01:02:21Z"}, {"author": "Michael Prorock", "text": "

henk, that requires treating other people with mutual respect and as another equal human being, even if you disagree with them

", "time": "2024-03-22T01:03:23Z"}, {"author": "A.J. Stein", "text": "

I know this is well outside the scope of \"what the WG\" does but I am not sure in future IETF meetings we need a compare/contrast presentation or invite them to collab with us \"over here\" or over there, I am willing to volunteer or contribute on that front.

", "time": "2024-03-22T01:03:44Z"}]