Re: [Anima] rfc822Name use in Autonomic Control Plane document

[Benjamin Kaduk <[e-mail]>]

Hi Brian, Michael,

On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote:
> On 16-Jun-20 12:20, Michael Richardson wrote:
> > 
> > Hi, I have had a few conversations with Toerless who is trying to deal with
> > the feedback on the ACP document.
> > 
> > An item that has come up is the use, or claimed abuse of the rfc822Name SAN.
> > 
> > We already had this debate.
> > Some time ago.  The WG decided.

With all due respect, this is not the sole decision of the ANIMA WG to
make.  If WGs had such authority then why bother with cross-area review?

> > Three or four years ago, I think.
> 
> Yes, this is relitigating an issue that was resolved a long time ago in discussing Ben's DISCUSS:

I'm not sure I understand why you use the word "resolved" here:

> https://mailarchive.ietf.org/arch/msg/anima/lnZ-ykqas487qih86sYNVsUGbsc

In this message, I say that "I still feel like this is not the best
architectural choice" and that I will provide a sketch of an alternative in
my (then-)forthcoming ballot position; that ballot position retains the
Discuss-level concern about rfc822Name usage along with the promised
alternative.

> The explanation is at https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-24#page-26

I appreciate that the attempted justification is clearly written; however,
I do not find it compelling.  Russ did not, either, and I just heard back
from Sean Turner a few days ago to confirm that he supports Russ's
comments.  (There should be a few other editorial-ish comments that came
out of that review that are still pending.)

> I believe it is incorrect IETF process to rediscuss this point yet again.

(I'm not sure if the "yet again" refers to "after the WG decided" or "after
the (alleged) resolution of my first Discuss point".)

If you believe the technical answer is clear and that I am in error to
continue to hold my Discuss point for it, are there not also clear IETF
processes to follow?  E.g., asking for the "Single Discuss" ballot procedure
described at https://www.ietf.org/standards/process/iesg-ballots/?  I
believe I have mentioned this option to Toerless previously; my apologies
if that is not the case.  While I'm willing to continue discussing the
topic and pull in additional PKIX experts to weigh in, there is perhaps
some consideration to matters of expediency.

> > 
> > I sure wish that we could use something else.
> > But, CAs and CA software make that very difficult.
> > 
> > Given that the era of publically anchored Enterprise CAs is dead, there are
> > only two ways an (Enterprise) ACP Registrar is going to occur.
> > 
> > 1) by running a private CA.
> >    Sure anything is possible if you are writing your own code, but
> >    most will not be doing that. (I've supported otherName in my code for
> >    other purposes, and it's not that difficult, but it's not trivial either)
> >    My experience with COTS CA systems it that it's really hard to
> >    get them to do it.    Please prove me wrong.

(Sadly, I have zero experience with COTS CA systems; I know too much about
openssl at this point and would presumably be writing my own, in this
position.)

> >    The most popular Enterprise CA software is the Microsoft CA.
> > 
> > 2) by using ACME to speak to a hosted CA.  Maybe WebPKI, maybe not.
> >    Either way, getting otherName supported is even harder, because
> >    nobody else uses it.

Is the concern the ACME protocol support or just getting the hosted CA to
cope with it?  The former seems like something that we could make happen in
the IETF, and the latter seems to have high overlap with point (1).

> > If we can't depend upon otherName being filled in, then we have to look for
> > two things.  That means more code paths (two more) to test, more test
> > vectors, and what exactly does an end point do when both are present, BUT
> > THEY DO NOT MATCH?  So three more pages of text there.
> > Remember, that just rejecting the certificate means that we have to send out
> > a truck, which is what ACP aims to avoid, so that won't be popular.
> > And of course, there could also be bugs (maybe even CVEs) in the code that
> > tries to deal with the tie.

To be honest, this argument feels like a stronger one to me than the bits
in the -24.  I'm still not willing to accept into the RFC Series a document
that violates the rules set down by the specification for the technology
it's making use of, but the refocus on the "running code" aspect is
appreciated.

-Ben