Re: [Acme] Client certificate draft

[Richard Barnes <[e-mail]>]

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

>
>
> On Fri, Mar 29, 2019 at 4:27 AM Richard Barnes <[e-mail]> wrote:
>
>>
>>
>> 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
>>
>
> 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 <
>>> [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
>>>>
>>>
>
> --
>
> Best regards,
> Kathleen
>