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. 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. -- ] 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
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
