[{"author": "Michael Richardson", "text": "

:mouse_trap:

", "time": "2023-11-08T13:30:16Z"}, {"author": "Sean Turner", "text": "

thanks Rich!

", "time": "2023-11-08T13:31:42Z"}, {"author": "Mike Ounsworth", "text": "

Michael Richardson said:

\n
\n

:mouse_trap:

\n
\n

Mouse trap? Was that meant for the RATS channel?

", "time": "2023-11-08T13:34:48Z"}, {"author": "Sean Turner", "text": "

:cheese:

", "time": "2023-11-08T13:35:49Z"}, {"author": "Rich Salz", "text": "

@Sean Turner which drafts are you most interested in, I'll let you know when we're one or two before them.

", "time": "2023-11-08T13:36:01Z"}, {"author": "Sean Turner", "text": "

I'm doing part of the CMCbis drafts presentationn.

", "time": "2023-11-08T13:36:38Z"}, {"author": "Rich Salz", "text": "

so the rfc5990bis topic?

", "time": "2023-11-08T13:37:41Z"}, {"author": "Sean Turner", "text": "

item 7b on the agenda :)

", "time": "2023-11-08T13:38:23Z"}, {"author": "Rich Salz", "text": "

oh dunh. okay, i'll let you know when we're at 6e or so

", "time": "2023-11-08T13:39:01Z"}, {"author": "Sean Turner", "text": "

thanks

", "time": "2023-11-08T13:39:58Z"}, {"author": "Michael StJohns", "text": "

There isn\u2019t any reason you can\u2019t do that, but where you put the certs (of just the certs for a given evidence statement) starts to permit a complex set of choice with the increase in the number of evidence statements. I\u2019d like the encoding to have two properties: 1) SHOULD NOT result in duplication of certificates ; 2) any given encoder when presented with identical data SHOULD produce identical encodings. Hide and seek on the part of the receiver will not make anyone happy.

", "time": "2023-11-08T13:52:07Z"}, {"author": "Mike Ounsworth", "text": "

In regards to Falko's presentation.
\nAre we discussing the case where an email comes in, fails to decrypt properly, displays all garbled, so I hit Reply-All and say \"Hey, something wrong with your email, please send again\", and my MUA helpfully attaches the failed-to-decrypt content in the forwarded blob ?

", "time": "2023-11-08T13:52:18Z"}, {"author": "Michael StJohns", "text": "

Sorry this was a reply to the message above. Zulip on an iPad is not obvious

", "time": "2023-11-08T13:53:11Z"}, {"author": "Daniel Gillmor", "text": "

Mike Ounsworth said:

\n
\n

Are we discussing the case where an email comes in, fails to decrypt properly, displays all garbled, so I hit Reply-All and say \"Hey, something wrong with your email, please send again\", and my MUA helpfully attaches the failed-to-decrypt content in the forwarded blob ?

\n
\n

Yep, that's one form of the oracle, mike. probably the most obvious form. But the attack applies to anywhere there's an oracle.

", "time": "2023-11-08T13:56:11Z"}, {"author": "Daniel Gillmor", "text": "

a sensible MUA won't do that, of course. but the overlap between \"sensible\" and \"MUA\" is \u2026 let's say a proper subset of each set.

", "time": "2023-11-08T13:56:54Z"}, {"author": "Dan Harkins", "text": "

using AES-SIV would address this attack as well

", "time": "2023-11-08T13:59:23Z"}, {"author": "Daniel Gillmor", "text": "

please no please no please no middlebox transformations between CMS and COSE

", "time": "2023-11-08T14:00:03Z"}, {"author": "Rich Salz", "text": "

Daniel Gillmor said:

\n
\n

please no please no please no middlebox transformations between CMS and COSE

\n
\n

Agree. More specifically, no transformation without explicitly sharing the key material

", "time": "2023-11-08T14:01:59Z"}, {"author": "Hubert Kario", "text": "

+1; the key should be as strictly linked to the context as possible

", "time": "2023-11-08T14:03:05Z"}, {"author": "Mike Ounsworth", "text": "

I would hope that even if you're doing a CMS-to-COSE middlebox, that you have separate encryption keys / certs for S/MIME and COSE, which should thwart the attack, right? I live in hope.

", "time": "2023-11-08T14:05:25Z"}, {"author": "Simon Friedberger", "text": "

@Mike Ounsworth There are examples for oracles from MUAs in efail if you're curious. Mostly section 6 and 7.

", "time": "2023-11-08T14:06:48Z"}, {"author": "Yoav Nir", "text": "

I mean, if you don't see \"30\" and think \"sequence-of\", what are you really doing?

", "time": "2023-11-08T14:07:18Z"}, {"author": "Simon Friedberger", "text": "

@Daniel Gillmor To get back to your earlier point, I don't have enough background here but, is there any other date that should be included?

", "time": "2023-11-08T14:07:41Z"}, {"author": "Deb Cooley", "text": "

@Yoav - +1

", "time": "2023-11-08T14:07:43Z"}, {"author": "Yoav Nir", "text": "

(deleted)

", "time": "2023-11-08T14:09:20Z"}, {"author": "Deirdre Connolly", "text": "

<stark> AES-SIV would be nice

", "time": "2023-11-08T14:09:54Z"}, {"author": "David Benjamin", "text": "

Shameless plug for https://github.com/google/der-ascii if you, like me, spend too much of your life having to encode and decode DER on sight. :-)

", "time": "2023-11-08T14:10:37Z"}, {"author": "Deirdre Connolly", "text": "

:laughing:

", "time": "2023-11-08T14:11:58Z"}, {"author": "Rich Salz", "text": "

BTW, I think Russ died just write the bytes down in his head. Maybe he went back and calculated the lengths, but still...

", "time": "2023-11-08T14:12:45Z"}, {"author": "Michael StJohns", "text": "

How does a receiver tell the difference between a message whose sender doesn\u2019t implement this, and a message where the attacker removed the tag? This is a transition question between now and when it\u2019s expected

", "time": "2023-11-08T14:12:46Z"}, {"author": "John Gray", "text": "

If there are usecases for context separation between COSE, JOSE and S/MIME then define a cross validation salt value, along with ones for everyone else.

", "time": "2023-11-08T14:12:58Z"}, {"author": "Daniel Gillmor", "text": "

Simon Friedberger said:

\n
\n

Daniel Gillmor To get back to your earlier point, I don't have enough background here but, is there any other date that should be included?

\n
\n

I don't understand S/MIME, CMS, or X.509 well enough to know what additional data should be included in the KDF. In TLS we just stopped trying to figure that out and included the full transcript in the KDF.

", "time": "2023-11-08T14:14:06Z"}, {"author": "Hubert Kario", "text": "

MIC: Bob Beck is unmuted

", "time": "2023-11-08T14:15:37Z"}, {"author": "Sean Turner", "text": "

and back to the regular sequence of events ;)

", "time": "2023-11-08T14:16:17Z"}, {"author": "Deirdre Connolly", "text": "

\"include the full transcript in the KDF\" is pretty nice if you can do that

", "time": "2023-11-08T14:16:35Z"}, {"author": "Simon Friedberger", "text": "

Daniel Gillmor said:

\n
\n

Simon Friedberger said:

\n
\n

Daniel Gillmor To get back to your earlier point, I don't have enough background here but, is there any other date that should be included?

\n
\n

I don't understand S/MIME, CMS, or X.509 well enough to know what additional data should be included in the KDF. In TLS we just stopped trying to figure that out and included the full transcript in the KDF.

\n
\n

@Russ Housley What's your opinion?

", "time": "2023-11-08T14:16:53Z"}, {"author": "Rich Salz", "text": "

@Sean Turner 6A started.

", "time": "2023-11-08T14:18:07Z"}, {"author": "Sean Turner", "text": "

ack

", "time": "2023-11-08T14:18:29Z"}, {"author": "Rich Salz", "text": "

@Sean Turner they're skipping a bunch because already done, so section 6 is just about done.

", "time": "2023-11-08T14:21:35Z"}, {"author": "Deirdre Connolly", "text": "

sneak!

", "time": "2023-11-08T14:22:21Z"}, {"author": "Daniel Gillmor", "text": "

John Gray said:

\n
\n

If there are usecases for context separation between COSE, JOSE and S/MIME then define a cross validation salt value, along with ones for everyone else.

\n
\n

There should definitely be some form of context separation between encrypted objects in COSE, JOSE, and CMS. if there's a way to take a CMS message and mutate it into a COSE or JOSE object that can be decrypted with the same symmetric key, that is a really sketchy cross-protocol attack that makes it harder to analyze any of these overall systems.

", "time": "2023-11-08T14:25:36Z"}, {"author": "Yoav Nir", "text": "

Arrrrgh. He used the O-word

", "time": "2023-11-08T14:26:28Z"}, {"author": "David Benjamin", "text": "

Has anyone in the history of X.509 ever actually used those BIT STRINGs as BIT STRINGs? I have never seen an algorithm that doesn't actually want an OCTET STRING in BIT STRING's clothing.

", "time": "2023-11-08T14:26:59Z"}, {"author": "Daniel Gillmor", "text": "

are we really held hostage by OpenSSL's API here?

", "time": "2023-11-08T14:27:01Z"}, {"author": "Deirdre Connolly", "text": "

Do these KEM definitions duplicate work elsewhere, like in CFRG?

", "time": "2023-11-08T14:27:11Z"}, {"author": "Daniel Van Geest", "text": "

Simon Friedberger said:

\n
\n

Daniel Gillmor said:

\n
\n

Simon Friedberger said:

\n
\n

Daniel Gillmor To get back to your earlier point, I don't have enough background here but, is there any other date that should be included?

\n
\n

I don't understand S/MIME, CMS, or X.509 well enough to know what additional data should be included in the KDF. In TLS we just stopped trying to figure that out and included the full transcript in the KDF.

\n
\n

Russ Housley What's your opinion?

\n
\n

I also don't understand it all well enough, and in ACME @Deirdre Connolly pointed out that ML-KEM no longer commits to public key and ciphertext, while Kyber did. I don't know if this becomes a problem for kemri, but if it does, I believe including the full transcript addresses this.

", "time": "2023-11-08T14:27:34Z"}, {"author": "Deirdre Connolly", "text": "

*ML-KEM no longer commits to ciphertext, not sure about public key

", "time": "2023-11-08T14:27:56Z"}, {"author": "Deirdre Connolly", "text": "

Yes including the full transcript should keep you safe no matter what

", "time": "2023-11-08T14:28:16Z"}, {"author": "Simon Friedberger", "text": "

@Deirdre Connolly I think somebody mentioned earlier today that pquip has slides on different MLKEM usages because there is so much overlap in WGs.

", "time": "2023-11-08T14:28:18Z"}, {"author": "Christopher Patton", "text": "

What is the use case for Kyber + RSA? Don't we generally want Kyber + some EC?

", "time": "2023-11-08T14:28:18Z"}, {"author": "David Benjamin", "text": "

More importantly, because these schemes know what algorithms they're doing, we know exactly what we're concatenating.

", "time": "2023-11-08T14:28:26Z"}, {"author": "Deirdre Connolly", "text": "

@Simon cheers, good

", "time": "2023-11-08T14:28:37Z"}, {"author": "Daniel Gillmor", "text": "

i guess there's a question about what the \"full transcript\" is for CMS -- for TLS it's more obvious, because there is an explicit wire image, while CMS is relying on external certificates somehow.

", "time": "2023-11-08T14:28:45Z"}, {"author": "Christopher Patton", "text": "

(s/Kyber/ML-KEM)

", "time": "2023-11-08T14:29:27Z"}, {"author": "Aritra Banerjee", "text": "

@Simon Friedberger: These slides will presented in PQUIP https://datatracker.ietf.org/meeting/118/materials/slides-118-pquip-pquip-hybridkem-comparisons-00

", "time": "2023-11-08T14:29:59Z"}, {"author": "Deirdre Connolly", "text": "

Careful, Kyber != ML-KEM, but

", "time": "2023-11-08T14:30:44Z"}, {"author": "Christopher Patton", "text": "

yeah sorry I haven't learned the difference yet

", "time": "2023-11-08T14:31:01Z"}, {"author": "Deirdre Connolly", "text": "

Oh no not you Chris, to Mike, just in case

", "time": "2023-11-08T14:31:17Z"}, {"author": "Deirdre Connolly", "text": "

@Arita good to have the hybrid kem tracking, I'm also noticing the generic KEM (Keygen/Encaps/Decaps) proliferation of definitions across WGs

", "time": "2023-11-08T14:32:39Z"}, {"author": "Yoav Nir", "text": "

Christopher Patton said:

\n
\n

(s/Kyber/ML-KEM)

\n
\n

Rijndael forever.

", "time": "2023-11-08T14:33:58Z"}, {"author": "Aritra Banerjee", "text": "

@Dierdre +1 to that.

", "time": "2023-11-08T14:34:04Z"}, {"author": "Christopher Patton", "text": "

This long list of ciphersuites scares me

", "time": "2023-11-08T14:34:53Z"}, {"author": "Deirdre Connolly", "text": "

:100:

", "time": "2023-11-08T14:34:59Z"}, {"author": "Deirdre Connolly", "text": "

:100:

", "time": "2023-11-08T14:35:06Z"}, {"author": "Deirdre Connolly", "text": "

... :100:

", "time": "2023-11-08T14:35:17Z"}, {"author": "Deirdre Connolly", "text": "

...why is this chat turning my 100 into clocks

", "time": "2023-11-08T14:35:45Z"}, {"author": "Deirdre Connolly", "text": "

:100:

", "time": "2023-11-08T14:35:53Z"}, {"author": "Deirdre Connolly", "text": "

hwat

", "time": "2023-11-08T14:36:00Z"}, {"author": "Yoav Nir", "text": "

These are full pie charts

", "time": "2023-11-08T14:36:03Z"}, {"author": "Daniel Gillmor", "text": "

I see 100s

", "time": "2023-11-08T14:36:23Z"}, {"author": "Simon Friedberger", "text": "

They're 100s on my end, web, FF.

", "time": "2023-11-08T14:36:26Z"}, {"author": "Deirdre Connolly", "text": "

wild

", "time": "2023-11-08T14:36:37Z"}, {"author": "Yoav Nir", "text": "

They're 100s on Zulip

", "time": "2023-11-08T14:36:42Z"}, {"author": "Hubert Kario", "text": "

I see clocks, with web Firefox client

", "time": "2023-11-08T14:36:45Z"}, {"author": "Yoav Nir", "text": "

They're full pie charts in MeetEcho

", "time": "2023-11-08T14:37:13Z"}, {"author": "Daniel Gillmor", "text": "

2023-11-08_15-36-51_window_810x568.png (chromium 119.0.6045.105-1)

\n
", "time": "2023-11-08T14:37:35Z"}, {"author": "Simon Friedberger", "text": "

Oh, it's Meetecho vs Zulip...?

", "time": "2023-11-08T14:37:55Z"}, {"author": "Deirdre Connolly", "text": "

in zulip.ietf.org, they are the proper :100:'s; in https://meetecho.ietf.org/ they are :clock:

", "time": "2023-11-08T14:38:00Z"}, {"author": "Deirdre Connolly", "text": "

hilarious

", "time": "2023-11-08T14:38:11Z"}, {"author": "Daniel Gillmor", "text": "

@Meetecho Robot we have an emoji emergency upthread here

", "time": "2023-11-08T14:38:30Z"}, {"author": "Hubert Kario", "text": "

I see \ud83d\udd50 in meetecho :)

", "time": "2023-11-08T14:38:41Z"}, {"author": "Yoav Nir", "text": "

Yeah, 100% or full pie chart. Except the full pie chart looks like a weird clock

", "time": "2023-11-08T14:39:13Z"}, {"author": "Deirdre Connolly", "text": "

HA i send a \ud83d\udd50 it turns into \u231b in meetecho

", "time": "2023-11-08T14:39:22Z"}, {"author": "Lorenzo Miniero", "text": "

Yeah, unfortunately the emoji desync between zulip and Meetecho is a known problem, it's on the todo list, sorry for the confusion :D

", "time": "2023-11-08T14:39:23Z"}, {"author": "Deirdre Connolly", "text": "

:sob:

", "time": "2023-11-08T14:39:32Z"}, {"author": "Lorenzo Miniero", "text": "

It's why I write colon-D to smile like it's still 1998!

", "time": "2023-11-08T14:40:11Z"}, {"author": "Deirdre Connolly", "text": "

you're missing out on innovations like \ud83e\udee0

", "time": "2023-11-08T14:40:58Z"}, {"author": "Yoav Nir", "text": "

People write here \"/me thinks this is strange\" like this is IRC

", "time": "2023-11-08T14:41:23Z"}, {"author": "Deirdre Connolly", "text": "

heh

", "time": "2023-11-08T14:41:31Z"}, {"author": "Daniel Gillmor", "text": "

:100: U+1F4AF HUNDRED POINTS SYMBOL \u2192 \ud83d\udd50 U+1F550 CLOCK FACE ONE OCLOCK
\n\ud83d\udd50 U+1F550 CLOCK FACE ONE OCLOCK \u2192 \u231bU+231B HOURGLASS ??

", "time": "2023-11-08T14:42:16Z"}, {"author": "Deirdre Connolly", "text": "

:rolling_on_the_floor_laughing:

", "time": "2023-11-08T14:43:52Z"}, {"author": "Deirdre Connolly", "text": "

:+1::+1::+1:

", "time": "2023-11-08T14:45:02Z"}, {"author": "Deirdre Connolly", "text": "

Thank you on ciphersuite alignment for KEMs

", "time": "2023-11-08T14:45:15Z"}, {"author": "David Benjamin", "text": "

The \"choice\" on the TLS side is a red herring. Keep in mind that TLS negotiated \"named groups\" and \"cipher suites\" completely orthogonally.

", "time": "2023-11-08T14:46:30Z"}, {"author": "Deirdre Connolly", "text": "

:+1:

", "time": "2023-11-08T14:46:45Z"}, {"author": "Christopher Patton", "text": "

Thanks all for clarifying :)

", "time": "2023-11-08T14:46:54Z"}, {"author": "David Benjamin", "text": "

In practice, yes, TLS implementations tends to use AES-128-GCM. One could do a switch to AES-256 with ML-KEM but... yeah that's not going to happen. :-)

", "time": "2023-11-08T14:47:56Z"}, {"author": "Deirdre Connolly", "text": "

:100:

", "time": "2023-11-08T14:48:34Z"}, {"author": "Daniel Gillmor", "text": "

@David Benjamin you don't think there could be a switch to AES-256 independently of ML-KEM?

", "time": "2023-11-08T14:48:52Z"}, {"author": "Deirdre Connolly", "text": "

nah

", "time": "2023-11-08T14:49:10Z"}, {"author": "Deirdre Connolly", "text": "

i mean, maybe, but, they will happen on different schedules

", "time": "2023-11-08T14:49:33Z"}, {"author": "Hubert Kario", "text": "

IIRC, ANSSI or BSI said that Grover against AES-128 is theoretical, so there's no need for migration to AES-256 with PQC kex

", "time": "2023-11-08T14:50:00Z"}, {"author": "Christopher Patton", "text": "

Trying to massage the symmetric and public-key crypto into the same security level is probably not that important. Shor's algorithm is much closer to being implemented than Grover's for key search.

", "time": "2023-11-08T14:50:10Z"}, {"author": "Hubert Kario", "text": "

so there is no guarantee that everybody will move to AES-256

", "time": "2023-11-08T14:50:22Z"}, {"author": "Deirdre Connolly", "text": "

:+1:

", "time": "2023-11-08T14:50:22Z"}, {"author": "Aritra Banerjee", "text": "

+1 to that.

", "time": "2023-11-08T14:51:20Z"}, {"author": "David Benjamin", "text": "

I mean, I wouldn't say there can't be a transition. Just seems an unnecessary amount of fuss to tie it to the KEM selection logic. (Of course a server could tie the two together in the selection logic.) But yeah the consensus also seems to be that it's unnecessary.

", "time": "2023-11-08T14:52:01Z"}, {"author": "Deirdre Connolly", "text": "

:plus:

", "time": "2023-11-08T14:54:02Z"}, {"author": "Daniel Gillmor", "text": "

+1 to Tim: OCSP should return valid on a cert like this.

", "time": "2023-11-08T14:54:51Z"}, {"author": "Deb Cooley", "text": "

how do you know it has been issued?

", "time": "2023-11-08T14:55:16Z"}, {"author": "Deb Cooley", "text": "

If issued, then valid is the proper response

", "time": "2023-11-08T14:55:27Z"}, {"author": "Deb Cooley", "text": "

it it hasn't been issued, then it should return 'not issued'.

", "time": "2023-11-08T14:55:48Z"}, {"author": "Yoav Nir", "text": "

And what if you don't know if it has been issued or not, because you're responding based on looking in the CRL?

", "time": "2023-11-08T14:58:05Z"}, {"author": "David Benjamin", "text": "

Virtual queue seems not to have worked but, uh, what is the relying party intended to do with this noRevAvail bit? You can observe that there is no rev info available by the lack of crldp and OCSP extension. ISTM noRevAvail is just telling you \"yup, those are indeed not there...\"

", "time": "2023-11-08T14:58:11Z"}, {"author": "Yoav Nir", "text": "

\"We really mean it. We're not just bad at encoding certificates\"

", "time": "2023-11-08T14:58:50Z"}, {"author": "Deb Cooley", "text": "

not there, by design

", "time": "2023-11-08T14:58:54Z"}, {"author": "Mike Ounsworth", "text": "

Simon Friedberger said:

\n
\n

Deirdre Connolly I think somebody mentioned earlier today that pquip has slides on different MLKEM usages because there is so much overlap in WGs.

\n
\n

@Deirdre Connolly It's sorta all me. I'm the lead author of the CFRG KEM combiners draft. I am the lead author of the LAMPS CompositeKEMs draft (which is a direct application of the CFRG one). I am also giving the PQUIP Hybrid KEMs Alignment talk :)

", "time": "2023-11-08T14:59:26Z"}, {"author": "David Benjamin", "text": "

And what behavior change would the relying party trigger based on this \"we really mean it\" bit?

", "time": "2023-11-08T14:59:34Z"}, {"author": "Deb Cooley", "text": "

@David: to stop looking for the CRL?

", "time": "2023-11-08T15:00:01Z"}, {"author": "Yoav Nir", "text": "

If you don't have a CRLDP, where are you going to look?

", "time": "2023-11-08T15:00:19Z"}, {"author": "David Benjamin", "text": "

But it knows there's no CRL to look for by way of lack of crldp.

", "time": "2023-11-08T15:00:26Z"}, {"author": "Deirdre Connolly", "text": "

@mike :sweat_smile:

", "time": "2023-11-08T15:00:59Z"}, {"author": "Deb Cooley", "text": "

not always.

", "time": "2023-11-08T15:01:03Z"}, {"author": "Daniel Gillmor", "text": "

@David Benjamin maybe it's not for the relying party -- but rather for the auditor looking at what was issued by the CA?

", "time": "2023-11-08T15:01:15Z"}, {"author": "Daniel Gillmor", "text": "

i agree that it seems to have the exact same semantics for the relying party.

", "time": "2023-11-08T15:01:53Z"}, {"author": "Mike Ounsworth", "text": "

Deirdre Connolly said:

\n
\n

Oh no not you Chris, to Mike, just in case

\n
\n

I know I know I know :P

", "time": "2023-11-08T15:02:44Z"}, {"author": "Tadahiko Ito", "text": "

I believe, revocation information not available for RP is different from CA not providing revocation mechanism.
\nIs that mean no revocation mechanism provided by CA?

", "time": "2023-11-08T15:03:36Z"}, {"author": "David Benjamin", "text": "

Daniel Gillmor said:

\n
\n

David Benjamin maybe it's not for the relying party -- but rather for the auditor looking at what was issued by the CA?

\n
\n

The draft doesn't seem to say anything about this. But, even then, presumably the auditor is checking some property like \"the CA said it will include CRLDP unless the cert lasts less than N days\", so the redundant bit is also not useful here. An auditor that lets any noRevAvail slide is unlikely to be doing anything useful.

", "time": "2023-11-08T15:03:44Z"}, {"author": "David Benjamin", "text": "

Deb Cooley said:

\n
\n

not always.

\n
\n

Hmm, so, is this is some external revocation service that your RP has a priori knowledge about, but that it doesn't have a priori knowledge about which certificates are out of scope for it?

", "time": "2023-11-08T15:05:41Z"}, {"author": "Deb Cooley", "text": "

yes, like that.

", "time": "2023-11-08T15:07:55Z"}, {"author": "Deb Cooley", "text": "

sometimes certs are issued on networks where the CRL can't be reached.

", "time": "2023-11-08T15:08:11Z"}, {"author": "Deb Cooley", "text": "

so we pre-populate it to an accessible location.

", "time": "2023-11-08T15:08:31Z"}, {"author": "Deb Cooley", "text": "

CRLDP is just awkward in that case.

", "time": "2023-11-08T15:08:50Z"}, {"author": "Tadahiko Ito", "text": "

some browsers require to publish CLR in around cabforum. some CA do not put CRLD on the Certificate, but publish CRL by someCRLDP

", "time": "2023-11-08T15:10:10Z"}, {"author": "David Benjamin", "text": "

Mmm. I do find it strange that to use a signal, inside the thing you don't yet believe, to decide whether to skip one of the checks you'd otherwise have considered a requirement to decide whether you believe the thing. :-) I would have expected it to be based on validity or whatever other criteria you decide revocation is unnecessary. But it's hard for me to reason about that abstractly... if that's the target use case, perhaps the draft could expand on it?

", "time": "2023-11-08T15:10:11Z"}, {"author": "Tadahiko Ito", "text": "

for CRLite I believe.

", "time": "2023-11-08T15:10:42Z"}, {"author": "David Benjamin", "text": "

But schemes like CRLite or CRLSets are pre-pushed blobs that you go do a lookup into. Doing an extra query in them is basically free.

", "time": "2023-11-08T15:11:50Z"}, {"author": "Deb Cooley", "text": "

The draft just needs to address OCSP and what the plan is.

", "time": "2023-11-08T15:12:12Z"}, {"author": "Tadahiko Ito", "text": "

In addition, CRLite can cause false positive (I believe), but we may not help those people.

", "time": "2023-11-08T15:13:15Z"}, {"author": "David Benjamin", "text": "

Ah, that's true. CRLite's false positive avoidance depends both sides agreeing on the universe of certificates.

", "time": "2023-11-08T15:13:30Z"}, {"author": "Deirdre Connolly", "text": "

Non-Separability

", "time": "2023-11-08T15:13:44Z"}, {"author": "Deirdre Connolly", "text": "

(weak vs strong)

", "time": "2023-11-08T15:14:03Z"}, {"author": "Mike Ounsworth", "text": "

Non-Separability:
\nWe have been working closely with Britta Hale (as recently as this week's hackathon) to roll stronger NS into this composite-sigs draft.

", "time": "2023-11-08T15:14:40Z"}, {"author": "Deirdre Connolly", "text": "

:dancer:

", "time": "2023-11-08T15:14:53Z"}, {"author": "David Benjamin", "text": "

But, imagining what I'd do as an RP, if I just see a random cert with noRevAvail, I think it'd still be important to apply a validity check on it. At which point, that may as well be the criteria. Also in the context of CRLite, what the CA believes should be excluded from the universe may not be what the CRLite assembler believes.

", "time": "2023-11-08T15:16:06Z"}, {"author": "Peter Campbell", "text": "

@Mike This only provides weak non-separability. The OID is an artefact indicating the existince of the hybrid, but I think you still have something that verifies for a component algorithm.

", "time": "2023-11-08T15:17:05Z"}, {"author": "David Benjamin", "text": "

Anyway, my broader point is I do not think the draft sufficiently justifies why we need this bit. Whatever use case it has in mind should be written down.

", "time": "2023-11-08T15:17:08Z"}, {"author": "Tadahiko Ito", "text": "

It may not matter if, for instance validity period is 7 days, but not quite sure about 90days

", "time": "2023-11-08T15:17:18Z"}, {"author": "Deirdre Connolly", "text": "

ummm

", "time": "2023-11-08T15:17:53Z"}, {"author": "Peter Campbell", "text": "

It's valid for a different message M' = OID || M.

", "time": "2023-11-08T15:18:39Z"}, {"author": "Deirdre Connolly", "text": "

:check:

", "time": "2023-11-08T15:19:07Z"}, {"author": "Daniel Gillmor", "text": "

that's scary

", "time": "2023-11-08T15:19:12Z"}, {"author": "Tadahiko Ito", "text": "

if life time of the certs were shorter than publishing cycle + distribution lag, not providing revocation mechanism at all should be reasonable

", "time": "2023-11-08T15:20:40Z"}, {"author": "Daniel Gillmor", "text": "

you'd like to know that non-composite signatures are also over OID || M -- that should make a collision impossible.

", "time": "2023-11-08T15:20:52Z"}, {"author": "Carl Wallace", "text": "

re: relying on the thing you don't trust to know whether or not rev should be checked for noRevAvail, maybe the extension belongs in the CA cert as a value that indicates validity periods below which no rev is available. one may already trust the CA cert. that would avoid cases where it appears in \"long\" lived certs as well.

", "time": "2023-11-08T15:23:50Z"}, {"author": "Deirdre Connolly", "text": "

hm

", "time": "2023-11-08T15:25:11Z"}, {"author": "Deb Cooley", "text": "

@ Carl: perfect

", "time": "2023-11-08T15:26:31Z"}, {"author": "Deirdre Connolly", "text": "

hmmmm

", "time": "2023-11-08T15:27:39Z"}, {"author": "Deb Cooley", "text": "

list of public keys = otherwise known as a directory?

", "time": "2023-11-08T15:28:08Z"}, {"author": "Deirdre Connolly", "text": "

DIDs!

", "time": "2023-11-08T15:28:49Z"}, {"author": "Deirdre Connolly", "text": "

As seen on BlueSky!

", "time": "2023-11-08T15:28:59Z"}, {"author": "Deirdre Connolly", "text": "

:nod nod:

", "time": "2023-11-08T15:29:18Z"}, {"author": "Rich Salz", "text": "

Deb Cooley said:

\n
\n

list of public keys = otherwise known as a directory?

\n
\n

That's not funny, Deb

", "time": "2023-11-08T15:29:59Z"}, {"author": "Deb Cooley", "text": "

yes it is

", "time": "2023-11-08T15:30:12Z"}, {"author": "Deirdre Connolly", "text": "

:laughing:

", "time": "2023-11-08T15:30:22Z"}]