Re: [Acme] Client certificate draft

[Richard Barnes <[e-mail]>]

On Fri, Mar 29, 2019 at 7:49 AM Kathleen Moriarty <
[e-mail]> wrote:

> I meant to respond inline as well.
>
> Sent from my mobile device
>
> On Mar 28, 2019, at 4:58 PM, Richard Barnes <[e-mail]> 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 <[e-mail]>
> 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
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/acme
>> >
>>
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
>>
>