Re: [Acme] Client certificate draft
On Fri, Mar 29, 2019 at 4:31 AM Richard Barnes wrote: > > > On Fri, Mar 29, 2019 at 9:30 AM Kathleen Moriarty < > kathleen.moriarty.i...@gmail.com> wrote: > >> >> >> On Fri, Mar 29, 2019 at 4:27 AM Richard Barnes wrote: >> >>> >>> >>> On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty < >>> kathleen.moriarty.i...@gmail.com> wrote: >>> I meant to respond inline as well. Sent from my mobile device On Mar 28, 2019, at 4:58 PM, Richard Barnes wrote: To recap and extend some things that were said at the meeting: - ACME can already be used for client certificates that attest to domain names. It's just an EKU difference, so it can be negotiated in the CSR. - ACME can already be used for code-signing certs, with external validation. As with client certs, the relevant EKUs can be negotiated in the CSR. None of the empirical validation mechanisms are appropriate; the authority token work might be relevant. - FIDO does not define or issue certificates of any type. FIDO uses public key pairs, using different sets of credentials (key pairs) for each service. This is working well for authentication for many. I’ve heard a few people say they have different use cases and I’m trying to figure out if we want identity proofing or just ties to a system or to know the same person holds a few keys on different devices if we define something. >>> >>> C'est magnifique, mais ce n'est pas un certificat. >>> >>> You could make it a challenge, though. Cf. >>> https://tools.ietf.org/html/draft-ietf-acme-acme-00#section-7.3 >>> >> >> Sure, it's listed as an option in the draft for a challenge already if >> people were interested. >> > > It would be helpful if you could go ahead and post the draft. > It's been posted to the list. And I am trying, the secretariat has the xml and txt. The interface is spitting out odd errors for me with a different test draft rather than mine. Best, Kathleen > > >> >>> >>> --Richard >>> >>> Best regards, Kathleen On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson < hidinginthe...@gmail.com> wrote: > Thank you for your draft. > > As per the discussion from the WG meeting in Prague, my thoughts: > > Section 5, Device Certificates: > DNS/IP based challenges may be appropriate for on-premises hardware > and > less appropriate for Cloud or IoT environments where a machine > requesting may not have DNS or suitable IP address. For Cloud > deployments it may be more desirable to tie the challenge to the > platform's respective IAM service using > draft-ietf-acme-authority-token. > > In terms of actions, an informative document describing considerations > (such as ensuring "TLS Client Certificate Authentication" is set in > CSR, > like you describe) would probably be most appropriate in my view and I > would be happy to co-author or contribute to it if there was interest.. > > Section 6, End User Certificates: > I had considered the idea of using ACME for end user certificates (and > believe it's worth it, particulary in enterprise environments), as I > was > unaware of the possibility of FIDO being used. However CAs and > implementors may find using ACME better for consistency sake as they > may > already be doing existing issuance using it. > > Browser support I believe remains the biggest challenge for this and I > would like to hear the thoughts from browser vendors on list. > > Regards > > On 20/03/2019 14:59, Kathleen Moriarty wrote: > > Hello, > > > > I am attaching a draft on several client certificate types to > discuss in > > Prague. The draft intentionally leaves some open questions for > > discussion and I'll form the slides for the presentation in Prague > > around those questions. > > > > Thanks in advance for your review and discussion in Prague. > > > > Safe travels! > > > > -- > > > > Best regards, > > Kathleen > > > > ___ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > >> >> -- >> >> Best regards, >> Kathleen >> > -- Best regards, Kathleen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Client certificate draft
On Fri, Mar 29, 2019 at 9:30 AM Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > > > On Fri, Mar 29, 2019 at 4:27 AM Richard Barnes wrote: > >> >> >> On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty < >> kathleen.moriarty.i...@gmail.com> wrote: >> >>> I meant to respond inline as well. >>> >>> Sent from my mobile device >>> >>> On Mar 28, 2019, at 4:58 PM, Richard Barnes wrote: >>> >>> To recap and extend some things that were said at the meeting: >>> >>> - ACME can already be used for client certificates that attest to domain >>> names. It's just an EKU difference, so it can be negotiated in the CSR.. >>> >>> - ACME can already be used for code-signing certs, with external >>> validation. As with client certs, the relevant EKUs can be negotiated in >>> the CSR. None of the empirical validation mechanisms are appropriate; the >>> authority token work might be relevant. >>> >>> - FIDO does not define or issue certificates of any type. >>> >>> >>> FIDO uses public key pairs, using different sets of credentials (key >>> pairs) for each service. This is working well for authentication for >>> many. I’ve heard a few people say they have different use cases and I’m >>> trying to figure out if we want identity proofing or just ties to a system >>> or to know the same person holds a few keys on different devices if we >>> define something. >>> >> >> C'est magnifique, mais ce n'est pas un certificat. >> >> You could make it a challenge, though. Cf. >> https://tools.ietf.org/html/draft-ietf-acme-acme-00#section-7.3 >> > > Sure, it's listed as an option in the draft for a challenge already if > people were interested. > It would be helpful if you could go ahead and post the draft. > >> >> --Richard >> >> >>> >>> Best regards, >>> Kathleen >>> >>> >>> >>> On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson < >>> hidinginthe...@gmail.com> wrote: >>> Thank you for your draft. As per the discussion from the WG meeting in Prague, my thoughts: Section 5, Device Certificates: DNS/IP based challenges may be appropriate for on-premises hardware and less appropriate for Cloud or IoT environments where a machine requesting may not have DNS or suitable IP address. For Cloud deployments it may be more desirable to tie the challenge to the platform's respective IAM service using draft-ietf-acme-authority-token. In terms of actions, an informative document describing considerations (such as ensuring "TLS Client Certificate Authentication" is set in CSR, like you describe) would probably be most appropriate in my view and I would be happy to co-author or contribute to it if there was interest. Section 6, End User Certificates: I had considered the idea of using ACME for end user certificates (and believe it's worth it, particulary in enterprise environments), as I was unaware of the possibility of FIDO being used. However CAs and implementors may find using ACME better for consistency sake as they may already be doing existing issuance using it. Browser support I believe remains the biggest challenge for this and I would like to hear the thoughts from browser vendors on list. Regards On 20/03/2019 14:59, Kathleen Moriarty wrote: > Hello, > > I am attaching a draft on several client certificate types to discuss in > Prague. The draft intentionally leaves some open questions for > discussion and I'll form the slides for the presentation in Prague > around those questions. > > Thanks in advance for your review and discussion in Prague. > > Safe travels! > > -- > > Best regards, > Kathleen > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme >>> > > -- > > Best regards, > Kathleen > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Client certificate draft
On Fri, Mar 29, 2019 at 4:27 AM Richard Barnes wrote: > > > On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty < > kathleen.moriarty.i...@gmail.com> wrote: > >> I meant to respond inline as well. >> >> Sent from my mobile device >> >> On Mar 28, 2019, at 4:58 PM, Richard Barnes wrote: >> >> To recap and extend some things that were said at the meeting: >> >> - ACME can already be used for client certificates that attest to domain >> names. It's just an EKU difference, so it can be negotiated in the CSR. >> >> - ACME can already be used for code-signing certs, with external >> validation. As with client certs, the relevant EKUs can be negotiated in >> the CSR. None of the empirical validation mechanisms are appropriate; the >> authority token work might be relevant. >> >> - FIDO does not define or issue certificates of any type. >> >> >> FIDO uses public key pairs, using different sets of credentials (key >> pairs) for each service. This is working well for authentication for >> many. I’ve heard a few people say they have different use cases and I’m >> trying to figure out if we want identity proofing or just ties to a system >> or to know the same person holds a few keys on different devices if we >> define something. >> > > C'est magnifique, mais ce n'est pas un certificat. > > You could make it a challenge, though. Cf. > https://tools.ietf.org/html/draft-ietf-acme-acme-00#section-7.3 > Sure, it's listed as an option in the draft for a challenge already if people were interested. > > > --Richard > > >> >> Best regards, >> Kathleen >> >> >> >> On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson >> wrote: >> >>> Thank you for your draft. >>> >>> As per the discussion from the WG meeting in Prague, my thoughts: >>> >>> Section 5, Device Certificates: >>> DNS/IP based challenges may be appropriate for on-premises hardware and >>> less appropriate for Cloud or IoT environments where a machine >>> requesting may not have DNS or suitable IP address. For Cloud >>> deployments it may be more desirable to tie the challenge to the >>> platform's respective IAM service using draft-ietf-acme-authority-token.. >>> >>> In terms of actions, an informative document describing considerations >>> (such as ensuring "TLS Client Certificate Authentication" is set in CSR, >>> like you describe) would probably be most appropriate in my view and I >>> would be happy to co-author or contribute to it if there was interest. >>> >>> Section 6, End User Certificates: >>> I had considered the idea of using ACME for end user certificates (and >>> believe it's worth it, particulary in enterprise environments), as I was >>> unaware of the possibility of FIDO being used. However CAs and >>> implementors may find using ACME better for consistency sake as they may >>> already be doing existing issuance using it. >>> >>> Browser support I believe remains the biggest challenge for this and I >>> would like to hear the thoughts from browser vendors on list. >>> >>> Regards >>> >>> On 20/03/2019 14:59, Kathleen Moriarty wrote: >>> > Hello, >>> > >>> > I am attaching a draft on several client certificate types to discuss >>> in >>> > Prague. The draft intentionally leaves some open questions for >>> > discussion and I'll form the slides for the presentation in Prague >>> > around those questions. >>> > >>> > Thanks in advance for your review and discussion in Prague. >>> > >>> > Safe travels! >>> > >>> > -- >>> > >>> > Best regards, >>> > Kathleen >>> > >>> > ___ >>> > Acme mailing list >>> > Acme@ietf.org >>> > https://www.ietf.org/mailman/listinfo/acme >>> > >>> >>> ___ >>> Acme mailing list >>> Acme@ietf.org >>> https://www.ietf.org/mailman/listinfo/acme >>> >> -- Best regards, Kathleen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Client certificate draft
On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty < kathleen.moriarty.i...@gmail.com> wrote: > I meant to respond inline as well. > > Sent from my mobile device > > On Mar 28, 2019, at 4:58 PM, Richard Barnes wrote: > > To recap and extend some things that were said at the meeting: > > - ACME can already be used for client certificates that attest to domain > names. It's just an EKU difference, so it can be negotiated in the CSR. > > - ACME can already be used for code-signing certs, with external > validation. As with client certs, the relevant EKUs can be negotiated in > the CSR. None of the empirical validation mechanisms are appropriate; the > authority token work might be relevant. > > - FIDO does not define or issue certificates of any type. > > > FIDO uses public key pairs, using different sets of credentials (key > pairs) for each service. This is working well for authentication for > many. I’ve heard a few people say they have different use cases and I’m > trying to figure out if we want identity proofing or just ties to a system > or to know the same person holds a few keys on different devices if we > define something. > C'est magnifique, mais ce n'est pas un certificat. You could make it a challenge, though. Cf. https://tools.ietf.org/html/draft-ietf-acme-acme-00#section-7.3 --Richard > > Best regards, > Kathleen > > > > On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson > wrote: > >> Thank you for your draft. >> >> As per the discussion from the WG meeting in Prague, my thoughts: >> >> Section 5, Device Certificates: >> DNS/IP based challenges may be appropriate for on-premises hardware and >> less appropriate for Cloud or IoT environments where a machine >> requesting may not have DNS or suitable IP address. For Cloud >> deployments it may be more desirable to tie the challenge to the >> platform's respective IAM service using draft-ietf-acme-authority-token. >> >> In terms of actions, an informative document describing considerations >> (such as ensuring "TLS Client Certificate Authentication" is set in CSR, >> like you describe) would probably be most appropriate in my view and I >> would be happy to co-author or contribute to it if there was interest. >> >> Section 6, End User Certificates: >> I had considered the idea of using ACME for end user certificates (and >> believe it's worth it, particulary in enterprise environments), as I was >> unaware of the possibility of FIDO being used. However CAs and >> implementors may find using ACME better for consistency sake as they may >> already be doing existing issuance using it. >> >> Browser support I believe remains the biggest challenge for this and I >> would like to hear the thoughts from browser vendors on list. >> >> Regards >> >> On 20/03/2019 14:59, Kathleen Moriarty wrote: >> > Hello, >> > >> > I am attaching a draft on several client certificate types to discuss >> in >> > Prague. The draft intentionally leaves some open questions for >> > discussion and I'll form the slides for the presentation in Prague >> > around those questions. >> > >> > Thanks in advance for your review and discussion in Prague. >> > >> > Safe travels! >> > >> > -- >> > >> > Best regards, >> > Kathleen >> > >> > ___ >> > Acme mailing list >> > Acme@ietf.org >> > https://www.ietf.org/mailman/listinfo/acme >> > >> >> ___ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Client certificate draft
I meant to respond inline as well. Sent from my mobile device > On Mar 28, 2019, at 4:58 PM, Richard Barnes wrote: > > To recap and extend some things that were said at the meeting: > > - ACME can already be used for client certificates that attest to domain > names. It's just an EKU difference, so it can be negotiated in the CSR. > > - ACME can already be used for code-signing certs, with external validation. > As with client certs, the relevant EKUs can be negotiated in the CSR. None > of the empirical validation mechanisms are appropriate; the authority token > work might be relevant. > > - FIDO does not define or issue certificates of any type. FIDO uses public key pairs, using different sets of credentials (key pairs) for each service. This is working well for authentication for many. I’ve heard a few people say they have different use cases and I’m trying to figure out if we want identity proofing or just ties to a system or to know the same person holds a few keys on different devices if we define something. Best regards, Kathleen > > >> On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson >> wrote: >> Thank you for your draft. >> >> As per the discussion from the WG meeting in Prague, my thoughts: >> >> Section 5, Device Certificates: >> DNS/IP based challenges may be appropriate for on-premises hardware and >> less appropriate for Cloud or IoT environments where a machine >> requesting may not have DNS or suitable IP address. For Cloud >> deployments it may be more desirable to tie the challenge to the >> platform's respective IAM service using draft-ietf-acme-authority-token. >> >> In terms of actions, an informative document describing considerations >> (such as ensuring "TLS Client Certificate Authentication" is set in CSR, >> like you describe) would probably be most appropriate in my view and I >> would be happy to co-author or contribute to it if there was interest. >> >> Section 6, End User Certificates: >> I had considered the idea of using ACME for end user certificates (and >> believe it's worth it, particulary in enterprise environments), as I was >> unaware of the possibility of FIDO being used. However CAs and >> implementors may find using ACME better for consistency sake as they may >> already be doing existing issuance using it. >> >> Browser support I believe remains the biggest challenge for this and I >> would like to hear the thoughts from browser vendors on list. >> >> Regards >> >> On 20/03/2019 14:59, Kathleen Moriarty wrote: >> > Hello, >> > >> > I am attaching a draft on several client certificate types to discuss in >> > Prague. The draft intentionally leaves some open questions for >> > discussion and I'll form the slides for the presentation in Prague >> > around those questions. >> > >> > Thanks in advance for your review and discussion in Prague. >> > >> > Safe travels! >> > >> > -- >> > >> > Best regards, >> > Kathleen >> > >> > ___ >> > Acme mailing list >> > Acme@ietf.org >> > https://www.ietf.org/mailman/listinfo/acme >> > >> >> ___ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Client certificate draft
I was thinking OTP may be a possibility for a CodeSigning challenge (after account establishment out of band) and I have received outreach from others interested to develop solutions for each of the types. Client certs for messaging and enterprise was mentioned by others as well. Feedback and contributions appreciated. Thank you, Kathleen Sent from my mobile device > On Mar 28, 2019, at 4:58 PM, Richard Barnes wrote: > > To recap and extend some things that were said at the meeting: > > - ACME can already be used for client certificates that attest to domain > names. It's just an EKU difference, so it can be negotiated in the CSR. > > - ACME can already be used for code-signing certs, with external validation. > As with client certs, the relevant EKUs can be negotiated in the CSR. None > of the empirical validation mechanisms are appropriate; the authority token > work might be relevant. > > - FIDO does not define or issue certificates of any type. > > >> On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson >> wrote: >> Thank you for your draft. >> >> As per the discussion from the WG meeting in Prague, my thoughts: >> >> Section 5, Device Certificates: >> DNS/IP based challenges may be appropriate for on-premises hardware and >> less appropriate for Cloud or IoT environments where a machine >> requesting may not have DNS or suitable IP address. For Cloud >> deployments it may be more desirable to tie the challenge to the >> platform's respective IAM service using draft-ietf-acme-authority-token. >> >> In terms of actions, an informative document describing considerations >> (such as ensuring "TLS Client Certificate Authentication" is set in CSR, >> like you describe) would probably be most appropriate in my view and I >> would be happy to co-author or contribute to it if there was interest. >> >> Section 6, End User Certificates: >> I had considered the idea of using ACME for end user certificates (and >> believe it's worth it, particulary in enterprise environments), as I was >> unaware of the possibility of FIDO being used. However CAs and >> implementors may find using ACME better for consistency sake as they may >> already be doing existing issuance using it. >> >> Browser support I believe remains the biggest challenge for this and I >> would like to hear the thoughts from browser vendors on list. >> >> Regards >> >> On 20/03/2019 14:59, Kathleen Moriarty wrote: >> > Hello, >> > >> > I am attaching a draft on several client certificate types to discuss in >> > Prague. The draft intentionally leaves some open questions for >> > discussion and I'll form the slides for the presentation in Prague >> > around those questions. >> > >> > Thanks in advance for your review and discussion in Prague. >> > >> > Safe travels! >> > >> > -- >> > >> > Best regards, >> > Kathleen >> > >> > ___ >> > Acme mailing list >> > Acme@ietf.org >> > https://www.ietf.org/mailman/listinfo/acme >> > >> >> ___ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Client certificate draft
To recap and extend some things that were said at the meeting: - ACME can already be used for client certificates that attest to domain names. It's just an EKU difference, so it can be negotiated in the CSR. - ACME can already be used for code-signing certs, with external validation. As with client certs, the relevant EKUs can be negotiated in the CSR. None of the empirical validation mechanisms are appropriate; the authority token work might be relevant. - FIDO does not define or issue certificates of any type. On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson wrote: > Thank you for your draft. > > As per the discussion from the WG meeting in Prague, my thoughts: > > Section 5, Device Certificates: > DNS/IP based challenges may be appropriate for on-premises hardware and > less appropriate for Cloud or IoT environments where a machine > requesting may not have DNS or suitable IP address. For Cloud > deployments it may be more desirable to tie the challenge to the > platform's respective IAM service using draft-ietf-acme-authority-token. > > In terms of actions, an informative document describing considerations > (such as ensuring "TLS Client Certificate Authentication" is set in CSR, > like you describe) would probably be most appropriate in my view and I > would be happy to co-author or contribute to it if there was interest. > > Section 6, End User Certificates: > I had considered the idea of using ACME for end user certificates (and > believe it's worth it, particulary in enterprise environments), as I was > unaware of the possibility of FIDO being used. However CAs and > implementors may find using ACME better for consistency sake as they may > already be doing existing issuance using it. > > Browser support I believe remains the biggest challenge for this and I > would like to hear the thoughts from browser vendors on list. > > Regards > > On 20/03/2019 14:59, Kathleen Moriarty wrote: > > Hello, > > > > I am attaching a draft on several client certificate types to discuss in > > Prague. The draft intentionally leaves some open questions for > > discussion and I'll form the slides for the presentation in Prague > > around those questions. > > > > Thanks in advance for your review and discussion in Prague. > > > > Safe travels! > > > > -- > > > > Best regards, > > Kathleen > > > > ___ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > ___ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
Re: [Acme] Client certificate draft
Thank you for your draft. As per the discussion from the WG meeting in Prague, my thoughts: Section 5, Device Certificates: DNS/IP based challenges may be appropriate for on-premises hardware and less appropriate for Cloud or IoT environments where a machine requesting may not have DNS or suitable IP address. For Cloud deployments it may be more desirable to tie the challenge to the platform's respective IAM service using draft-ietf-acme-authority-token. In terms of actions, an informative document describing considerations (such as ensuring "TLS Client Certificate Authentication" is set in CSR, like you describe) would probably be most appropriate in my view and I would be happy to co-author or contribute to it if there was interest. Section 6, End User Certificates: I had considered the idea of using ACME for end user certificates (and believe it's worth it, particulary in enterprise environments), as I was unaware of the possibility of FIDO being used. However CAs and implementors may find using ACME better for consistency sake as they may already be doing existing issuance using it. Browser support I believe remains the biggest challenge for this and I would like to hear the thoughts from browser vendors on list. Regards On 20/03/2019 14:59, Kathleen Moriarty wrote: Hello, I am attaching a draft on several client certificate types to discuss in Prague. The draft intentionally leaves some open questions for discussion and I'll form the slides for the presentation in Prague around those questions. Thanks in advance for your review and discussion in Prague. Safe travels! -- Best regards, Kathleen ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
[Acme] Client certificate draft
Hello, I am attaching a draft on several client certificate types to discuss in Prague. The draft intentionally leaves some open questions for discussion and I'll form the slides for the presentation in Prague around those questions. Thanks in advance for your review and discussion in Prague. Safe travels! -- Best regards, Kathleen IETF K. Moriarty Internet-Draft Dell EMC Intended status: Standards Track March 18, 2019 Expires: September 19, 2019 ACME Client Extension Abstract Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support end user client, device client, and code signing certificates. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 19, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Moriarty Expires September 19, 2019 [Page 1] Internet-Draft ACMEClient March 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Identity Proofing for Client Certificates . . . . . . . . . . 2 3. Key Storage . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Why Not EST . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Device Certificates . . . . . . . . . . . . . . . . . . . . . 5 6. End USer Client Certificates . . . . . . . . . . . . . . . . 6 7. CodeSigning Certificates . . . . . . . . . . . . . . . . . . 7 8. Pre-authorization . . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.2. Informative References . . . . . . . . . . . . . . . . . 10 12.3. URL References . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction ACME [RFC8555] is a mechanism for automating certificate management on the Internet. It enables administrative entities to prove effective control over resources like domain names, and automates the process of generating and issuing certificates. ACME was designed for web server certificates with the possibility to create extensions for other use cases and certificate types. End user and device certificates may also benefit from automated management to ease the deployment and maintenance of these certificates type, thus the definition of the extension for that purpose in this document. 2. Identity Proofing for Client Certificates As with the TLS certificates defined in the core ACME document, identity proofing for ACME issued end user client, device client, and code signing certificates was not covered in RFC8555. Identity proofing for these certificate types present some challenges for process automation. NIST SP 800-63 r3 [NIST800-63r3] serves as guidance for identity proofing further detailed in NIST SP 800-63A [NIST800-63A] that may occur prior to the ability to automate certificate
