Subject: [Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 2 Jul 2019 19:04:35 +0000

All,

This early draft https://datatracker.ietf.org/doc/draft-friel-acme-integrations/ covers how BRSKI could potentially be integrated with an ACME CA for cert issuance.

What is the WG initial feedback on this idea? I have requested 10mins at IETF105 to present/discuss.

Related work is https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/, which covers how ACME could be used to issue device certs, but does not use BRSKI. We are currently discussing offline with Rifaat how we could potentially integrate both approaches. 

Owen

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: 02 July 2019 19:50
To: Richard Barnes <[email-masked]>; Owen Friel (ofriel) <[email-masked]>
Subject: New Version Notification for draft-friel-acme-integrations-01.txt

A new version of I-D, draft-friel-acme-integrations-01.txt
has been successfully submitted by Owen Friel and posted to the IETF repository.

Name:		draft-friel-acme-integrations
Revision:	01
Title:		ACME Integrations
Document date:	2019-07-02
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-friel-acme-integrations-01.txt
Status:         https://datatracker.ietf.org/doc/draft-friel-acme-integrations/
Htmlized:       https://tools.ietf.org/html/draft-friel-acme-integrations-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-friel-acme-integrations
Diff:           https://www.ietf.org/rfcdiff?url2=draft-friel-acme-integrations-01

Abstract:
   This document outlines multiple advanced use cases and integrations
   that ACME facilitates without any modifications or enhancements
   required to the base ACME specification.  These use cases are not
   immediately obvious from reading the ACME specification and thus are
   explicitly documented here.  The use cases include ACME issuance of
   subdomain certificates, and ACME integration with EST and TEAP.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Jul 2019 18:28:22 -0400

Owen Friel (ofriel) <[email-masked]> wrote:
    > This early draft
    > https://datatracker.ietf.org/doc/draft-friel-acme-integrations/ covers
    > how BRSKI could potentially be integrated with an ACME CA for cert
    > issuance.

I read it.
While it is certainly true that a BRSKI RA can use ACME to speak to a CA, I'm
not actually sure what it means from a standards point of view.

My code base does not connect the RA to LetsEncrypt, but rather uses
LetsEncrypt to produce IDevIDs from a provisioning process.

I think that you have a problem in STEP 2 (section 3),
and STEP 3 (section 4), STEP 3 (section 5).

In each place where you post a CSR, you omit the part where you get the
CSRattributes.  At some point the pledge needs to learn about what the
delegated domain is ("domain.com").

In section 4, the figures (which need to be numbered, btw), is labelled a
Pledge, but since there is no BRSKI, it should "Client"

    > Related work is
    > https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/,
    > which covers how ACME could be used to issue device certs, but does not
    > use BRSKI. We are currently discussing offline with Rifaat how we could
    > potentially integrate both approaches.

I'll read this.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Fri, 5 Jul 2019 10:09:51 +0000

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of Michael Richardson
Sent: 03 July 2019 23:28
To: [email-masked]; Owen Friel (ofriel) <[email-masked]>
Cc: Rifaat Shekh-Yusef <[email-masked]>
Subject: Re: [Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt

    > how BRSKI could potentially be integrated with an ACME CA for cert

I read it.
While it is certainly true that a BRSKI RA can use ACME to speak to a CA, I'm not actually sure what it means from a standards point of view.
[ofriel] Yes, this could maybe be Informational rather than std track. As currently written, there are no changes required to BRSKI, EST or ACME drafts, so it really is informational on how to stitch these things together. One of the interesting things is possisble use of ACME for subdomain certs, which the flows for EST, BRSKI and TEAP illustrate, as this is a nice signalling optimisation for scaling to large number of clients.

My code base does not connect the RA to LetsEncrypt, but rather uses LetsEncrypt to produce IDevIDs from a provisioning process.

I think that you have a problem in STEP 2 (section 3), and STEP 3 (section 4), STEP 3 (section 5).

In each place where you post a CSR, you omit the part where you get the CSRattributes.  At some point the pledge needs to learn about what the delegated domain is ("domain.com").
[ofriel] Sure, it doesn't include all the BRSKI bits. Its also left as a todo exactly how the client should determine its domain for inclusion in the CSR if it only has its IDevID to start with.

In section 4, the figures (which need to be numbered, btw), is labelled a Pledge, but since there is no BRSKI, it should "Client"
[ofriel] For sure, loads of minor nits in -01.

I'll read this.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-