[{"author": "Deb Cooley", "text": "

Is this working?

", "time": "2022-07-27T14:15:29Z"}, {"author": "John Preu\u00df Mattsson", "text": "

yes

\n

Deb Cooley said:

\n
\n

Is this working?

\n
\n

yes

", "time": "2022-07-27T14:16:07Z"}, {"author": "Deb Cooley", "text": "

was there a volunteer to take notes?

", "time": "2022-07-27T14:17:17Z"}, {"author": "Tim Hollebeek", "text": "

I'll bring that up after this convo

", "time": "2022-07-27T14:17:42Z"}, {"author": "Deb Cooley", "text": "

I'm doing it, but.... I'd take help.

", "time": "2022-07-27T14:17:43Z"}, {"author": "Tim Hollebeek", "text": "

thank you

", "time": "2022-07-27T14:17:51Z"}, {"author": "John Gray", "text": "

Thanks Hendrick for all your great work on the CMP documents and keeping it moving forward!

", "time": "2022-07-27T14:20:22Z"}, {"author": "Massimiliano Pala", "text": "

+1 - Thanks Hendrick!

", "time": "2022-07-27T14:20:46Z"}, {"author": "Florence D", "text": "

Deb Cooley said:

\n
\n

I'm doing it, but.... I'd take help.

\n
\n

I can help Deb.

", "time": "2022-07-27T14:27:06Z"}, {"author": "Jabber", "text": "

Yoshiro Yoneya: Please speak louder at floor mic.

", "time": "2022-07-27T14:29:40Z"}, {"author": "Deb Cooley", "text": "

And I didn't get the name of the gentleman from MS....

", "time": "2022-07-27T14:31:57Z"}, {"author": "Deb Cooley", "text": "

for the notes.

", "time": "2022-07-27T14:32:00Z"}, {"author": "Massimiliano Pala", "text": "

This looks like another EKU ... :)

", "time": "2022-07-27T14:32:22Z"}, {"author": "Jabber", "text": "

mcr: Roy Something. Maybe Williams.

", "time": "2022-07-27T14:32:56Z"}, {"author": "Uri Blumenthal", "text": "

In short: I support this draft. It makes sense.

", "time": "2022-07-27T14:33:11Z"}, {"author": "Uri Blumenthal", "text": "

Let's adopt it.

", "time": "2022-07-27T14:33:30Z"}, {"author": "Deb Cooley", "text": "

@MCR: yeah, there is one of those in the attendees list...

", "time": "2022-07-27T14:33:57Z"}, {"author": "Massimiliano Pala", "text": "

Any reason not to define and use OIDs in the EKU?

", "time": "2022-07-27T14:35:28Z"}, {"author": "Tero Kivinen", "text": "

Relating to the CMP update and bis documents, if you need to ask questions from some of the original authors, i.e., the Tomi Kause or Tero Mononen, they said they can try to help and answer questions if needed.

", "time": "2022-07-27T14:37:29Z"}, {"author": "Roman Danyliw", "text": "

The internationalization issues of ASCII vs. UTF-8 at IESG review should be manageable due to the traceability to the 3GPP requirement.

", "time": "2022-07-27T14:37:29Z"}, {"author": "Uri Blumenthal", "text": "

@Roman +1

", "time": "2022-07-27T14:39:15Z"}, {"author": "Ned Smith", "text": "

Why wouldn't key attestation be included in an attestation protocol (eg. TLS with attestation ext) rather than embed it in a certificate request message?

", "time": "2022-07-27T14:42:10Z"}, {"author": "Hendrik Brockhaus", "text": "

Tero, thank you for the info. Do you know, if they are willing to act as co-authors?

", "time": "2022-07-27T14:42:28Z"}, {"author": "Uri Blumenthal", "text": "

@Stefan, I think this is about provenance of the key?

", "time": "2022-07-27T14:42:51Z"}, {"author": "Tero Kivinen", "text": "

At least Kause said no...

", "time": "2022-07-27T14:43:30Z"}, {"author": "Hendrik Brockhaus", "text": "

Thank you for the feedback

", "time": "2022-07-27T14:44:55Z"}, {"author": "Thomas Fossati", "text": "

@Ned Smith I think once you have the extension you can use it to stuff your attestation evidence / results into CSRs as well as in a cert that you use in a TLS handshake (e.g., https://arxiv.org/pdf/1801.05863.pdf)

", "time": "2022-07-27T14:46:18Z"}, {"author": "Michael StJohns", "text": "

@ned - when a CA gets a CSR, say for a root key for a customer and say the CSP says that the key should be in an HSM etc. This is one way to figure that out remotely.

", "time": "2022-07-27T14:47:43Z"}, {"author": "Michael StJohns", "text": "

@ned - you may also want an attestation for the ephemeral keys in a TLS handshake, but that maybe less of an issue.

", "time": "2022-07-27T14:48:55Z"}, {"author": "Tim Hollebeek", "text": "

There are actually lots of standards groups that want to require hardware key storage for all certificate keys of a particular kind, but can't because key attestation is not quite there yet

", "time": "2022-07-27T14:49:07Z"}, {"author": "Ned Smith", "text": "

@Thomas Fossati The idea of of a CSR is the contents in the CRS should be included in the cert that CA issues. The goal of putting attestation information in a certificate is interoperability in which case the contents should be defined by industry standards such as RATS

", "time": "2022-07-27T14:49:21Z"}, {"author": "Michael StJohns", "text": "

@ned - not really. there's usually info in the csr that does not need to make it in the certificate.

", "time": "2022-07-27T14:50:26Z"}, {"author": "Ned Smith", "text": "

@Michael - I expect the attestation protocol would provide all this information already.

", "time": "2022-07-27T14:50:47Z"}, {"author": "Mike Ounsworth", "text": "

Ned Smith said:

\n
\n

@Michael - I expect the attestation protocol would provide all this information already.

\n
\n

But is there an attestation protocol _to the CA_ at issuing time? Cause it sounds like there are some CPSs that forbid the CA from issuing the cert unless it has checked attestation.

", "time": "2022-07-27T14:51:39Z"}, {"author": "Thomas Fossati", "text": "

@Ned Smith the WebAuthn bit is just a wrapper {\"fmt\": \"ATTESTATION_TYPE\", \"attStmt\": { ATTESTATION_VALUE } } where the val part is defined in RATS, TCG, FIDO, etc.

", "time": "2022-07-27T14:51:45Z"}, {"author": "Stefan Santesson", "text": "

I will provide a link in a sec

", "time": "2022-07-27T14:53:19Z"}, {"author": "Stefan Santesson", "text": "

https://www.etsi.org/deliver/etsi_en/319400_319499/31941205/02.03.01_60/en_31941205v020301p.pdf

", "time": "2022-07-27T14:54:25Z"}, {"author": "Ned Smith", "text": "

@Mike - It is possible to tunnel a CSR exchange over TLS. TLS w/ attestation would achieve the evidence conveyance as part of the tls handshake. The attestation would include all the components from the TLS endpoint to the root of trust. If the key is protected by something in that sequence, then the CA/verifier would have the key attestation knowledge it needed (presumably).

", "time": "2022-07-27T14:54:55Z"}, {"author": "Stefan Santesson", "text": "

section 4.2.2

", "time": "2022-07-27T14:55:12Z"}, {"author": "Tim Hollebeek", "text": "

Adding an entire TLS layer to CSR delivery just to convey attestation information seems to be a bit heavyweight to me

", "time": "2022-07-27T14:57:03Z"}, {"author": "Mike Ounsworth", "text": "

Ned Smith said:

\n
\n

@Mike - It is possible to tunnel a CSR exchange over TLS. ...

\n
\n

Fair, so that meets the \"there exists\" bar, but would mean that you can't do attestation to the CA via, for example, pasting a CSR into a textbox on the CA's webpage.
\n(I make no claims to know whether that's a thing people actually want to do, etc)

", "time": "2022-07-27T14:57:34Z"}, {"author": "Thomas Fossati", "text": "

I support adoption

", "time": "2022-07-27T14:57:51Z"}, {"author": "Ned Smith", "text": "

@Tim tls is often used to protect CSRs to protect privacy - especially if done over public networks

", "time": "2022-07-27T14:59:09Z"}, {"author": "Tim Hollebeek", "text": "

I'm not saying using TLS for CSR transport a bad idea or shouldn't be done, but it should be possible to convey attestation information when the transport mechanism isn't TLS, as well

", "time": "2022-07-27T14:59:58Z"}, {"author": "Ned Smith", "text": "

@Tim - got it. I'm exploring if there are alternative approaches that do the same thing and if so, is there sufficient interest in implementing this particular approach.

", "time": "2022-07-27T15:01:05Z"}, {"author": "Tim Hollebeek", "text": "

It's certainly worth at least talking about whether such a TLS extension is useful --- it might be

", "time": "2022-07-27T15:02:15Z"}, {"author": "Leif Johansson", "text": "

@Carl Wallace wold be happy to talk about attestation offline - leifj @ sunet.se

", "time": "2022-07-27T15:02:30Z"}, {"author": "Carl Wallace", "text": "

I don't think trying to convey attestations for a cert request protocol via TLS or transport is an improvement. augmenting the cert request with attestation for the key in the request is very straightforward. given the TLS approach changes cert format in TLS, that would greatly slow adoption in my opinion.

", "time": "2022-07-27T15:02:30Z"}, {"author": "Bas Westerbaan", "text": "

Also I don't think we'll standardise all parameter sets of SPHINCS+.

", "time": "2022-07-27T15:03:33Z"}, {"author": "Mike Ounsworth", "text": "

Same comment I made at the mic: I have an omnibus suggestion for all the PQC stuff: can we get these adopted, get the rough design and editorial work out of the way, and then pause them waiting for small tweaks from the final NIST specs?
\n(the room gave strong consensus for that)

", "time": "2022-07-27T15:07:50Z"}, {"author": "Uri Blumenthal", "text": "

Is there any kind of tech support? Had to switch to iPhone, and **** meetecho doesn\u2019t deliver any sound to any browser absinthe there.

", "time": "2022-07-27T15:10:35Z"}, {"author": "Thom Wiggers", "text": "

Is the OID per algorithm / per algorithm+parameterset not a question for NIST as they will pick the OIDs?

", "time": "2022-07-27T15:12:33Z"}, {"author": "Mike Ounsworth", "text": "

Thom Wiggers said:

\n
\n

Is the OID per algorithm / per algorithm+parameterset not a question for NIST as they will pick the OIDs?

\n
\n

I guess we get to make sure that in the meantime we're all prototyping under the same model?

", "time": "2022-07-27T15:14:04Z"}, {"author": "Bas Westerbaan", "text": "

LMS is different. Stateful hash-based signatures benefit very much from parameters for fine-tuning to usage. Dilithium doesn't.

", "time": "2022-07-27T15:14:30Z"}, {"author": "Massimiliano Pala", "text": "

The downside of using individual OIDs is usability of tools that would need to mask the underlying complexity... it was an unfortunate choice from the usability point of view, IMHO.

", "time": "2022-07-27T15:17:13Z"}, {"author": "Stefan Santesson", "text": "

+1 for separate drafts

", "time": "2022-07-27T15:17:36Z"}, {"author": "Peter Campbell", "text": "

NIST have said they will prioritise Dilithium so the other signature standards may well appear later.

", "time": "2022-07-27T15:18:59Z"}, {"author": "Bas Westerbaan", "text": "

I think hybrids are a temporary solution. In N years I expect we're all on single algorithms. Why add complexity now? Let's keep hybrids as simple as possible.

", "time": "2022-07-27T15:25:27Z"}, {"author": "Tim Hollebeek", "text": "

That's a valid position, but people have also made the argument that we seem to go through crypto transitions on a regular basis, so maybe it's time to keep some generic agility around so we don't have to set it up again later the next time we need to transition

", "time": "2022-07-27T15:27:17Z"}, {"author": "Tim Hollebeek", "text": "

I'm not sure personally which is the better perspective

", "time": "2022-07-27T15:27:29Z"}, {"author": "Uri Blumenthal", "text": "

I agree with Bas. Also, I am strongly against composite keys and certs.

", "time": "2022-07-27T15:28:27Z"}, {"author": "Florence D", "text": "

I don't read Bas and Tim's positions as contradictory necessarily, I think the details of what we mean by \"crypto agility\" matter.

", "time": "2022-07-27T15:28:38Z"}, {"author": "Jonathan Hoyland", "text": "

I'd be in favour of always allowing Hybrid because it allows agility. There will always are a risk that something will be discovered to be maybe broken and we want to go for a belt-and-braces approach.

", "time": "2022-07-27T15:28:53Z"}, {"author": "Jonathan Hoyland", "text": "

always be*

", "time": "2022-07-27T15:29:13Z"}, {"author": "Massimiliano Pala", "text": "

@dkg: we need the parking lot because we have real-world deployments and constraints we need to work with. The rails are always good, but that might be a separate discussion. We need good tools and choices, IMHO.

", "time": "2022-07-27T15:29:19Z"}, {"author": "Bas Westerbaan", "text": "

There is already some migration flexibility in downstreams protocols such as TLS. I do not think we need the flexibility this proposal provides.

", "time": "2022-07-27T15:29:34Z"}, {"author": "Ned Smith", "text": "

crypto agility can be a design goal regardless of hybrid or not.

", "time": "2022-07-27T15:29:47Z"}, {"author": "Uri Blumenthal", "text": "

@Ned +1, @Bas +1

", "time": "2022-07-27T15:30:21Z"}, {"author": "Uri Blumenthal", "text": "

I am against adopting composite

", "time": "2022-07-27T15:35:37Z"}, {"author": "Massimiliano Pala", "text": "

We are planning to be using these tools. We run one of the largest PKI in the world.

", "time": "2022-07-27T15:37:44Z"}, {"author": "Daniel Huigens", "text": "

In the OpenPGP world, I've been arguing for fixed combination algorithm IDs, with (in the case of signatures) always the meaning of \"and\" (you need to verify both). But, there is a mechanism for sending multiple signatures, so you could send a Ed25519 signature and a Ed25519+Dilithium signature, if you want \"or\". Of course that would add some redundancy, but not much. Not sure if that applies cleanly to S/MIME, but just my 2c.

", "time": "2022-07-27T15:38:14Z"}, {"author": "Uri Blumenthal", "text": "

@Pala that doesn\u2019t change the fact that composite is technically bad, and likely to cause problems in the long term.

", "time": "2022-07-27T15:39:33Z"}, {"author": "Bas Westerbaan", "text": "

I'm against.

", "time": "2022-07-27T15:41:33Z"}, {"author": "Massimiliano Pala", "text": "

@uri: I would like to expand on your statement \"technically bad\" - please can you elaborate on the mailing list? This is part of the discussion we need on the list.

", "time": "2022-07-27T15:42:09Z"}, {"author": "Uri Blumenthal", "text": "

Yes, I\u2019ll be happy to continue on the mailing list, especially since I\u2019m not getting audio now, and cannot contribute meaningfully here (except for Twitter-like comments ;-) )

", "time": "2022-07-27T15:43:26Z"}, {"author": "Deb Cooley", "text": "

@Jonathan Hoyland: but the question here is a composite thing or two seperate distinct things. Where there are N choos M options for the number of combinations.

", "time": "2022-07-27T15:43:30Z"}, {"author": "Florence D", "text": "

If we're going to do this I think it should be done as simply as possible (and no more simply), and not define multiple combiners.

", "time": "2022-07-27T15:44:34Z"}, {"author": "Tim Hollebeek", "text": "

yeah, that was my reaction to some of the more complicated 17 of 33 scenarios

", "time": "2022-07-27T15:47:52Z"}, {"author": "Jonathan Hoyland", "text": "

@Deb Cooley I think doing it in a single piece means you don't have to worry about weird binding issues at the layer above, i.e. enforcing the \"and\" at the TLS layer is fiddly.

", "time": "2022-07-27T15:48:54Z"}, {"author": "Jabber", "text": "

mcr: will the chairs please add this document to the related documents list?

", "time": "2022-07-27T15:49:45Z"}, {"author": "Mike Ounsworth", "text": "

Bas Westerbaan said:

\n
\n

There is already some migration flexibility in downstreams protocols such as TLS. I do not think we need the flexibility this proposal provides.

\n
\n

So, I personally believe that Rebecca Guthrie's Non-Composite is the right approach for TLS, so I think that TLS-based arguments are moot here. An argument based on, for example code signing or S/MIME would be more convincing.

", "time": "2022-07-27T15:50:57Z"}, {"author": "Uri Blumenthal", "text": "

@Jonathan - on the contrary. Doing it as a single thing sticks you with bindings you\u2019d wish you didn\u2019t have later on.

", "time": "2022-07-27T15:53:50Z"}, {"author": "Mike Ounsworth", "text": "

But speaking of TLS, one thing I don't love about \"multi cert / non-composite hybrid\" is that it forwards the complexity to the sysadmin who needs to juggle multiple certs (and potentially multiple cert chains) per server.
\nGetting your server serving its cert chain properly is already a pain point for non-crypto-literate sysadmins. Multi-cert is going to make that worse.

", "time": "2022-07-27T15:54:06Z"}, {"author": "Uri Blumenthal", "text": "

@Mike, that complexity actually is the ability of the organization to make and apply decisions that fit their needs and policies.

", "time": "2022-07-27T15:55:58Z"}, {"author": "Bas Westerbaan", "text": "

I'm confused: SPHINCS+ has very small private and public keys.

", "time": "2022-07-27T15:56:15Z"}, {"author": "Clint Wilson", "text": "

Multi-cert was successfully used, in a fairly widespread manner, during the migration from SHA-1 to SHA-2 in the Web PKI. Automation, tooling, and server management capabilities have only increased since then. This doesn't mean the argument is moot, but I do think it's much less of an issue than posited here.

", "time": "2022-07-27T15:56:26Z"}, {"author": "Jonathan Hoyland", "text": "

@Uri Understanding what the bindings mean when done at a higher layer is non-trivial. For example if you were to use Exported Authenticators to add multiple certs to a connection each cert has a cryptographic binding to the TLS connection, but the don't bind to each other. This is different from doing TLS hybrid. The crypto distinction is subtle, and understanding the implications is not easy.

", "time": "2022-07-27T15:56:29Z"}, {"author": "Tim Hollebeek", "text": "

The SHA-1 to SHA-2 transition was a drop in replacement, so the transition was quite a bit simpler than this one will be.

", "time": "2022-07-27T15:57:06Z"}, {"author": "Jonathan Hoyland", "text": "

If you have a composite cert then it's clear exactly what identity you are being presented with.

", "time": "2022-07-27T15:57:08Z"}, {"author": "Tim Hollebeek", "text": "

(and it was still hard)

", "time": "2022-07-27T15:57:18Z"}, {"author": "Deb Cooley", "text": "

@Jonathan Hoyland: and to be clear, I'm not (personally) a fan of hybrid.

", "time": "2022-07-27T15:57:21Z"}, {"author": "Uri Blumenthal", "text": "

@Jonathan, maybe nontrivial, but necessary in order to do what the organization needs. This \u201cProcrustean bed\u201d is not an acceptable answer.

", "time": "2022-07-27T15:58:06Z"}, {"author": "Rich Salz", "text": "

@Uri Blumenthal can't you control what you want by deciding what keys to be put in the cert request? What an I missing?

", "time": "2022-07-27T15:59:57Z"}, {"author": "John Gray", "text": "

@Uri could you please explain why you think a well-defined and simplified composite specification is a bad idea? We hear from many organizations that they want to use it. I agree with keeping the draft simple, and for signatures require AND mode as there is no ambiguity. We have worked with other partners on implementations and thus far it has not been difficult to implement correctly.

", "time": "2022-07-27T16:00:53Z"}, {"author": "Bas Westerbaan", "text": "

I'm a bit worried that everything is in there: for instance, the AES modes of Diltihium are all limited to level 1 or 2. They are only specified in the submission as a demonstration what hardware acceleration could do.

", "time": "2022-07-27T16:01:38Z"}, {"author": "Jabber", "text": "

dkg: i'd prefer putting the secret keys into the same documents as those that define the public keys. less of a chance for an impedance mismatch

", "time": "2022-07-27T16:03:07Z"}, {"author": "Jonathan Hoyland", "text": "

@MeetEcho adjourned

", "time": "2022-07-27T16:03:08Z"}]