Re: [Anima] We want BRSKI and ACP!

Benjamin Kaduk <> Wed, 11 March 2020 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8DA33A00C1 for <>; Wed, 11 Mar 2020 12:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.362
X-Spam-Status: No, score=-3.362 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1F4sD2T31fKL for <>; Wed, 11 Mar 2020 12:06:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 808E03A00B0 for <>; Wed, 11 Mar 2020 12:06:40 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 02BJ6RtG012014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Mar 2020 15:06:29 -0400
Date: Wed, 11 Mar 2020 12:06:27 -0700
From: Benjamin Kaduk <>
To: Toerless Eckert <>
Cc: Michael Richardson <>, Brian E Carpenter <>, Warren Kumari <>, Anima WG <>,
Message-ID: <>
References: <> <6011.1583935076@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <>
Subject: Re: [Anima] We want BRSKI and ACP!
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Mar 2020 19:06:43 -0000

Hi Toerless,

On Wed, Mar 11, 2020 at 04:17:44PM +0100, Toerless Eckert wrote:
> Thanks, Michael
> Brian,
> At IETF106 i thought if Bens review would remove all discuss, we would have
> finished IESG review, but that is not the case because two of the
> IESG members that had approved ACP draft have since left office, so
> their votes do not count. I did report that at ANIMA WG @IETF106.
> At IETF106 we had both the ACP report from me of -21, as well as Ben's
> presentation on the main issue he saw, the encoding of the ACP
> domain information field in the certificate.
> While i had hoped that the in-person discuss about that issue would
> resolve that discuss because we did explain all the argments for it,
> his discuss of -21 on 12/30/2019 did i think not change his position,

I had also hoped that, though it did at least give me a better
understanding of the situation and the interplay amongst the various

> instead it also mentioned IPsec experts supporting that view, but
> without a technical explanation why, or who all those experts where.

I think it's more of a matter for PKIX experts (e.g., LAMPS WG) than IPsec,
since it relates to X.509 certificate contents.

I've asked Russ Housley to take a closer look and produce some comments,
and have a todo item to get another expert or two to opine.

> In January, i worked on -22 to answer to Bens review of -21. which i
> published 02/03/2020. For the encoding issue i rewrote the bullet
> points justifying the choice of encoding, primarily pointing to the
> fact that rfc822 names are nowadays quite common identifiers in a
> lot of e.g.: web systems, in addition to all the benefits of avoiding
> new or extensions to certificate parsing libraries and the like.
> Through IETF106 and writeup of -22 i even think more this
> is a pragmatic, prudent and logical choice, and i couldn't find
> anything in the cert related RFCs i read that seemed to contradict this for me.

I'll also mention again that there are procedures in place that can allow a
document to proceed even with a "holdout" Discuss position such as mine:
per the sponsoring AD
can request the "Single Discuss" procedure be used, or ask the chair to
invoke the "Alternate" ballot procedure.

> In February, Ben had told me, that -22 resolves his other points,
> except that that he continues on his position re. the encoding.
> But there was also security profile work improved in -22.

I'm very happy to see those improvements and the exchanges with the IPSECME
WG; thank you again for driving that!


> Shortly after IETF 106, Eric Vyncke took over as sponsoring AD for
> ACP. He provided a review with 72 comments in january to the authors.
> After i finished -22, i worked on these 72 points through february and posted
> -23/24 last week.
> In addition, during february, i also started to reach out to IPsec
> mailing list to further discuss details of the proposed enhancements
> to the IPsec profile. I ran out of time last week, and plan to
> finalize those fixes quickly (together with the WG fix sugestions i
> received for -24).
> In addition, i will also reach out directly to the IPsec experts
> i know and ask for the rfc822name encoding. I did that already
> last year, but never received replies.
> Eric told me, he wants to put ACP back onto the IESG agenda for April,
> and this would result in a new IETF review.
> Thats all i know.
> Cheers 
>     Toerless
> On Wed, Mar 11, 2020 at 09:57:56AM -0400, Michael Richardson wrote:
> > 
> > Brian E Carpenter <> wrote:
> >     > Could those on the hook for the ACP and BRSKI drafts, which have been
> >     > very seriously delayed, update the WG with the plan for getting them
> >     > approved? It seems to me that there has been endless nitpicking, of the
> >     > kind that is appropriate for full Standard status, but very surprising
> >     > for Proposed Standard where there is no expectation of perfection.
> > 
> > I don't know what kind of plan I can relate: It seems to be above my pay grade.
> > 
> > For BRSKI, since IETF106, all DISCUSSes, except Ben Kaduk's desire to have
> > the examples redone have been cleared.  I had originally tagged redoing that
> > for AUTH48 time, since all IANA allocations would be done by then.
> > All allocations have been done at this point, and in January I redid the
> > examples in the non-normative Appendix with the right OIDs.  Ben found some
> > errors (one repeated certificate), and so I generated the examples again.
> > 
> > I then asked Jim Schaad and Max Pritikin (a BRSKI co-author, who has been
> > redirected on other important Cisco work), to validate.  Max reviewed, and
> > this resulted in an additional clarifiying sentence committed to the github.
> > (I thought I posted it on Monday, I don't seem to have. I will do that now.
> > 
> > Warren Kumari has taken over as the sponsoring AD.
> > 
> >     > Can we expect these drafts to be approved in the next one or two weeks,
> >     > for example? If not then, when?
> > 
> > I know that ACP has gone through a similar set of DISCUSSes, and I think that
> > they are mostly all done.
> > I don't see an update from Ben.
> > 
> >
> > says that most have No Objections, rather than Yes. Three YES are needed to
> > override a DISCUSS.
> > I guess this document has been in front of the IESG since 2018 when Terry was
> > an AD!
> > 
> > I think that the WG participants need to actively engage the DISCUSSes and
> > the choices that the WG has made.
> > 
> > --
> > Michael Richardson <>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> > 
> > 
> > 
> > _______________________________________________
> > Anima mailing list
> >
> >
> -- 
> ---