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
