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 <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. > 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
