Re: [Acme] Client certificate draft

[Kathleen Moriarty <[e-mail]>]

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.

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