Hi Kathleen & Co, I have now actually used ACME as well :)
Anyway, I see a slight disconnect between ACME and how Open Banking CAs work today. That is, open banking application developers typically create an account using a Web application provided by the bank (or external CA). From this account they can retrieve application IDs as well as getting certificates and private keys supplied as ZIP or P12 files. The latter is of course not ideal so the question is how this could be enhanced using ACME. I'm thinking about a process where you: - Locally create an account key-pair - Register the public key using the aforementioned Web application After that you have everything needed to perform automated certification requests using ACME or similar. This may look similar to what many commercial CAs already do but it is actually quite different; account keys are long-lived keys, distinct from the keys that the CA is supposed to certify. It obvious that these applications could benefit from attestations as well since security is highly dependent on the account keys. Since attestations would be a part of every certification request, it should be sufficient to provide the attestation certificate during registration. WDYT? Anders On 2021-11-04 21:50, Kathleen Moriarty wrote:
Hi Anders, On Tue, Oct 19, 2021 at 2:08 PM Anders Rundgren <[email protected] <mailto:[email protected]>> wrote: On 2021-10-19 19:00, Kathleen Moriarty wrote: > Hello Anders, > > The draft extends ACME to add client challenge methods that might be helpful. This could be for several use cases including code signing automation or client certificate management. Does the draft contain what you need? The use case from your message is not clear to me. Hello Kathleen, The client is not a person, it is a regulated entity like a payment processor. These entities need client certificates for calling banks. Currently CAs distribute encrypted private key + certificate chain for installation in servers. Both the initial part and possible updates could benefit from a more automated scheme which is why I find your draft interesting. OK, so the automation via already distributed credentials, and those pre-existing credentials may have been supported by a manual identity proofing process. The scheme could be further strengthened by (in some way...) locking cert requests to the entity's domain as well. Sure, for code signing certificates, there is a tie to the organization and the credentials may require a bigger process for issuance outside of ACME. For updates it would be cool if key container attestations also was a part of the plot because requests signed by the original key does not guarantee that the new key is in the same container. Newer HSMs support attestations. What are you proposing? Do you have text? I'm not clear on this part. Thank you, Kathleen Does that make sense? Thanx, Anders > > Thank you, > Kathleen > > > On Wed, Oct 13, 2021 at 8:42 AM Anders Rundgren <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: > > After some research I found https://datatracker.ietf.org/doc/draft-ietf-acme-client/ <https://datatracker.ietf.org/doc/draft-ietf-acme-client/> <https://datatracker.ietf.org/doc/draft-ietf-acme-client/ <https://datatracker.ietf.org/doc/draft-ietf-acme-client/>> which almost fills the bill. What would the preferred procedure be, including challenge? > > Attestations like offered by FIDO is not a part of ACME, right? > > thanx, > Anders > > On 2021-10-11 9:03, Anders Rundgren wrote: > > Dear ACME experts, > > > > I haven't kept track of ACME so please pardon my somewhat naive question: > > > > In Open Banking, service providers (TPPs) are equipped with TLS client certificates as well as signature certificates. Currently the certificates (including associated private keys), are distributed by the CA as encrypted files. This makes updates fairly difficult and not entirely compatible with the highly regulated nature of these providers. > > > > Question: does ACME support this scenario? > > > > thanx, > > Anders > > > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
