[{"author": "Mike Ounsworth", "text": "

Hi

", "time": "2024-03-19T07:41:59Z"}, {"author": "Orie Steele", "text": "

hi

", "time": "2024-03-19T07:42:14Z"}, {"author": "Britta Hale", "text": "

Hiiiii

", "time": "2024-03-19T07:42:46Z"}, {"author": "John Gray", "text": "

Hello

", "time": "2024-03-19T07:42:58Z"}, {"author": "Sofia Celi", "text": "

hi haha

", "time": "2024-03-19T07:42:58Z"}, {"author": "Aritra Banerjee", "text": "

Hellooo

", "time": "2024-03-19T07:43:08Z"}, {"author": "Ben S", "text": "

Salutations

", "time": "2024-03-19T07:43:18Z"}, {"author": "Hendrik Brockhaus", "text": "

Moin

", "time": "2024-03-19T07:43:55Z"}, {"author": "Sofia Celi", "text": "

yes

", "time": "2024-03-19T07:50:32Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Maybe include \"signatures\" in the title to better represent the content?

", "time": "2024-03-19T07:50:55Z"}, {"author": "Florence D", "text": "

I really like the idea of the flow chart and it'll be helpful, but I think it's missing a \"why\" at the minute. I want to know why the lines flow where they do.

", "time": "2024-03-19T07:51:01Z"}, {"author": "Sofia Celi", "text": "

the minutes in case someone want to contribute as well:https://notes.ietf.org/notes-ietf-119-pquip?view

", "time": "2024-03-19T07:51:46Z"}, {"author": "Rich Salz", "text": "

I think \"decision tree\" is a better description than flowchart.

", "time": "2024-03-19T07:52:12Z"}, {"author": "Michael Prorock", "text": "

can we call it AI?

", "time": "2024-03-19T07:52:48Z"}, {"author": "John Gray", "text": "

Good point Rich, I like decision tree as well.

", "time": "2024-03-19T07:53:06Z"}, {"author": "Sofia Celi", "text": "

great memes

", "time": "2024-03-19T07:53:30Z"}, {"author": "Michael Prorock", "text": "

in seriousness - decision tree is a good term for those

", "time": "2024-03-19T07:53:32Z"}, {"author": "Florence D", "text": "

Decision tree is a good term. I still would like to understand why I'm being led to certain decisions (what's there is already useful)

", "time": "2024-03-19T07:54:27Z"}, {"author": "Michael Prorock", "text": "

+1

", "time": "2024-03-19T07:54:42Z"}, {"author": "Orie Steele", "text": "

Mike P... reminds me of XMLDateTime vs unix time in verifiable credentials.

", "time": "2024-03-19T07:54:43Z"}, {"author": "Orie Steele", "text": "

time is not as easy as we all wish it was.

", "time": "2024-03-19T07:55:00Z"}, {"author": "Michael Prorock", "text": "

@orie don't remind me

", "time": "2024-03-19T07:55:02Z"}, {"author": "Stephen Farrell", "text": "

WRT the stateful HBS doc, does anyone know of any open source implementation that does all that well? If that existed, might be a good ref

", "time": "2024-03-19T07:55:58Z"}, {"author": "Michael Prorock", "text": "

re decision tree, and flo's comment - why would be good - also maybe some guidance for systems going into production at some future date

", "time": "2024-03-19T07:56:07Z"}, {"author": "Thom Wiggers", "text": "

Stephen Farrell said:

\n
\n

WRT the stateful HBS doc, does anyone know of any open source implementation that does all that well? If that existed, might be a good ref

\n
\n

that would be great, but I'm not familiar with anything... Unfortunately, there's a lot of results that strongly suggest that there may not be a way to do things \"well\" on commodity hardware even...

", "time": "2024-03-19T07:57:09Z"}, {"author": "Stephen Farrell", "text": "

bummer;-(

", "time": "2024-03-19T07:57:29Z"}, {"author": "Thom Wiggers", "text": "

(in general, it appears general computers don't really have a super reliable way to commit writes to disk)

", "time": "2024-03-19T07:58:18Z"}, {"author": "Rohan Mahy", "text": "

which of these would cross signed certs fall under?

", "time": "2024-03-19T07:59:24Z"}, {"author": "Michael Prorock", "text": "

this binding diagram is great

", "time": "2024-03-19T07:59:35Z"}, {"author": "Britta Hale", "text": "

Thank you!

", "time": "2024-03-19T08:00:02Z"}, {"author": "Britta Hale", "text": "

@Rohan: cross-signed certs would be most linked to the linked parallel (although these are for sig and that is certs). Basically, each sig is covers something attesting to the other.

", "time": "2024-03-19T08:01:32Z"}, {"author": "Jonathan Hammell", "text": "

Just don't use the CMS Signing Time attribute on a leap day.

", "time": "2024-03-19T08:07:32Z"}, {"author": "Tadahiko Ito", "text": "

I was thinking that it is for signing procedure, but is it about set of signing and verification procedure?

", "time": "2024-03-19T08:07:33Z"}, {"author": "Stephen Farrell", "text": "

CMS being so feature-rich is a bit of a double-edged sword though, not clear multiple implementations would all support the same stuff afaik (but open to correction)

", "time": "2024-03-19T08:11:10Z"}, {"author": "John Gray", "text": "

In CMS it comes down to the application layer verifiers policy, and if different implementations have different verifier policies that are supposed to work together then watch out...

", "time": "2024-03-19T08:13:53Z"}, {"author": "Jonathan Hammell", "text": "

The improved interoperability through IETF registry control for composite assumes explicit composite identifiers. Composite had been defined generically in the past and that did not control the allowed combinations.

", "time": "2024-03-19T08:15:37Z"}, {"author": "Britta Hale", "text": "

@Aron Wussler : Do you want to drop information here on where (meeting WG / connection information) that discussion tomorrow morning will be at?

", "time": "2024-03-19T08:16:59Z"}, {"author": "Tadahiko Ito", "text": "

if it were application layer policy, we may treat and mode and or mode together?

", "time": "2024-03-19T08:18:05Z"}, {"author": "Daniel Van Geest", "text": "

MUST on that second point? :)

", "time": "2024-03-19T08:18:10Z"}, {"author": "Aron Wussler", "text": "

OpenPGP WG will have a heated discussion at 9:30 AM (local time) tomorrow about how to link composite signatures (which layer, security properties)

", "time": "2024-03-19T08:18:30Z"}, {"author": "Michael Prorock", "text": "

stephen said it better

", "time": "2024-03-19T08:20:22Z"}, {"author": "Rohan Mahy", "text": "

+1 that we don't need every combination. but 1 or 2 is unrealistically little

", "time": "2024-03-19T08:23:06Z"}, {"author": "Stephen Farrell", "text": "

heh, I didn't say I used all my arguments there:-)

", "time": "2024-03-19T08:23:11Z"}, {"author": "Rich Salz", "text": "

Can IRTF create IANA registries? I don't think so.

", "time": "2024-03-19T08:24:33Z"}, {"author": "Stephen Farrell", "text": "

@rich, yes that's happened

", "time": "2024-03-19T08:24:54Z"}, {"author": "Stephen Farrell", "text": "

e.g. HPKE

", "time": "2024-03-19T08:25:10Z"}, {"author": "Michael Prorock", "text": "

+1

", "time": "2024-03-19T08:25:25Z"}, {"author": "Rich Salz", "text": "

Thanks for the correction.

", "time": "2024-03-19T08:25:26Z"}, {"author": "Britta Hale", "text": "

A consideration for having binding above the crypto algorithm layer is that signature security vs protocol security will no longer be a modular analysis. I.e., analysis of TLS, QUIC, etc. is normally based on signatures satisfying certain properties (e.g., EUF-CMA). If the signature scheme security has to be based on the security of the protocol use, there is the potential for circular reasoning arguments. ... i.e., it is wise to tread carefully.

", "time": "2024-03-19T08:26:05Z"}, {"author": "Aron Wussler", "text": "

Stephen Farrell said:

\n
\n

heh, I didn't say I used all my arguments there:-)

\n
\n

Hehehehe, but IMO combinations are far less scary on the protocol level...

", "time": "2024-03-19T08:26:17Z"}, {"author": "Florence D", "text": "

I agree with Mike. It's about building from security properties but also other properties e.g. backwards compatibility, compliance, practicality given protocol etc.

", "time": "2024-03-19T08:28:16Z"}, {"author": "Thom Wiggers", "text": "

remote attendance helps :)

", "time": "2024-03-19T08:28:17Z"}]