On Fri, Mar 29, 2019 at 4:27 AM Richard Barnes <r...@ipv.sx> 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 <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 >
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 <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
