Sent from my mobile device > On Oct 5, 2025, at 1:41 PM, Michael Richardson <[email protected]> wrote: > > > I went back to look at the adoption call and discussion for > draft-ietf-acme-client. > TL;DR> please share this email with your Code Signing CA operational people. > > Kathleen presented at IETF105, and 106 (yes, before pandemic!). > If you look back, you'll find some problems with the proceedings and > recordings from that era, and I've opened a ticket with support@ietf about > this. > The adoption call proceeded in Nov. 2019 without objections (but also without > any review or commitment to review or implement). > > I found the recording for IETF105 (Montreal) at: > https://www.youtube.com/watch?v=bpgaDzhJUpE&t=951s > https://get.ietf.org/archive/jabber/logs/acme/2019-07-22.html > > (I prefer to DT links, since that would link in the chat, and one can then > read the chat at the same time as the video) > Notes mentioned "4-implementers", and I tried to identify those 4, and came > up with three only, and one said he wasn't an implementer (and has changed > jobs), but just cared about it. Two others have not answered my email query. > > The #1 use case people talked about seems to be code signing certificates. > This is not exactly client certificate: it won't be used for mTLS. > Maybe the real mistake is confounding the two. > > It was mentioned that one wants *two* administrators to authenticate. > I also think that the person possessing control over the key (whether 2U HSM > or USB dongle) is often *not* the person who would be doing the > organizational authorization. > This is important operationally if renewal requires 2-3 parties to coordinate. > > I asked about how Code Signers are authenticated/authorized. > CABFORUM criteria has evolved since 2019, thanks to SunBurst (SolarWinds) > attack. We have draft-ietf-lamps-csr-attestation as part of the solution. > But, that's about private key location, not the question as to whether the > entity asking for a code signing key really represents authority for that org. > > I've been told that in order to get a Code Signing certificate that current > CAs > will do some research into the company asking, and then will schedule a > (video) call in which they attempt to authenticate the principals using > (government) photo ID against the person in the video, and determine if > that's really the CTO, CFO, CISO. It's unclear to me what their criteria > are, they clearly have them, but I was at the far end of a tell-a-friend. > While this process is expensive, maybe it's justified.
This is why there was a section on identity proofing, it’s very important in that process for signing certificate types. > I don't know if someone has an idea to replace it with something > cheaper/online. To be clear: I'm talking about *initial* creation of the > relationship. > It would be lovely to hear from other CAs about this. > > I am unclear what SubjectDN is put into code signing certificates. > The majority of code signing that deal with is signing git commits using > OpenPGP. > (And those keys are largely self-signed, alas) > > I would appreciate more feedback from public CA operators that do code > signing. It would also be good to see some real examples. I don't know if > those certificates show up publically... maybe they are in the CT logs? > > What we did hear at 105 and 106 is that renewing of a code signing key might > require two C* to authorize the mechanism. If that's an actual goal, then > in order to get *AND* behaviour from ACME, we need to have a number of > *identifiers*, not just challenge types. If we want something more complex, > like a k-of-n threshold, then that will require some interesting innovation. > > It could well be that TOTP is the right tool, and one can even imagine during > that initial video call, that a QR code could be presented in the call to be > scanned > into a phone. That means that the TOTP secret would be created and owned > by the *CA*, and not by the Enterprise. > Thanks for looking at this through an adjusted lens. WebAuthn single device mode is also appealing potentially. The blog had an initial idea on using timeframes, and the IETF draft left room for some interaction if required to reduce how cumbersome the process is and some of that may be necessary. Best regards, Kathleen > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > > > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] > <signature.asc> _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
