DKG, can we not talk about age?
", "time": "2023-07-27T20:00:08Z"}, {"author": "Daniel Gillmor", "text": "they're more about trying to capture what's happening in the room that is a surprise
", "time": "2023-07-27T20:00:11Z"}, {"author": "Daniel Gillmor", "text": "Deb Cooley said:
\n\n\nDKG, can we not talk about age?
\n
i can't remember
", "time": "2023-07-27T20:00:31Z"}, {"author": "Uri Blumenthal", "text": ":joy:
", "time": "2023-07-27T20:02:01Z"}, {"author": "Daniel Gillmor", "text": "@Bernie Hoeneisen i cheated and made one slide deck for both e2e-mail-guidance and header-protection, so they'll both happen as soon as Russ and Tim let me get to the mic
", "time": "2023-07-27T20:03:50Z"}, {"author": "Tim Hollebeek", "text": "That's fine, and thanks for letting us know.
", "time": "2023-07-27T20:04:56Z"}, {"author": "Roman Danyliw", "text": "One more addition to documents with the IESG/RFCEd = draft-ietf-lamps-nf-eku
", "time": "2023-07-27T20:05:17Z"}, {"author": "Tim Hollebeek", "text": "Yes, I missed that one putting the agenda together, it seems. Thank you.
", "time": "2023-07-27T20:06:04Z"}, {"author": "Daniel Gillmor", "text": "Limited Acroynms for Messaging and PKIX Stuff
", "time": "2023-07-27T20:07:22Z"}, {"author": "Stephen Farrell", "text": "so 'case it helps, I'll answer dkg's mail about -guidance and get out of the way
", "time": "2023-07-27T20:17:24Z"}, {"author": "Tim Hollebeek", "text": "Let's All Make Pretty Sertificates!
", "time": "2023-07-27T20:19:31Z"}, {"author": "Thom Wiggers", "text": "the glasses match the slides
", "time": "2023-07-27T20:27:41Z"}, {"author": "Mike Ounsworth", "text": "(deleted)
", "time": "2023-07-27T20:28:07Z"}, {"author": "Uri Blumenthal", "text": ":grin::thumbsup:
", "time": "2023-07-27T20:28:41Z"}, {"author": "Uri Blumenthal", "text": "Mike R., free ASN.1 compilers do not support the latest ASN.1 capabilities, so it would be GREAT if you could add definitions in \"old\" ASN.1.
", "time": "2023-07-27T20:32:20Z"}, {"author": "Stephen Farrell", "text": "Stephen Farrell said:
\n\n\nso 'case it helps, I'll answer dkg's mail about -guidance and get out of the way
\n
Mail sent, sorry for being slow.
", "time": "2023-07-27T20:33:17Z"}, {"author": "Daniel Gillmor", "text": "@Uri Blumenthal or maybe someone\u2122 could contribute fixes to the free ASN.1 compilers?
", "time": "2023-07-27T20:33:22Z"}, {"author": "Daniel Gillmor", "text": "i'm not volunteering, sorry, my plate is full
", "time": "2023-07-27T20:35:02Z"}, {"author": "Daniel Gillmor", "text": "and if i was going to work on abstract data formats, ASN.1 would not be on the top of my list anyway :melting_face:
", "time": "2023-07-27T20:35:47Z"}, {"author": "Uri Blumenthal", "text": "@Daniel, the complexity of what you're suggesting is too big - adding language capability to an already-complicated compiler. No joy.
", "time": "2023-07-27T20:36:09Z"}, {"author": "Thom Wiggers", "text": "Uri, just wanted to highlight that you're talking about ASN.1 and joy in one sentence
", "time": "2023-07-27T20:37:11Z"}, {"author": "Uri Blumenthal", "text": ":rolling_on_the_floor_laughing:
", "time": "2023-07-27T20:39:48Z"}, {"author": "Pete Resnick", "text": ":face_palm:
", "time": "2023-07-27T20:40:32Z"}, {"author": "Uri Blumenthal", "text": "@Thom, ASN.1 used to be somewhat decent and parse-able. but at 7030-level it's 100% un-grok-able. :-(
", "time": "2023-07-27T20:40:51Z"}, {"author": "Deb Cooley", "text": "There is at least one cheap HSM....
", "time": "2023-07-27T20:41:20Z"}, {"author": "Uri Blumenthal", "text": "If you count Yubico YubiHSM2 (which I use) - then yes, it's quite capable, and costs below $700. Not sure what other HSM devices you would consider \"cheap\".
", "time": "2023-07-27T20:42:24Z"}, {"author": "Phillip Hallam-Baker", "text": "@deb, how cheap is 'cheap' though?
", "time": "2023-07-27T20:43:21Z"}, {"author": "Deb Cooley", "text": "We can talk after
", "time": "2023-07-27T20:43:45Z"}, {"author": "Thom Wiggers", "text": "the yubikeys appear to be \"overall FIPS level 2, physical level 3\" whatever that means
", "time": "2023-07-27T20:44:38Z"}, {"author": "Thom Wiggers", "text": "both just the regular FIPS yubikey 5 and YubiHSM
", "time": "2023-07-27T20:45:00Z"}, {"author": "Deb Cooley", "text": "The smartcards DOD/US Fed uses are FIPS 140 level 2, physical level 3.
", "time": "2023-07-27T20:45:55Z"}, {"author": "Deb Cooley", "text": "just means that the physical protection parts meet level 3
", "time": "2023-07-27T20:46:15Z"}, {"author": "Deb Cooley", "text": "but everything else is level 2 hardware
", "time": "2023-07-27T20:46:25Z"}, {"author": "Deb Cooley", "text": "happy to know what Yubikey is....
", "time": "2023-07-27T20:46:41Z"}, {"author": "Thom Wiggers", "text": "yeah I suppose the question was \"whatever that means in the context of the previous discussion\"
", "time": "2023-07-27T20:46:42Z"}, {"author": "Roman Danyliw", "text": "Is the RATS Conceptual Message Wrapper the same as draft-ftbs-rats-msg-wrap-03? An unadopted document?
", "time": "2023-07-27T20:47:27Z"}, {"author": "Corey Bonnell", "text": "https://cabforum.org/wp-content/uploads/Baseline-Requirements-for-the-Issuance-and-Management-of-Code-Signing.v3.3.pdf
\nSection 6.2.7.4.1 Subscriber Private Key protection
@Deb, AFAIK, YubiHSM2 is FIPS 140-3, but I can't swear to that (or at that :slightly_smiling_face:)
", "time": "2023-07-27T20:48:36Z"}, {"author": "Corey Bonnell", "text": "...\"Effective June 1, 2023, Subscriber Private Keys for Code Signing Certificates SHALL be
\nprotected per the following requirements. The CA MUST obtain a contractual
\nrepresentation from the Subscriber that the Subscriber will use one of the following
\noptions to generate and protect their Code Signing Certificate Private Keys in a
\nHardware Crypto Module with a unit design form factor certified as conforming to at
\nleast FIPS 140\u20102 Level 2 or Common Criteria EAL 4+\"...
The initial work preceded CAB forum and is valuable independent of CAB forum requirement
", "time": "2023-07-27T20:48:51Z"}, {"author": "Deb Cooley", "text": "Uri: look up the chat...
", "time": "2023-07-27T20:48:54Z"}, {"author": "Tomofumi Okubo", "text": "Level 2...
", "time": "2023-07-27T20:49:10Z"}, {"author": "Bas Westerbaan", "text": "Does it have to be in the CSR or could it be beside it?
", "time": "2023-07-27T20:49:38Z"}, {"author": "Watson Ladd", "text": "Bas Westerbaan said:
\n\n\nDoes it have to be in the CSR or could it be beside it?
\n
I think the problem is only the csr plumbs through
", "time": "2023-07-27T20:50:17Z"}, {"author": "Uri Blumenthal", "text": ":thumbsup:
", "time": "2023-07-27T20:50:22Z"}, {"author": "Henk Birkholz", "text": "Passport, I meant :see_no_evil:
", "time": "2023-07-27T20:50:34Z"}, {"author": "Florence D", "text": "Everyone commenting on this draft should check what the notes say because I know very little about the details of attestation
", "time": "2023-07-27T20:50:48Z"}, {"author": "Sander Temme", "text": "@Deb Cooley Yubico sells a number of small form factor modules that do things like OTP. They also have an HSM-like variant for which they have a FIPS 140-2 Level 3 certificate
", "time": "2023-07-27T20:51:34Z"}, {"author": "Watson Ladd", "text": "You're making an unwarranted assumption about commenting I'm afraid
", "time": "2023-07-27T20:51:39Z"}, {"author": "Henk Birkholz", "text": "+1 to Ned for being precise here
", "time": "2023-07-27T20:52:43Z"}, {"author": "Florence D", "text": "Watson Ladd said:
\n\n\nYou're making an unwarranted assumption about commenting I'm afraid
\n
I'm hoping people at least know what they said. No other assumptions :smile: (if this was addressed to me)
", "time": "2023-07-27T20:55:22Z"}, {"author": "Carl Wallace", "text": "@Mike Ounsworth defining an extension does not mean for certs. the prior draft ought have language to support extension or attribute, which was the point on the list.
", "time": "2023-07-27T20:56:09Z"}, {"author": "Carl Wallace", "text": "no code signing is not all that is of interest to the group at large
", "time": "2023-07-27T20:56:35Z"}, {"author": "Carl Wallace", "text": "the already accepted draft predates the code signing focus.
", "time": "2023-07-27T20:56:54Z"}, {"author": "Carl Wallace", "text": "mic re: the above please (sorry for absence)
", "time": "2023-07-27T20:57:25Z"}, {"author": "Bas Westerbaan", "text": "Agree with PHB on threshold
", "time": "2023-07-27T20:59:02Z"}, {"author": "Uri Blumenthal", "text": "So, what up with Kyber certificates?
", "time": "2023-07-27T21:00:42Z"}, {"author": "Thom Wiggers", "text": "same as Dilithium aiui
", "time": "2023-07-27T21:01:00Z"}, {"author": "Mike Ounsworth", "text": "Carl Wallace said:
\n\n\nMike Ounsworth defining an extension does not mean for certs. the prior draft ought have language to support extension or attribute, which was the point on the list.
\n
Right; I need to go brush up on CRMF.
", "time": "2023-07-27T21:01:12Z"}, {"author": "Uri Blumenthal", "text": "@Thom, one unpleasant difference is that, unlike Dilithium, you can't create a CSR for Kyber certificate.
", "time": "2023-07-27T21:03:03Z"}, {"author": "Bas Westerbaan", "text": "On SPHINCS+, my guess is that we'll see all the SHA2 and SHAKE variants, but not the Haraka.
", "time": "2023-07-27T21:03:17Z"}, {"author": "Thom Wiggers", "text": "I am aware; I just don't think that draft covers issuance
", "time": "2023-07-27T21:03:25Z"}, {"author": "Bas Westerbaan", "text": "Uri Blumenthal said:
\n\n\n@Thom, one unpleasant difference is that, unlike Dilithium, you can't create a CSR for Kyber certificate.
\n
You can with a zero-knowledge proof. Would require quite some work to standardise though.
", "time": "2023-07-27T21:03:41Z"}, {"author": "Bas Westerbaan", "text": "Another question though is: do we really need PoP? I do not know.
", "time": "2023-07-27T21:03:57Z"}, {"author": "Uri Blumenthal", "text": "@Bas, do you mean \"Proof of Possession\", or \"CSR\"? I agree that PoP can be done in multiple ways - my point is that CSR seems impossible.
", "time": "2023-07-27T21:04:31Z"}, {"author": "Uri Blumenthal", "text": "And yes - we do want PoP. IMHO, at least.
", "time": "2023-07-27T21:04:44Z"}, {"author": "Bas Westerbaan", "text": "Uri Blumenthal said:
\n\n\n@Bas, do you mean \"Proof of Possession\", or \"CSR\"? I agree that PoP can be done in multiple ways - my point is that CSR seems impossible.
\n
You can turn Kyber into a signature scheme, by proving in zero knowledge you know the private key and binding the message.
", "time": "2023-07-27T21:04:57Z"}, {"author": "Uri Blumenthal", "text": "@Bas, perhaps you can contact me offline and show the details?
", "time": "2023-07-27T21:05:30Z"}, {"author": "Michael Jenkins", "text": "Isn't that the original text?
", "time": "2023-07-27T21:06:17Z"}, {"author": "Ned Smith", "text": "\n", "time": "2023-07-27T21:07:06Z"}, {"author": "Thom Wiggers", "text": "Another question though is: do we really need PoP? I do not know.
\n
https://www.douglas.stebila.ca/research/papers/CCS-GHLOSZ22/ has some discussion on \"do we care about PoP\" in appendix A
", "time": "2023-07-27T21:07:26Z"}, {"author": "Bas Westerbaan", "text": "Uri Blumenthal said:
\n\n\n@Bas, perhaps you can contact me offline and show the details?
\n
Sure. There are multiple approaches. The most promising seems to be this zero-knowledge proof system of which Kyber proof-of-possession is the simplest application. https://link.springer.com/chapter/10.1007/978-3-031-15979-4_3
\nI believe Gregor Seiler is working on an actual implementation of this.
", "time": "2023-07-27T21:07:39Z"}, {"author": "Ned Smith", "text": "PoP is an interesting question if a root of trust / HSM uses an attestable key to sign the CSR.
", "time": "2023-07-27T21:08:00Z"}, {"author": "Jonathan Hammell", "text": "Michael Jenkins said:
\n\n\nIsn't that the original text?
\n
The proposed text clarified what might go into the ukm, since previously it mentioned KDF-specific things like the salt which would not.
", "time": "2023-07-27T21:08:18Z"}, {"author": "Thom Wiggers", "text": "without paywall https://eprint.iacr.org/2022/284
", "time": "2023-07-27T21:08:18Z"}, {"author": "Bas Westerbaan", "text": "Off-topic, they made a rap video for the paper: https://www.youtube.com/watch?v=2uVsVYtedVQ
\n\n", "time": "2023-07-27T21:12:50Z"}, {"author": "Jonathan Hammell", "text": "The proposed text clarified... Predictably, I am okay with text that clarifies what one puts into a ukm that I don't want to use :smile: The text that I care about is the \"gracefully reject\" and I am good with that text.
\n
\"gracefully reject\" is very polite
", "time": "2023-07-27T21:13:50Z"}, {"author": "Thom Wiggers", "text": "Bas Westerbaan said:
\n\n\nOff-topic, they made a rap video for the paper: https://www.youtube.com/watch?v=2uVsVYtedVQ
\n
\"lattice based zero knowledge proofs hey!\" will echo around my head for yet another week, thanks
", "time": "2023-07-27T21:14:12Z"}, {"author": "Deb Cooley", "text": "he tries...
", "time": "2023-07-27T21:14:13Z"}, {"author": "Yoav Nir", "text": "I think the people who said, \"we don't want hybrid signatures\" all knew that this was about certificates and such
", "time": "2023-07-27T21:15:03Z"}, {"author": "Yoav Nir", "text": "I mean, that's why it was proposed at LAMPS and not, say, IPsecME or TLS
", "time": "2023-07-27T21:15:29Z"}, {"author": "Deb Cooley", "text": "to be fair there is a big difference in document signing and TLS session establishment
", "time": "2023-07-27T21:16:25Z"}, {"author": "Jonathan Hammell", "text": "\"we don't want hybrid signatures\" is not as polite as \"gracefully reject\" :grinning:
", "time": "2023-07-27T21:16:26Z"}, {"author": "Deb Cooley", "text": "I struggle with being polite
", "time": "2023-07-27T21:16:46Z"}, {"author": "Michael StJohns", "text": "@carlwallace - defining an extension vs a csr attribute is trivial, and can be added to the asn1 module once you settle on the structure of the structure contained within the attribute. E.g. AttestAttribute ::= ATTRIBUTE { AttestStructure IDENTIFIED BY id-attestStructure-oid} maps directly as AttestExtension ::= EXTENSION { SYNTAX AttestStructure IDENTIFIED BY id-AttestStructure-oid }. So I\u2019d not the need and defer the definition until the structure definition is stable. If you want the extension to contain different info than the extension, then you\u2019ll need to define a different structure and get a different oid. One of the reasons I keep arguing against including the certificates in the structure is the possible use of the structure as an extension for the other pkix related protocols.
", "time": "2023-07-27T21:17:21Z"}, {"author": "Michael StJohns", "text": "Note the need. Sigh.
", "time": "2023-07-27T21:17:58Z"}, {"author": "Bas Westerbaan", "text": "Seriously though, SHA3 is easier to use than SHA2. Compare KMAC vs HMAC
", "time": "2023-07-27T21:20:29Z"}, {"author": "Bas Westerbaan", "text": "Or compare the details of SPHINCS+ for SHA3 and SHA2.
", "time": "2023-07-27T21:20:47Z"}, {"author": "Uri Blumenthal", "text": "There is no known evidence of weaknesses in SHA-2. Except for lack of defense against length/message extension. It's not likely we'll get collisions like with SHA-1.
", "time": "2023-07-27T21:21:07Z"}, {"author": "Jessica Krynitsky", "text": "Who is presenting right now? Didn't introduce himself and there's no name on the room feed
", "time": "2023-07-27T21:21:11Z"}, {"author": "Daniel Gillmor", "text": "That was @Watson Ladd
", "time": "2023-07-27T21:21:25Z"}, {"author": "Jessica Krynitsky", "text": "Sorry, not the person asking the question but the person presenting this draft
", "time": "2023-07-27T21:21:47Z"}, {"author": "Bas Westerbaan", "text": "Uri Blumenthal said:
\n\n\nThere is no known evidence of weaknesses in SHA-2. Except for lack of defense against length/message extension. It's not likely we'll get collisions like with SHA-1.
\n
Also the small pipe is annoying. See the attack of Sidney Antonov on SPHINCS+-sha2
", "time": "2023-07-27T21:24:08Z"}, {"author": "Corey Bonnell", "text": "Jessica Krynitsky said:
\n\n\nSorry, not the person asking the question but the person presenting this draft
\n
Tadahiko Ito, not me :)
", "time": "2023-07-27T21:24:40Z"}, {"author": "Jessica Krynitsky", "text": "thank you Corey!
", "time": "2023-07-27T21:25:05Z"}, {"author": "Mike Ounsworth", "text": "Ned Smith said:
\n\n\nPoP is an interesting question if a root of trust / HSM uses an attestable key to sign the CSR.
\n
This is a most interesting point.
\nThe signature on the CSR serves both as PoP, and integrity-protection of the CSR. It is still valuable for the latter even if the attestation accomplishes the former.
@Bas, I'm not sure Antonov's attack is relevant here - but yes, small pipe is a disadvantage... I'm just concerned with the efforts of move - and notice that even now there are entities that did not move from SHA-1 to SHA-2 yet...
", "time": "2023-07-27T21:25:57Z"}, {"author": "Bas Westerbaan", "text": "Here SHA2 will do just as well as SHA3, but I just want to push back hard against the weak argument that SHA3 is just the shiny new thing. It's actually a better primitive.
", "time": "2023-07-27T21:26:48Z"}, {"author": "Carl Wallace", "text": "@Michael StJohns I understand defining extension or attribute is simple. As far as I know, the conveyance structure is stable enough to address the comment (not from me) on the list asking for an extension. Will defer to @Mike Ounsworth
", "time": "2023-07-27T21:27:17Z"}, {"author": "Uri Blumenthal", "text": "Point is - it's not THAT much better, as to justify the pain of migration. Not that I have a horse in this race, anyway.
", "time": "2023-07-27T21:27:30Z"}, {"author": "Jonathan Hoyland", "text": "I wanted to know about compromise cert attestation actually. Shame we skipped
", "time": "2023-07-27T21:27:46Z"}, {"author": "David Benjamin", "text": "There are costs to having extra algorithms. One needs to maintain fast implementations for the full Cartesian product of {important algorithms} x {important hardware}. And this is ignoring SHA-3 being unreasonably slow because they picked the parameters wrong... which compounds all this because we need to put more work to hit perf targets.
", "time": "2023-07-27T21:29:22Z"}, {"author": "Bas Westerbaan", "text": "Uri Blumenthal said:
\n\n\nPoint is - it's not THAT much better, as to justify the pain of migration. Not that I have a horse in this race, anyway.
\n
That I agree with. But when we do new things, let's do them just with TurboSHAKE.
", "time": "2023-07-27T21:29:29Z"}, {"author": "Deb Cooley", "text": "Did Russ want 'Bob'?
", "time": "2023-07-27T21:29:55Z"}, {"author": "David Benjamin", "text": "TurboSHAKE does fix the round count... and is not SHA-3. And it still carries the multiplicative costs of supporting new primitives.
", "time": "2023-07-27T21:30:26Z"}, {"author": "Daniel Gillmor", "text": "seems like this isn't just about signalling supported algorithms, but also about signalling desired identity (e.g. SNI)
", "time": "2023-07-27T21:32:13Z"}, {"author": "Jonathan Hoyland", "text": "Also, SHA3 isn't a _new_ shiny thing, it has its eighth birthday next week
", "time": "2023-07-27T21:33:12Z"}, {"author": "Uri Blumenthal", "text": "First, I have a big concern regarding truncating # of rounds and such, because today we don't know a better attack. Second, NIST officially stated that they will not standardize reduced-round Keccak - thus, TurboSHAKE will not be NIST-\"blessed\". Which, in turn, means that several vendors won't be able to offer it.
", "time": "2023-07-27T21:33:59Z"}, {"author": "Bas Westerbaan", "text": "Uri Blumenthal said:
\n\n\nFirst, I have a big concern regarding truncating # of rounds and such, because today we don't know a better attack. Second, NIST officially stated that they will not standardize reduced-round Keccak - thus, TurboSHAKE will not be NIST-\"blessed\". Which, in turn, means that several vendors won't be able to offer it.
\n
The security margin on TurboSHAKE will still be much larger than the margin on most other hashes. I believe NIST did not say they will not standardise TurboSHAKE. Use in Kyber is a different question.
", "time": "2023-07-27T21:37:11Z"}, {"author": "Jonathan Hoyland", "text": "Is there some issue with the SEEMS LEGIT attacks? It looks like it could cause an issue here, but it's not obvious at first glance what
", "time": "2023-07-27T21:38:28Z"}, {"author": "Uri Blumenthal", "text": "\n\nI believe NIST did not say they will not standardise TurboSHAKE.
\n
Actually, they did - at one of the recent NIST workshops, within the last few months.
", "time": "2023-07-27T21:39:19Z"}, {"author": "Carl Wallace", "text": "DER reencoding may not wear well in practice
", "time": "2023-07-27T21:40:31Z"}, {"author": "Phillip Hallam-Baker", "text": "@Carl, I have never encountered any circumstance where canonicalization works for the purpose it was proposed.
", "time": "2023-07-27T21:41:23Z"}, {"author": "Ned Smith", "text": "+1 to @Farrell, Stephen point that there doesn't seem to be compelling use cases / industry need
", "time": "2023-07-27T21:41:37Z"}, {"author": "Phillip Hallam-Baker", "text": "DER was just a way to discourage use of ASN.1
", "time": "2023-07-27T21:41:45Z"}, {"author": "Daniel Gillmor", "text": "To restate what i said at the mic: protocols that state \"here is 1 cert\" in many cases have hidden assumptions about there being 1 cert.
\nif we sidestep those constraints with this mechanism, we haven't made the protocol more flexible; we've violated its hidden assumption.
", "time": "2023-07-27T21:42:04Z"}, {"author": "Uri Blumenthal", "text": "In some cases size of certs does not matter. In others, including my use cases - size of certs singlehandedly kills the likelihood of having connection established.
", "time": "2023-07-27T21:42:39Z"}, {"author": "Daniel Gillmor", "text": "If the protocol should be more flexible, that's a protocol-specific thing that needs to be addressed.
", "time": "2023-07-27T21:42:39Z"}, {"author": "Thom Wiggers", "text": "impressive sneezes
", "time": "2023-07-27T21:43:14Z"}, {"author": "Carl Wallace", "text": "@Phillip Hallam-Baker If DER discourages ASN.1, what do indefinite lengths do:-)
", "time": "2023-07-27T21:43:37Z"}, {"author": "Uri Blumenthal", "text": "There's Russian proverb: \"sneezing confirms the truth of what has been said\". :wink:
", "time": "2023-07-27T21:43:58Z"}, {"author": "Thom Wiggers", "text": "This proposal seems only useful if you have a certificate for TWO protocols, one of them wants to use the base certificate without changes and the second protocol computes and uses the delta certificate
", "time": "2023-07-27T21:44:29Z"}, {"author": "Thom Wiggers", "text": "I guess this last comment was roughly that
", "time": "2023-07-27T21:45:48Z"}, {"author": "David Benjamin", "text": "@Daniel Gillmor Ah whoops, guess I basically said what you just said here at the mic. Hadn't caught up on Zulip by the time I queued up. :-)
", "time": "2023-07-27T21:45:57Z"}, {"author": "Daniel Gillmor", "text": "@David Benjamin all good, you said it better than i did
", "time": "2023-07-27T21:47:59Z"}, {"author": "Yoav Nir", "text": "It's a rule that if you name your thing \"limited\" or \"lightweight\" or \"simple\", you end up with the new PKIX, with LDAP and SMTP.
", "time": "2023-07-27T21:49:58Z"}, {"author": "David Benjamin", "text": "Re the IDNA thing, the ASCII one already needs to address the IDNA problem, so using A-labels for the UTF-8 one doesn't add anything new. It just aligns things so we only need one codepath.
", "time": "2023-07-27T21:49:59Z"}]