:eyes:
", "time": "2025-01-08T17:10:27Z"}, {"author": "Mike Ounsworth", "text": "Always / Never Use SignedAttrs: Are you allowed empty signed attributes?
", "time": "2025-01-08T17:21:31Z"}, {"author": "Falko Strenzke", "text": "the SignedAttrs must always contain at least the messageDigest attribute
", "time": "2025-01-08T17:22:11Z"}, {"author": "Deirdre Connolly", "text": "yep
", "time": "2025-01-08T17:22:36Z"}, {"author": "Deirdre Connolly", "text": "er yep this is a new thing in the WG
", "time": "2025-01-08T17:22:55Z"}, {"author": "Scott Fluhrer", "text": "Actually, as far as we know, MD5 is second-prehash resistant
", "time": "2025-01-08T17:26:30Z"}, {"author": "Deb Cooley", "text": "are there hashes around that are not second-prehash resistant?
", "time": "2025-01-08T17:27:16Z"}, {"author": "Alicja Kario", "text": "MD4
", "time": "2025-01-08T17:27:25Z"}, {"author": "Mike Ounsworth", "text": "This may not be a popular question, but what's the CVSS score of this attack?
", "time": "2025-01-08T17:27:40Z"}, {"author": "Deb Cooley", "text": "but that hasn't been used in a really, really long time
", "time": "2025-01-08T17:27:44Z"}, {"author": "Alicja Kario", "text": "yeah, it's more of a curiosity than a realistic scenario
", "time": "2025-01-08T17:28:06Z"}, {"author": "Mike Ounsworth", "text": "IE how critical is it that we retro-fix this? Are there actual practical attacks?
", "time": "2025-01-08T17:28:09Z"}, {"author": "Deirdre Connolly", "text": "FLAME was enough
", "time": "2025-01-08T17:28:58Z"}, {"author": "Bas Westerbaan", "text": "He sent a mail to the list he cant make it
", "time": "2025-01-08T17:29:34Z"}, {"author": "Michael Richardson", "text": "Worth writing down to use context for new algorithms, worth writing down mitigation/detection for RSA/ECDSA. Whether it's worth revising Ed448, I don't know.
", "time": "2025-01-08T17:30:06Z"}, {"author": "Deirdre Connolly", "text": "lost audio
", "time": "2025-01-08T17:31:49Z"}, {"author": "Sean Turner", "text": "audio out
", "time": "2025-01-08T17:31:54Z"}, {"author": "Michael Richardson", "text": "The ladder is to be read top-down. The tree is right-to-left for older to newer, correct?
", "time": "2025-01-08T17:38:44Z"}, {"author": "Russ Housley", "text": "@Michael: The OCSP Responses are the leafs in the tree
", "time": "2025-01-08T17:40:42Z"}, {"author": "Michael Richardson", "text": "Russ Housley said:
\n\n\n@Michael: The OCSP Responses are the leafs in the tree
\n
are the newer ones on the left or right?
", "time": "2025-01-08T17:41:03Z"}, {"author": "Russ Housley", "text": "Right
", "time": "2025-01-08T17:41:19Z"}, {"author": "Rich Salz", "text": "Is this the same MTL presented at CFRG in Vancouver?
", "time": "2025-01-08T17:43:12Z"}, {"author": "Deirdre Connolly", "text": "@Rich Salz that's a good question
", "time": "2025-01-08T17:43:23Z"}, {"author": "Russ Housley", "text": "Same crypto mode. Appllication to OCSP is new
", "time": "2025-01-08T17:43:38Z"}, {"author": "Rich Salz", "text": "@Russ, that's important point worth saying on mic. :)
", "time": "2025-01-08T17:44:11Z"}, {"author": "Mike Ounsworth", "text": "The savings of MTL Mode are batch signing and batch verification, right?
\nThat maps very well to DNSSEC, and we sorta figured that OCSP looks a bit like DNSSEC in that a single signer needs to produce (m|b)illions of signatures every day, and often a single client will need to verify multiple signatures from the same signer (if I remember the premise properly, John has been much more involved in this than me)
OCSP, when not stapled, is similar. Browsers tried to go to stapled everything, I think, failed, and then went for out-of-band bulk download to avoid privacy violating RTT to the OCSP server... my impression is that we are in an intermediate state with maximal badness.
", "time": "2025-01-08T17:51:33Z"}, {"author": "Bas Westerbaan", "text": "WebPKI is moving away from OCSP. So this would be for non WebPKI use cases.
", "time": "2025-01-08T17:52:22Z"}, {"author": "Alicja Kario", "text": "correct: the idea is sound, but it may not be beneficial enough for deployment
", "time": "2025-01-08T17:52:44Z"}, {"author": "Michael Richardson", "text": "It's an interesting idea
\nBas Westerbaan said:
\n\n\nWebPKI is moving away from OCSP. So this would be for non WebPKI use cases.
\n
yeah, okay. So we went that way, failed, and now we are doing a different direction.
", "time": "2025-01-08T17:52:48Z"}, {"author": "Bas Westerbaan", "text": "OCSP staple is like a short lived certificate anyway
", "time": "2025-01-08T17:53:36Z"}, {"author": "Alicja Kario", "text": "OCSP stapling failed because of operational complexity, this won't make deploying it easier
", "time": "2025-01-08T17:54:13Z"}, {"author": "Rich Salz", "text": "I'd kinda prefer MTL status to seven-day expiration as CABF is currently considering.
", "time": "2025-01-08T17:54:29Z"}, {"author": "Bas Westerbaan", "text": "MTL doesn't fix why OCSP failed in WebPKI. It just means CAs need to buy less HSMs.
", "time": "2025-01-08T17:55:40Z"}, {"author": "Rich Salz", "text": "Disagree, Alicja. OCSP failedon the WebPKI because of browser privacy concerns and their moves to stop doing it.
", "time": "2025-01-08T18:00:10Z"}, {"author": "Alicja Kario", "text": "I'm talking about OCSP _stapling_ there are no privacy concerns with stapling
", "time": "2025-01-08T18:00:44Z"}, {"author": "Michael Richardson", "text": "I don't think I understood Russ/John interaction well enough to capture it.
", "time": "2025-01-08T18:00:47Z"}, {"author": "Bas Westerbaan", "text": "MTL doesn't fix the privacy concerns, so I guess we agree?
", "time": "2025-01-08T18:00:48Z"}, {"author": "Michael Richardson", "text": "Alicja Kario said:
\n\n\nI'm talking about OCSP _stapling_ there are no privacy concerns with stapling
\n
yeah, stapling gets rid of the privacy issues with OCSP.
", "time": "2025-01-08T18:01:08Z"}, {"author": "Mike Ounsworth", "text": "I was gonna say that for the NSA Related Certs draft, we suggested that they do it this way, but it didn't fit their usecase, so we started our own draft :)
", "time": "2025-01-08T18:01:09Z"}, {"author": "Sean Turner", "text": "ack!
", "time": "2025-01-08T18:01:29Z"}, {"author": "Alison Becker", "text": "the related certs draft is only for when one certificate was already issued, so it's fairly different than this discovery work in that aspect
", "time": "2025-01-08T18:03:24Z"}, {"author": "Mike Ounsworth", "text": "Related Certs also assumes that the verifier can easily look up the related cert by cert hash. We are targeting a different problem, which is \"you have one cert from the pair and want to discover that the other one exists\".
", "time": "2025-01-08T18:07:54Z"}, {"author": "Rich Salz", "text": "@Alica, I misunderstood and agree with you about stapling.
", "time": "2025-01-08T18:09:31Z"}, {"author": "Alicja Kario", "text": ":+1:
", "time": "2025-01-08T18:10:29Z"}, {"author": "Alison Becker", "text": "@Mike no, it doesn't look up the cert by hash, it has a location field that is a pointer to a location via https or dataURI
", "time": "2025-01-08T18:11:57Z"}, {"author": "Sean Turner", "text": ":rolling_on_the_floor_laughing:
", "time": "2025-01-08T18:12:23Z"}, {"author": "Christopher Patton", "text": "excellent start, David Ben
", "time": "2025-01-08T18:12:29Z"}, {"author": "Deirdre Connolly", "text": ":joy:
", "time": "2025-01-08T18:12:53Z"}, {"author": "Mike Ounsworth", "text": "Alison Becker said:
\n\n\n@Mike no, it doesn't look up the cert by hash, it has a location field that is a pointer to a location via https or dataURI
\n
draft-ietf-lamps-cert-binding-for-multi-auth-06:
\n-- X.509 Certificate extension\n RelatedCertificate ::= OCTET STRING\n -- hash of entire related certificate }\nyes, that hash is in the extension, not the attribute
", "time": "2025-01-08T18:14:14Z"}, {"author": "Mike Ounsworth", "text": "X.509 certificates don't have attributes. CSRs have attributes, but certs don't. I'm confused.
", "time": "2025-01-08T18:14:54Z"}, {"author": "Alison Becker", "text": "yeah, that hash is in the extension, there's no hash in the csr where the cert is looked up
", "time": "2025-01-08T18:15:32Z"}, {"author": "Alicja Kario", "text": "the self-signatures do make sure that the root CA cert is self-contained and not modifiable
", "time": "2025-01-08T18:15:36Z"}, {"author": "Deirdre Connolly", "text": "definitely a mistake
", "time": "2025-01-08T18:16:34Z"}, {"author": "Mike Ounsworth", "text": "Right. The problem that draft-cert-binding doesn't solve is \"I am trying to email you and I have your RSA cert. Before I encrypt and send this email, I want to know if any other versions of your S/MIME cert exists\".
\nI think that's just a completely different problem statement than the one you're trying to solve?
Yeah we have the following in CMC (RFC 5272/6402): id-alg-noSignature OBJECT IDENTIFIER ::= { id-pkix id-alg(6) 2 }
", "time": "2025-01-08T18:17:10Z"}, {"author": "Bas Westerbaan", "text": "Kario, well, you can modify it by changing the public key to one you control the private key of and create a new sig.
", "time": "2025-01-08T18:17:30Z"}, {"author": "Alicja Kario", "text": "yes, but then it won't verify the cert chains you expect it to...
", "time": "2025-01-08T18:17:54Z"}, {"author": "Alison Becker", "text": "@Mike right, it is different, which is why i was saying that the related certs draft has different assumptions (like the cert being previously issued) than the discovery draft does, but the lookup of the related certificate does not depend on looking up a certificate by cert hash, like you stated
", "time": "2025-01-08T18:18:23Z"}, {"author": "Sean Turner", "text": "We are working on obsoleting RFC 5272 ;)
", "time": "2025-01-08T18:18:54Z"}, {"author": "Mike Ounsworth", "text": "I mean \"lookup of the cert\" in the context of my email client trying to look up which certificate to encrypt the email for.
\nI think we're on the same page :)
I have implemented this draft in WebRTC and successfully interoperated with Chrome's WebRTC stack
", "time": "2025-01-08T18:19:35Z"}, {"author": "Alison Becker", "text": "yeah we are, just crossed wires i think! i know we've discussed this before lol
", "time": "2025-01-08T18:20:24Z"}, {"author": "Sean Turner", "text": "id-alg-srlsyNoSignature
", "time": "2025-01-08T18:23:27Z"}, {"author": "Bas Westerbaan", "text": "maybe call it id-alg-invalid-signature
", "time": "2025-01-08T18:25:51Z"}, {"author": "Bas Westerbaan", "text": "or id-alg-dont-implement-me-please
", "time": "2025-01-08T18:26:12Z"}, {"author": "Mike Ounsworth", "text": "I particularly like:
\n\n\napplications are RECOMMENDED to satisfy these requirements by ignoring this document. An unmodified X.509 validator will not recognize id-alg-noSignature and is thus already expected to reject it in the certification path.
\n
IE a correct implementation ignores the existence of this RFC.
", "time": "2025-01-08T18:26:29Z"}, {"author": "Sean Turner", "text": "And for the record, I am totally fine with adopting this idea into CSRs (at least into CMC). I have to admit I am unsure how widely it got deployed because it was mostly designed to be used by Subscribers who only had a DH cert.
", "time": "2025-01-08T18:26:44Z"}, {"author": "Jonathan Lennox", "text": "The main benefit of davidben's draft would be to get Wireshark to recognize the OID.
", "time": "2025-01-08T18:29:02Z"}, {"author": "Mike Ounsworth", "text": "I begrudgingly admit that is makes sense to have a way to omit a PQ signature on objects where you know it will never be verified. Although the similarities to JWT alg-none give me the heebee-jeebies.
", "time": "2025-01-08T18:29:09Z"}, {"author": "Alicja Kario", "text": "yes, and thus I'd prefer to formalise putting \"OCTETSTRING:I'm not a signature\" in places where we have signatures that are never expected to be verified
", "time": "2025-01-08T18:30:25Z"}, {"author": "Alicja Kario", "text": "then when it ends up in a place where it's tried to be validated, it will simply explode, which is good
", "time": "2025-01-08T18:30:57Z"}, {"author": "Jonathan Lennox", "text": "Or id-alg-notASignature or something like that so implementors know not to have it validate
", "time": "2025-01-08T18:30:58Z"}, {"author": "Alicja Kario", "text": "having a n id-alg-noSignature has a high chance of the same issue as we had in Java TLS state machine, where it would accept any state transition (any handshake message in any order)
", "time": "2025-01-08T18:31:54Z"}, {"author": "Bas Westerbaan", "text": "id-alg-dontImplementMeNotASignatureAlwaysReturnInvalidPlease
", "time": "2025-01-08T18:33:40Z"}, {"author": "Mike Ounsworth", "text": "This may not be well said in the draft-truskovesky Tombstone Notice, but the other major downside is that these certs are hard to actually use. The X9 group has been playing with using them in TLS, and you need a whole new TLS ClientHello extension to negotiate whether you support this extension, and whether you want TLS to be signed with the primary or alt key. For CMS, how do you use it? Create two SignerInfos that both point to the same cert and hope that legacy clients don't choke on that?
", "time": "2025-01-08T18:34:05Z"}, {"author": "Jonathan Lennox", "text": "I mean you want to implement it on the generation side, that's the whole point.
", "time": "2025-01-08T18:34:42Z"}, {"author": "Mike Ounsworth", "text": "Like, the whole purpose of draft-truskovksy certs is backwards compatibility, but you lose that very quickly when you actually try to use it in a protocol that doesn't have a way to carry multiple (ignorable) signatures.
", "time": "2025-01-08T18:34:51Z"}, {"author": "David Benjamin", "text": "Using an empty OCTET STRING also leaves ambiguous questions like... should a \"self-signed\" end-entity TLS certificate still include the keyCertSign key usage extension? You don't actually intend for the key to be used with X.509, but it is claiming to sign itself, just doing a bad job of it. (Though we could certainly go put in some text to say so.)
", "time": "2025-01-08T18:36:58Z"}, {"author": "David Benjamin", "text": "Also what sigalg OID do you use if it's an key type that supports multiple sigalgs? What do you use if it's a key that supports none?
", "time": "2025-01-08T18:37:26Z"}, {"author": "Deirdre Connolly", "text": "\n\nhard to use
\n
:+1:
", "time": "2025-01-08T18:39:03Z"}, {"author": "Deirdre Connolly", "text": "means it will be less tested and more fraught
", "time": "2025-01-08T18:39:17Z"}, {"author": "Alicja Kario", "text": "@David: from what I've seen, things that just use X.509 to have a nice way to transfer public key around completely ignore all and any extensions on the certificate
", "time": "2025-01-08T18:40:19Z"}, {"author": "Michael Richardson", "text": "https://notes.ietf.org/notes-ietf-interim-2025-lamps-01-lamps where I'm taking notes, and not seeing anyone else in this HedgeDoc.
", "time": "2025-01-08T18:40:41Z"}, {"author": "David Benjamin", "text": "Not exclusively. AIUI WebRTC actually cares about the expiration. And, in general, you may want other subject information. (Indeed X.509 is particularly bad about this, where the distinction between ECDH and ECDSA keys is not in the SPKI but in the key usage extension.
", "time": "2025-01-08T18:41:08Z"}, {"author": "John Gray", "text": "Just caught up on some discussions.... between writing the notes. We think MTL may help with the privacy concern because a single MTL signature over the ladder covers all authentication paths, so leakage about specific information can be mitigated, but we can obviously look at that in more detail. We think that can be a plus of MTL revocation.
", "time": "2025-01-08T18:41:43Z"}, {"author": "David Benjamin", "text": "TLS also uses key usage to separate legacy RSA key exchange and from modern signing modes. (Indeed our stack will check that even if you tell it to accept the EE cert regardless, because we consider it part of the definition of the key.)
", "time": "2025-01-08T18:42:39Z"}, {"author": "Bas Westerbaan", "text": "John, the authentication path leaks the cert \"signed\"
", "time": "2025-01-08T18:42:41Z"}, {"author": "Alicja Kario", "text": "@David but then that's not really a problem... anyway, sounds like something good to discuss on the ML
", "time": "2025-01-08T18:42:42Z"}, {"author": "Bas Westerbaan", "text": "John, the OCSP server still learns identity of cert.
", "time": "2025-01-08T18:43:22Z"}, {"author": "John Gray", "text": "Bas, I think you mean the revocation data. Good point though, I guess the auth path does pinpoint the cert data. Perhaps it can be obfuscated in some way... We just used OCSP as an example of the efficiency that could be gained, but I think the end result wouldn't be OCSP... Would love to collaborate with you more on how this could potentially be mitigated if you are interested.
", "time": "2025-01-08T18:45:51Z"}, {"author": "Alicja Kario", "text": "@John: the OCSP response is still is for a single certificate, that's where the leakage comes from
", "time": "2025-01-08T18:46:03Z"}, {"author": "Bas Westerbaan", "text": "John, private online lookups is something I'm quite interested in for a different problem: the SCT auditing problem. https://www.youtube.com/watch?v=f8unMB2Qjho That's perhaps quite far from MTL.
\nhas anyone proposed MTL for certificate transparency? that seems to me like a much more aligned use case...
", "time": "2025-01-08T18:53:08Z"}, {"author": "Bas Westerbaan", "text": "Well... https://datatracker.ietf.org/doc/draft-davidben-tls-merkle-tree-certs/
", "time": "2025-01-08T18:53:27Z"}, {"author": "Bas Westerbaan", "text": "David presented it at 116 ( https://youtu.be/u_sFyz4F7dc?si=inG4bgBwKLzrBuvY&t=2566 )
\nthat seems about the certs themselves, not the transparency logs or proofs of inclusion
", "time": "2025-01-08T18:56:06Z"}, {"author": "Bas Westerbaan", "text": "MTC combines CT and certs in one system.
", "time": "2025-01-08T18:56:23Z"}, {"author": "Alicja Kario", "text": "(just skimmed through it obviously, so might be misinterpreting it)
", "time": "2025-01-08T18:56:35Z"}, {"author": "Bas Westerbaan", "text": "MTL is very similar to the tree currently used in CT btw, if you look at how that tree grows.
", "time": "2025-01-08T18:56:44Z"}, {"author": "Deirdre Connolly", "text": "Where is regen from seed not FIPS?
", "time": "2025-01-08T18:56:45Z"}, {"author": "Deirdre Connolly", "text": "Oh yeah
", "time": "2025-01-08T18:57:20Z"}, {"author": "Deirdre Connolly", "text": "hm
", "time": "2025-01-08T18:57:22Z"}, {"author": "Bas Westerbaan", "text": "We can ask NIST to add this to 800-227
", "time": "2025-01-08T18:58:23Z"}, {"author": "Alicja Kario", "text": "@Bas but the point of CTs is that we want a log run by a different party than the one signing...
", "time": "2025-01-08T18:58:23Z"}, {"author": "Bas Westerbaan", "text": "and I think you did, Mike
", "time": "2025-01-08T18:58:28Z"}, {"author": "Mike Ounsworth", "text": "Bas Westerbaan said:
\n\n\nand I think you did, Mike
\n
Yup. I sure did, yesterday already :)
", "time": "2025-01-08T18:58:49Z"}, {"author": "Bas Westerbaan", "text": "Alicja, I don't think that's required. Also, CAs run their own CT logs.
", "time": "2025-01-08T18:58:53Z"}, {"author": "Sean Turner", "text": "I asked for WGLC on ML-KEM certs I-D :)
", "time": "2025-01-08T18:59:00Z"}, {"author": "Sean Turner", "text": "Will ping Mike about ML-DSA certs I-D :)
", "time": "2025-01-08T18:59:17Z"}, {"author": "John Gray", "text": "ALicja, I agree, but we would like to look at how that could be mitigated by the MTL structure... I haven't thought about that enough.
", "time": "2025-01-08T18:59:19Z"}, {"author": "Jan Klau\u00dfner", "text": "bye!
", "time": "2025-01-08T18:59:28Z"}]