On Fri, Mar 29, 2019 at 4:31 AM Richard Barnes <[email protected]> wrote: > > > On Fri, Mar 29, 2019 at 9:30 AM Kathleen Moriarty < > [email protected]> wrote: > >> >> >> On Fri, Mar 29, 2019 at 4:27 AM Richard Barnes <[email protected]> wrote: >> >>> >>> >>> On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty < >>> [email protected]> wrote: >>> >>>> I meant to respond inline as well. >>>> >>>> Sent from my mobile device >>>> >>>> On Mar 28, 2019, at 4:58 PM, Richard Barnes <[email protected]> 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 < >>>> [email protected]> 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 >>>>> > [email protected] >>>>> > https://www.ietf.org/mailman/listinfo/acme >>>>> > >>>>> >>>>> _______________________________________________ >>>>> Acme mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/acme >>>>> >>>> >> >> -- >> >> Best regards, >> Kathleen >> > -- Best regards, Kathleen
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
