>Matt G1 <[email protected]> wrote: > > At the end of the work, however, other benefits came to light from my > > view. Primarily, the challenge-at-each-issuance fits more naturally > > into a zero trust design philosophy. The EST proof of identity (and the > > 3GPP CMPv2 based solution) issue a new certificate based on the fact > > you have (they key for) the previous one, and maybe some credentials > > issued at enrolment.
> What, in the cloud-native space, is the thing/identity that ACME allows you > to challenge for a client certificate? > I don't think it's an IP address (NAT44 all the way down in the kubernetes > space) or a DNS name. A good question - I viewed this sceptically at the time. And I still do. I did some checking and found that Kubernetes states that the K8s manager does cert management using a protocol "similar to ACME" which I inferred to mean using the message formats and skipping challenges. But that's just a conjecture on my part - I didn't dig down. Reference: https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/#:~:text=Kubernetes%20provides%20a%20certificates.k8s.io%20API%2C%20which%20lets%20you,protocol%20that%20is%20similar%20to%20the%20ACME%20draft. This chimes with something you mentioned in another message - people like ACME because they're familiar with it and its building blocks. Matt > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
