IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 03 July 2019 22:28 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB591206A0 for <anima@ietfa.amsl.com>; Wed, 3 Jul 2019 15:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be5xFQA7M4dp for <anima@ietfa.amsl.com>; Wed, 3 Jul 2019 15:28:25 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1971204C2 for <anima@ietf.org>; Wed, 3 Jul 2019 15:28:24 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 83DE738192; Wed, 3 Jul 2019 18:26:29 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AA601BB7; Wed, 3 Jul 2019 18:28:22 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "anima@ietf.org" <anima@ietf.org>, "Owen Friel (ofriel)" <ofriel@cisco.com>
cc: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
In-Reply-To: <DM6PR11MB3385A59B984127385DE49720DBF80@DM6PR11MB3385.namprd11.prod.outlook.com>
References: <156209339375.23780.16389385862360970000.idtracker@ietfa.amsl.com> <DM6PR11MB3385A59B984127385DE49720DBF80@DM6PR11MB3385.namprd11.prod.outlook.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 03 Jul 2019 18:28:22 -0400
Message-ID: <7216.1562192902@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/VJGD_kVNsbIyt78I0S9XfHUxH8c>
Subject: Re: [Anima] FW: New Version Notification for draft-friel-acme-integrations-01.txt
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 22:28:34 -0000

Owen Friel (ofriel) <ofriel@cisco.com> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email