Subject: [Acme] Client certificate draft

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 20 Mar 2019 10:59:02 -0400

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

---

From: Thomas Peterson <[email-masked]>
Date: Thu, 28 Mar 2019 14:25:15 +0000

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:
> Prague.  The draft intentionally leaves some open questions for 
> discussion and I'll form the slides for the presentation in Prague 
> around those questions.
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Mar 2019 16:58:55 +0100

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 28 Mar 2019 23:30:08 +0100

I was thinking OTP may be a possibility for a CodeSigning challenge (after account establishment out of band) and I have received outreach from others interested to develop solutions for each of the types. Client certs for messaging and enterprise was mentioned by others as well.

Feedback and contributions appreciated.

Thank you,
Kathleen 

Sent from my mobile device

> On Mar 28, 2019, at 4:58 PM, Richard Barnes <[email-masked]> wrote:
> 
> - 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.
> 
>> On Thu, Mar 28, 2019 at 3:25 PM Thomas Peterson <[email-masked]> wrote:

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 29 Mar 2019 07:49:57 +0100

I meant to respond inline as well.

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

Best regards,
Kathleen

---

From: Richard Barnes <[email-masked]>
Date: Fri, 29 Mar 2019 09:27:01 +0100

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

> 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

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 29 Mar 2019 04:29:30 -0400

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

-- 

Best regards,
Kathleen

---

From: Richard Barnes <[email-masked]>
Date: Fri, 29 Mar 2019 09:30:46 +0100

> Sure, it's listed as an option in the draft for a challenge already if

It would be helpful if you could go ahead and post the draft.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 29 Mar 2019 04:42:31 -0400

On Fri, Mar 29, 2019 at 4:31 AM Richard Barnes <[email-masked]> wrote:

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

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

-- 

Best regards,
Kathleen