Subject: [Anima] We want BRSKI and ACP!

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Mar 2020 13:34:34 +1300

Hi,

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.

Can we expect these drafts to be approved in the next one or two weeks, for example? If not then, when?

Regards
   Brian Carpenter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Mar 2020 09:57:56 -0400

Brian E Carpenter <[email-masked]> 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.

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

https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ballot/
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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 11 Mar 2020 16:17:44 +0100

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,
instead it also mentioned IPsec experts supporting that view, but
without a technical explanation why, or who all those experts where.

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.

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.

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

> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Mar 2020 12:05:53 -0400

[ + Benjamin ]

On Wed, Mar 11, 2020 at 9:58 AM Michael Richardson
<[email-masked]> wrote:
> the examples redone have been cleared.

Yes, Alissa cleared on 2020-01-24.
Ben checked, and updated his DISCUSS on 2020-01-03, asking for the
examples to be updated. He then updated again on 2020-02-24 pointing
out errors.

> I had originally tagged redoing that

I would not classify Ben's DISCUSS as "endless nitpicking" - he
reviewed the changes, and updated on 2020-02-24 - here is the current
ballot:
"Thanks for the updated examples using the allocated MASA URL extension OID!

Unfortunately, I think there are still some inconsistencies in the
examples to resolve:

The MASA cert/key is identical to the "manufacturer key pair for IDevID
signatures" (C.1.1 and C.1.2).  (It shows the MASA Subject CN, so maybe
just the included file was typo'd?)  The example IDevID cert shows an
issuer name that doesn't match the cert given.
(Also the MASA cert doesn't have a randomized serial number but the
registrar one does.)

The registrar-to-MASA voucher request in C.2.2 seems to have a CMS
SignedData with the SignerIdentifier identifying the "Unstrung Fountain
Root" (i.e,. the root CA used for these examples) instead of the
expected "fountain-test.example.com".  Am I misreading the ASN.1 dump?
(We do seem to send both certificates.)

The voucher response from MASA to Registrar seems to be signed by the
"highway-test.example.com CA" (which would be the "manufacturer key pair
for IDevID signatures" that we don't have in the -35 since the MASA
certificate is repeated), not the MASA's cert from C.1.1."

The authors quickly updated the document and posted a new version on
2020-02-26 ( ~2 weeks ago). As you can guess, the past few weeks have
been busy - as well as discussions around cancelling (or not) IETF
107, there has been a big push to clear outgoing ADs documents, so
that there is a clean handoff to the incoming ADs.

I'm expecting Benjamin (who I have CCed) to review the changes again soon.

> Warren Kumari has taken over as the sponsoring AD.

Indeed -- I took over from Ignas on 2020-01-27 (~ 1.5 months ago) --
since then, Alissa has cleared her DISCUSS, and the authors have
published 2 new versions (it is now at -37).
Ben had asked for some updates, and these have been folded in, and the
new issues should be reviewed soon.

Since IETF 106, there have been 6 new revisions of the document,
Benjamin has reviewed and updated his DISCUSS 3 times, Alissa has
cleared her DISCUSS (Roman cleared just before the meeting), and I see
~36 emails on the draft (some off-topic, and a number of off-list
pokings, etc).

So, yes, I understand that this is really frustrating, and I fully
agree that there have been many many delays that should not have
occurred - but, I think that there is now significant progress
happening...

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Mar 2020 13:38:21 -0400

Toerless Eckert <[email-masked]> wrote:
    > 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).

I helped Toerless, although I disagree with some of his points.

The IPsec WG seems to disagree with me (hardly surprising), but should there
be a virtual meeting for IPsecME, I would suggest we attempt to put up two
slides.

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

No, none of them care about rfc822name encoding.

No products can directly deal with the rfc822name encoding as is, and since
we aren't generating Traffic Selectors based upon the certificate (we use
RPL and VTI), it doesn't really matter.  IPsec IKEv2 will need to accept
connections from any node that has the right CA signature.

    > and this would result in a new IETF review.

I think you mean, IESG review.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Mar 2020 13:58:24 -0400

> The MASA cert/key is identical to the "manufacturer key pair for IDevID

...

All fixed, Max Pritikin double checked them, which resulted in a sentence of
clarification, which I thought I posted on Monday, but I didn't actually.

I think I did post -37 two weeks ago (Feb 26, I think) to the WG ML asking
for others to check my work before I bother Ben again.

the one sentence fix:
https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-37&url2=draft-ietf-anima-bootstrapping-keyinfra-38

the new examples:
https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-37&url2=draft-ietf-anima-bootstrapping-keyinfra-38

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Mar 2020 08:00:28 +1300

Thanks for the updates, and for BRSKI-38.

Regards
   Brian

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Mar 2020 15:01:06 -0400

> Thanks for the updates, and for BRSKI-38.

Indeed -- thank you for the new version.

W

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2020 12:06:27 -0700

Hi Toerless,

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

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

> 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 https://www.ietf.org/standards/process/iesg-ballots/ the sponsoring AD
can request the "Single Discuss" procedure be used, or ask the chair to
invoke the "Alternate" ballot procedure.

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

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2020 12:08:50 -0700

To confirm: I should not be waiting for any other reviews before I look at
the -38?  (What with it being outgoing-AD-season I can't promise an exact
date, but can bump it up the list a bit.)

Thanks,

Ben

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Wed, 11 Mar 2020 19:57:44 +0000

Sorry was a little busy to reply earlier

See below for EV>

-----Original Message-----
From: Toerless Eckert <[email-masked]>
Date: Wednesday, 11 March 2020 at 16:18
To: Michael Richardson <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, Warren Kumari <[email-masked]>, "[email-masked]" <[email-masked]>, Anima WG <[email-masked]>, Eric Vyncke <[email-masked]>
Subject: Re: [Anima] We want BRSKI and ACP!

EV> about ACP document, I still need to check whether all 70+ comments were addressed and then as changes were substantial, re-do an IETF Last Call, then IESG evaluation, so, could be mid April indeed assuming Last Call goes well

-éric

    Thats all i know.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 11 Mar 2020 16:17:00 -0400

> date, but can bump it up the list a bit.)

Correct.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 20 Mar 2020 12:57:11 -0400

A gentle reminder on this (in your copious free time :-))
W