[{"author": "Massimiliano Pala", "text": "

I have no clear opinion, the author's position seems reasonable but I have not reviewed the draft in detail.

", "time": "2023-03-29T00:42:39Z"}, {"author": "Mike Ounsworth", "text": "

One of the things about the proposed KEM message protection flow in 4210bis is that it adds an extra round-trip (2 RTT for RSA / DH, to 3 RTT with KEMs). I think that is unavoidable, and probably #NotABigDeal for CMP, but worth review.

", "time": "2023-03-29T00:44:07Z"}, {"author": "Mike Ounsworth", "text": "

Ballot that we commit a minor bit of vandalism to the LAMPS/About page to \"Lots of Additional Mechanisms\".

", "time": "2023-03-29T00:44:44Z"}, {"author": "Massimiliano Pala", "text": "

:thumbsup:

", "time": "2023-03-29T00:44:51Z"}, {"author": "Deb Cooley", "text": "

we can see it just fine.

", "time": "2023-03-29T00:46:16Z"}, {"author": "Deb Cooley", "text": "

LOLOLOL

", "time": "2023-03-29T00:46:20Z"}, {"author": "Amir Omidi", "text": "

:) #Remote yay

", "time": "2023-03-29T00:46:28Z"}, {"author": "Michael Richardson", "text": "

Is there an official font for ASN.1?

", "time": "2023-03-29T00:46:37Z"}, {"author": "Massimiliano Pala", "text": "

It is great for remote people :D ... A first!

", "time": "2023-03-29T00:46:38Z"}, {"author": "Daniel Gillmor", "text": "

https://datatracker.ietf.org/meeting/116/materials/slides-116-lamps-kyber-certificates

", "time": "2023-03-29T00:46:48Z"}, {"author": "Deb Cooley", "text": "

They could look at their laptops too.... even in the room.....

", "time": "2023-03-29T00:46:58Z"}, {"author": "Daniel Gillmor", "text": "

presenting to a roomful of people looking at their laptops is \u2026 not so great

", "time": "2023-03-29T00:47:18Z"}, {"author": "Deb Cooley", "text": "

sure

", "time": "2023-03-29T00:47:34Z"}, {"author": "Deb Cooley", "text": "

like that hasn't happened for years

", "time": "2023-03-29T00:47:45Z"}, {"author": "Daniel Gillmor", "text": "

it's not about saving the size, it's about saving the parsing confusion

", "time": "2023-03-29T00:47:58Z"}, {"author": "Daniel Gillmor", "text": "

private key transport is an interoperability issue.

", "time": "2023-03-29T00:48:47Z"}, {"author": "Yoav Nir", "text": "

If we replace all ASN.1 structures with great big octet strings, do we really need the ASN.1?

", "time": "2023-03-29T00:50:26Z"}, {"author": "Daniel Gillmor", "text": "

did we ever really need ASN.1?

", "time": "2023-03-29T00:50:42Z"}, {"author": "Deb Cooley", "text": "

only in that we needed a format

", "time": "2023-03-29T00:50:55Z"}, {"author": "Deb Cooley", "text": "

ASN.1 is merely a format

", "time": "2023-03-29T00:51:06Z"}, {"author": "Deb Cooley", "text": "

eyeroll

", "time": "2023-03-29T00:51:23Z"}, {"author": "Daniel Gillmor", "text": "

right but modern crypto primitive definitions typically specify a bytewise representation anyway -- just using that directly is good for interop

", "time": "2023-03-29T00:51:47Z"}, {"author": "Daniel Gillmor", "text": "

we're doing the same thing in OpenPGP, fwiw

", "time": "2023-03-29T00:52:18Z"}, {"author": "Deb Cooley", "text": "

sure, but you need some structure, right?

", "time": "2023-03-29T00:52:19Z"}, {"author": "Deb Cooley", "text": "

TLV and such

", "time": "2023-03-29T00:52:23Z"}, {"author": "Daniel Gillmor", "text": "

not if the OID tells you what object you need and the object itself is of known size.

", "time": "2023-03-29T00:53:05Z"}, {"author": "Deb Cooley", "text": "

So the OID is your structure

", "time": "2023-03-29T00:53:22Z"}, {"author": "Deb Cooley", "text": "

which I have to then go look up

", "time": "2023-03-29T00:53:30Z"}, {"author": "Michael Jenkins", "text": "

It'll have a non-Disney owned name, specifically

", "time": "2023-03-29T00:54:24Z"}, {"author": "Massimiliano Pala", "text": "

The new names are a bit... hard... :( ehehehe!!

", "time": "2023-03-29T00:54:25Z"}, {"author": "Daniel Gillmor", "text": "

if you're talking about naming, don't forget the 4Q curves, which were a response to bada55 curves

", "time": "2023-03-29T00:54:51Z"}, {"author": "Michael Richardson", "text": "

Disney will buy any name we come up with.

", "time": "2023-03-29T00:54:59Z"}, {"author": "Massimiliano Pala", "text": "

Hash entire certificate instead :)

", "time": "2023-03-29T00:56:30Z"}, {"author": "Massimiliano Pala", "text": "

... and algorithm agility, please!

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

So the uni-qsckeys-kyber draft does specify binary encodings for public and private keys (see s. 3.5).
\nThey have chosen ASN.1 (and therefore I assume DER, but I don't think that's actually said), which seems a bit of a bizarre choice for protocols that don't use ASN.1.
\nBut I assume you just DER that pub key structure to get a BIT or OCTET string, and stuff that into the structure in Sean's draft?
\nhttps://www.ietf.org/archive/id/draft-uni-qsckeys-kyber-00.html#name-private-key-full-encoding

", "time": "2023-03-29T00:58:14Z"}, {"author": "Massimiliano Pala", "text": "

More generalized is a good idea - we should work on repeatable proceses... post-quantum now... post-ai tomorrow... post-post-post... :)

", "time": "2023-03-29T00:59:17Z"}, {"author": "Tim Hollebeek", "text": "

We have a great strategy for a repeatable process ... it's called IETF, updates, -bis, etc :)

", "time": "2023-03-29T01:00:11Z"}, {"author": "Yoav Nir", "text": "

Yeah, don't mess with our excuse for traveling around the world to conferences.

", "time": "2023-03-29T01:00:58Z"}, {"author": "Massimiliano Pala", "text": "

Heheheh!! :)

", "time": "2023-03-29T01:01:31Z"}, {"author": "Tim Hollebeek", "text": "

The first internet draft to add a new HCP might be a good place to ask IANA for a registry, if we want one

", "time": "2023-03-29T01:12:55Z"}, {"author": "Massimiliano Pala", "text": "

I really like the approach, great work!

", "time": "2023-03-29T01:13:59Z"}, {"author": "Sean Turner", "text": "

@Tim Hollebeek @Russ Housley I uploaded new 5990bis slides via the datatracker. This set has a white background.

", "time": "2023-03-29T01:16:02Z"}, {"author": "Tim Hollebeek", "text": "

Thank you

", "time": "2023-03-29T01:16:47Z"}, {"author": "Tim Hollebeek", "text": "

Approved

", "time": "2023-03-29T01:17:11Z"}, {"author": "Sean Turner", "text": "

Sorry 'bout that folks. I have used that background for three other presentations and it was okay.

", "time": "2023-03-29T01:17:34Z"}, {"author": "Michael Jenkins", "text": "

It worked fine on Meetecho...

", "time": "2023-03-29T01:17:54Z"}, {"author": "Deb Cooley", "text": "

so then the bcc'd person can't accidentally send a message to the regular recipients?

", "time": "2023-03-29T01:19:07Z"}, {"author": "Deb Cooley", "text": "

reply not send....

", "time": "2023-03-29T01:19:18Z"}, {"author": "Daniel Migault", "text": "

@sean and black fonts ?

", "time": "2023-03-29T01:22:53Z"}, {"author": "Daniel Migault", "text": "

;-)

", "time": "2023-03-29T01:23:01Z"}, {"author": "Sean Turner", "text": "

:rolling_on_the_floor_laughing:

", "time": "2023-03-29T01:27:51Z"}, {"author": "Daniel Gillmor", "text": "

Deb Cooley said:

\n
\n

so then the bcc'd person can't accidentally \"reply all\" to the regular recipients?

\n
\n

the draft recommends:

\n
\n

Each Bcc recipient receives a distinct copy of the message, with an identical cryptographic payload, and the message is signed and encrypted to that specific recipient and all the named recipients.

\n
", "time": "2023-03-29T01:35:55Z"}, {"author": "Deb Cooley", "text": "

bummer.... I don't use bcc, because most people aren't smart enough to realize that I bcc'd them.

", "time": "2023-03-29T01:40:20Z"}, {"author": "Deb Cooley", "text": "

(regardless of whether it is encrypted or not)

", "time": "2023-03-29T01:40:31Z"}, {"author": "Mike Ounsworth", "text": "

@PRAT Julien I know I'm an author on this, so should maybe give feedback privately. Should that be KMAC rather than HKDF-SHA2-* ?

", "time": "2023-03-29T01:40:53Z"}, {"author": "Daniel Gillmor", "text": "

I think the main reason i use Bcc is to drop someone from a thread. in that case, i start such a message with something like:

\n

[dropping Jane to Bcc to spare her inbox]

", "time": "2023-03-29T01:41:31Z"}, {"author": "Deb Cooley", "text": "

oooohhh, I like that

", "time": "2023-03-29T01:42:02Z"}, {"author": "Daniel Gillmor", "text": "

(while bcc'ing jane, that is)

", "time": "2023-03-29T01:42:04Z"}, {"author": "Michael Richardson", "text": "

my MUA tells people on the BCC that they are on the BCC, and encapsulates the original message into a new message to the BCC. (This is MH)

", "time": "2023-03-29T01:43:48Z"}, {"author": "Michael Richardson", "text": "

The Blind is for the people on the CC, not the person on the BCC :-)

", "time": "2023-03-29T01:44:15Z"}, {"author": "Daniel Gillmor", "text": "

wow, that seems weird. so if they reply to you about the Bcc, they're actually replying to the new variant message?

\n

does the variant message have a distinct Message-ID? does it References: the original Message-ID?

", "time": "2023-03-29T01:45:03Z"}, {"author": "Michael Richardson", "text": "

(I've typically used BCC to tell my VP that I'm disagreeing with my manager, and/or that that the manager is doing something against the company policy)

", "time": "2023-03-29T01:45:05Z"}, {"author": "Michael Richardson", "text": "

@Daniel, yes, if they reply, they are replying to me, not the group. And yes, it has a new message-Id. The old one is in the encapsulated message.

", "time": "2023-03-29T01:45:34Z"}, {"author": "Daniel Gillmor", "text": "

shocked, shocked that you ever disagree with your manager, @Michael Richardson

", "time": "2023-03-29T01:45:49Z"}, {"author": "Deb Cooley", "text": "

I usually send a second message to the people I didn't want on the original message. I usually call it a 'ghetto bcc'

", "time": "2023-03-29T01:46:10Z"}, {"author": "Yoav Nir", "text": "

People really wanted a combination of dilithium3 and PKCS1.5?

", "time": "2023-03-29T02:00:49Z"}, {"author": "Sean Turner", "text": "

I was going to say that I appreciated their restraint in picking combinations ;)

", "time": "2023-03-29T02:02:32Z"}, {"author": "Yoav Nir", "text": "

No finite field DSA?

", "time": "2023-03-29T02:03:24Z"}, {"author": "Daniel Gillmor", "text": "

i was wondering whether i could nest the generic combiners

", "time": "2023-03-29T02:03:27Z"}, {"author": "Deb Cooley", "text": "

@Yoav don't give them ideas

", "time": "2023-03-29T02:04:02Z"}, {"author": "Michael Richardson", "text": "

What does it mean for a CA to revoke RSA? If the CA refuses to sign any certificates with RSA, and isn't using RSA itself, is it equivalent to revoking all previous certificates that had RSA keys?

", "time": "2023-03-29T02:08:12Z"}, {"author": "Yoav Nir", "text": "

Yeah, I'm not getting why we'd revoke the RSA on old certificates

", "time": "2023-03-29T02:08:43Z"}, {"author": "Deb Cooley", "text": "

I don't understand it. If you don't want RSA 1024, then don't issue certs with that algorithm

", "time": "2023-03-29T02:09:29Z"}, {"author": "Tim Hollebeek", "text": "

It's not that ...

", "time": "2023-03-29T02:09:42Z"}, {"author": "Deb Cooley", "text": "

go on

", "time": "2023-03-29T02:09:52Z"}, {"author": "Michael Richardson", "text": "

@Deb, imagine you signed 15 year long certificates 12 years ago.

", "time": "2023-03-29T02:09:53Z"}, {"author": "Deb Cooley", "text": "

stop....

", "time": "2023-03-29T02:10:01Z"}, {"author": "Yoav Nir", "text": "

12 years ago Deb did not used combined signatures

", "time": "2023-03-29T02:10:17Z"}, {"author": "Carl Wallace", "text": "

And that thing may be verified using the algorithm the thing says not to use

", "time": "2023-03-29T02:10:25Z"}, {"author": "Michael Richardson", "text": "

Okay. In 12 years, imagine you had 15 year duration certificates with three years left on them.

", "time": "2023-03-29T02:10:50Z"}, {"author": "Yoav Nir", "text": "

Right, and that is RSA + dilithium3, and we don't like RSA anymore

", "time": "2023-03-29T02:11:14Z"}, {"author": "Yoav Nir", "text": "

Why revoke it. The signature still verifies. If you don't trust RSA, don't verify the RSA sig?

", "time": "2023-03-29T02:11:38Z"}, {"author": "Deb Cooley", "text": "

oh so this is entirely because of composite stuff?

", "time": "2023-03-29T02:11:50Z"}, {"author": "Michael Richardson", "text": "

@Yoav, I agree. But maybe the idea is that the policy is at the CA, rather than the nodes, and that's where I think it mostly fails.

", "time": "2023-03-29T02:12:01Z"}, {"author": "Sean Turner", "text": "

+1 what Paul said about splitting the I-D into two parts

", "time": "2023-03-29T02:12:36Z"}, {"author": "Jonathan Hammell", "text": "

Nested composite is not allowed in the signatures draft. The draft says: \"Since recursive composite public keys are disallowed in [I-D.ounsworth-pq-composite-keys], no component signature may itself be a composite\"

", "time": "2023-03-29T02:15:13Z"}, {"author": "Paul Hoffman", "text": "

I agree with DKG: the generic OIDs are a bad idea

", "time": "2023-03-29T02:17:14Z"}, {"author": "Jonathan Hammell", "text": "

I don't get the \"rake factory\" reference. Google didn't help.

", "time": "2023-03-29T02:19:17Z"}, {"author": "Deb Cooley", "text": "

If you leave a bunch of rakes lying around and you step on them, they smack you in the face

", "time": "2023-03-29T02:19:57Z"}, {"author": "Deb Cooley", "text": "

He might have made it up on the fly. possibly

", "time": "2023-03-29T02:20:21Z"}, {"author": "Andrew Fregly", "text": "

How could CRLs be used to revoke an algorithm globally?

", "time": "2023-03-29T02:20:30Z"}, {"author": "Paul Hoffman", "text": "

And I agree with DKG again about not revocating algorithms, but replacing the software instead

", "time": "2023-03-29T02:20:48Z"}, {"author": "Jonathan Hammell", "text": "

@Deb Cooley Thanks. I've heard of the danger of leaving rakes around, just not sure what that had to do with a factory making them.

", "time": "2023-03-29T02:21:08Z"}, {"author": "Deb Cooley", "text": "

making one's clients agile.

", "time": "2023-03-29T02:21:10Z"}, {"author": "Andrew Fregly", "text": "

Current speaker seems bo be picking up the point\\

", "time": "2023-03-29T02:21:16Z"}, {"author": "Florence D", "text": "

@chairs - Do you want me to ask my questions in chat?

", "time": "2023-03-29T02:22:28Z"}, {"author": "Florence D", "text": "

I'm happy to given the time.

", "time": "2023-03-29T02:22:41Z"}, {"author": "Daniel Gillmor", "text": "

rakes: sideshow-bob-rakes.gif

\n
", "time": "2023-03-29T02:22:50Z"}, {"author": "Florence D", "text": "

Two questions:

\n
    \n
  1. Do we need SPHINCS+ hybrids? The OpenPGP doesn't include them and SPHINCS+ is pretty mature.
    2. \n
  2. Why is the K-of-N parameter a parameter of the key and not the signature? (based on the presentation, correct me if I'm wrong)
    3. \n
", "time": "2023-03-29T02:24:34Z"}, {"author": "Daniel Gillmor", "text": "

the idea is that the generic combiner is a factory for making rakes that will hit peopl in the face

", "time": "2023-03-29T02:24:39Z"}, {"author": "Jonathan Hammell", "text": "

You don't want to be writing a combiner guidance document in the future.

", "time": "2023-03-29T02:26:17Z"}, {"author": "Tadahiko Ito", "text": "

revocation of algorithms sound like usually verifier side's policy .
\nIt sound fine if CA is controlling all EE devices. It might be helpful to describe use case of mass-revocation.

", "time": "2023-03-29T02:26:22Z"}, {"author": "Daniel Gillmor", "text": "

i do like the idea of compact, privacy-preserving mass-revocation -- i'm just not sure this is the thing we want to do it though.

", "time": "2023-03-29T02:27:01Z"}, {"author": "Yoav Nir", "text": "

Doesn't k-of-n also sound like verifier-side policy?

", "time": "2023-03-29T02:27:05Z"}, {"author": "Tim Hollebeek", "text": "

One of the things to address on algorithms revocation is not a binary event. If people want this, they might want to communicate a work factor or something like that to indicate approximate how weak RSA is

", "time": "2023-03-29T02:27:58Z"}, {"author": "Tim Hollebeek", "text": "

And it's not clear how to communicate a non-binary signal using CRLs. Which might be another reason not to use CRLs for this.

", "time": "2023-03-29T02:28:23Z"}, {"author": "Deb Cooley", "text": "

Of course if one wanted to revoke all certs w/ a particular algorithm from a CA, one could revoke the CA.

", "time": "2023-03-29T02:28:48Z"}, {"author": "Massimiliano Pala", "text": "

@Yoav, yes it is. Ultimately it is always the choice of the verifying party if to accept or not a signature (besides the mathematical verification). The indication in the CRL and OCSP can provide the indication to the client how to handle things in an easy, integrated way.

", "time": "2023-03-29T02:28:48Z"}, {"author": "Tadahiko Ito", "text": "

I was thinking same thing as Yoav.

", "time": "2023-03-29T02:28:50Z"}, {"author": "Daniel Gillmor", "text": "

@Tim Hollebeek or you might want to say \"RSA bad, but RSA as part of 2-of-3 RSA + Khyber + Snausage is fine, even if you don't know how to validate Snausage\"

", "time": "2023-03-29T02:29:16Z"}, {"author": "Mike Ounsworth", "text": "

Yoav Nir said:

\n
\n

People really wanted a combination of dilithium3 and PKCS1.5?

\n
\n

There's still a lot of PKCSv1.5 out there. If the goal is to continue to use your battle-hardened crypto modules, then I think you need to offer it in hybrid.

", "time": "2023-03-29T02:30:20Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

i was wondering whether i could nest the generic combiners

\n
\n

No.

", "time": "2023-03-29T02:30:33Z"}, {"author": "Tim Hollebeek", "text": "

I think if you sign up for kofn, you've signed up for revoking RSA means that already, Daniel

", "time": "2023-03-29T02:30:34Z"}, {"author": "Massimiliano Pala", "text": "

@Daniel - Thanks for the support, we will work on a separate document so we can possibly collaborate on the solution. The idea I presented can be expanded to other details of certificates (e.g., do not trust certs issued before date X).

", "time": "2023-03-29T02:31:01Z"}, {"author": "Daniel Gillmor", "text": "

@Tim Hollebeek even if you don't know how to evaluate one of the others?

", "time": "2023-03-29T02:31:07Z"}, {"author": "Tim Hollebeek", "text": "

As a personal opinion, I retain an allergy to kofn.

", "time": "2023-03-29T02:31:09Z"}, {"author": "Tim Hollebeek", "text": "

@Daniel Gillmor That's an interesting point I'd like to avoid since kofn is already to complex for my taste. But people who like it need to address that too.

", "time": "2023-03-29T02:31:54Z"}, {"author": "Mike Ounsworth", "text": "

Jonathan Hammell said:

\n
\n

I don't get the \"rake factory\" reference. Google didn't help.

\n
\n

I think the point is that generic composite is giving you a blueprint to create rakes to smack yourself in the face with.

", "time": "2023-03-29T02:32:00Z"}, {"author": "Daniel Gillmor", "text": "

i think this is all a lot of complexity, and even if it would work in a perfect world, i'm not convinced that the complexity cost is worthwhile

", "time": "2023-03-29T02:32:03Z"}, {"author": "Massimiliano Pala", "text": "

Thank you everybody!

", "time": "2023-03-29T02:32:19Z"}, {"author": "Daniel Gillmor", "text": "

keep it simple until you know you need the complexity.

", "time": "2023-03-29T02:32:21Z"}, {"author": "Massimiliano Pala", "text": "

:thumbsup:

", "time": "2023-03-29T02:32:39Z"}]