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 <r...@ipv.sx> 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 <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 >> >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
