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

Brian E Carpenter <> Sun, 21 June 2020 02:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C1063A0848 for <>; Sat, 20 Jun 2020 19:41:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4bhgzLCT1Gwz for <>; Sat, 20 Jun 2020 19:41:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC3E73A0846 for <>; Sat, 20 Jun 2020 19:41:50 -0700 (PDT)
Received: by with SMTP id x207so6636309pfc.5 for <>; Sat, 20 Jun 2020 19:41:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=aWVGCQM1h3bymCoIUSVw8dOBgan+2JuqgIuHc2/MjHE=; b=I+G6L86Rp9X7dPFj5e044ZivrPV8SPCFJ44PMzVp+PVwLYh4dKhqvKUOEnlGL4EYWZ tK+dXOFVel3d+Za1H4Gd5ZRAlEuc/Ur1I9gc1Drd8Hu16YjNHbFlya/SjUHmjIU1tvGO 0JHWzSF7eZFjO/yeJbA5z0izwH4xy7a8igvyeubeID19OWKaK7WNsKHUnVDo8Klc7NTE Qe/QMOZypMlQsXs7zswO6/UcV/q+rqjWj4i6jpRIppwAPJptAuoqfzaddEg8wbMLcPhd a0Eb8P865h4ssIoMhz0EfVsS4HhPtNzVz9hiFZLFa6/KdKCTSU437kLnIMKPSyqL0oP2 YTUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aWVGCQM1h3bymCoIUSVw8dOBgan+2JuqgIuHc2/MjHE=; b=TyX46ygC7pqf9krYYlu9mI2+VVBHrh5j6kEUuD6l1HX2F5LFvI2VFJm05FPTFY5kbZ RBNI+JgyxauzCkHYLwA+MrF2/FuwmkUNHhLrtavzT/mwNk0Qa2joQ+4kJERcBByz8O2Q //WPLh8sMT9xuJJCppmpnLnxbEP2bdxU0wDH1w45RA8PlNBSQfmpiyACbCRiexd8VrEP 2UOl3ppdxtFbFC341N9u37qiMUDVuXBJD9HhQQuDbhY+eLnfmJxavnvgRFUtLB/PkmJS 4kCph+ZnTB/QXChWKhnm2tCjXiSL+0jJvJcfBrv2TjYYTXleFhm6EZCsIk9AOdNMzhGz yaKw==
X-Gm-Message-State: AOAM5300/ubflGrwV0McfVsgZo8eVgBRm2YB3+mW3yv1FHaQgctgA3+B NhGj6X3128PpG0815VzZx4in/zPVF5Q=
X-Google-Smtp-Source: ABdhPJzbnhjTHqXKURH/4w2lLv+7pXhgCcP4vUoEB/tkZhEDcioObA15HZtk/qfKSnIRXPrAfuFVsw==
X-Received: by 2002:a63:d847:: with SMTP id k7mr8155931pgj.93.1592707310173; Sat, 20 Jun 2020 19:41:50 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id w206sm10004064pfc.28.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2020 19:41:49 -0700 (PDT)
To: Benjamin Kaduk <>
Cc: Michael Richardson <>,, Russ Housley <>,
References: <11428.1592266833@localhost> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sun, 21 Jun 2020 14:41:43 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Anima] rfc822Name use in Autonomic Control Plane document
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: Sun, 21 Jun 2020 02:41:53 -0000

Thanks Ben. It's important IMHO to be precise about technical objections and your statement below is precise. As a non-expert, I'll refrain from technical comment.


On 21-Jun-20 11:48, Benjamin Kaduk wrote:
> Hi Brian,
> On Fri, Jun 19, 2020 at 05:11:30PM +1200, Brian E Carpenter wrote:
>> Hi Ben,
>> (Back on line after a couple of days spent moving apartments.)
> (and me after getting slowed down by being sick)
>> On 17-Jun-20 14:44, Benjamin Kaduk wrote:
>>> 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?
>> Yes, but that was exactly the reason we had the discussion a year ago.
> I think the expansion of the "we" is important, here -- who did you have in
> mind?

Well, I guess it was between you and the WG, but prior to IETF-wide review.
My understanding was that we'd reached an unhappy compromise, but apparently


>>>>> 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:
>>> 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.
>> "Not the best choice" is not a DISCUSS criterion according to the IESG's own rules at
>> It was exactly this sort of endless debate over "best choice" disagreements that caused the IESG to adopt the DISCUSS criteria rules in the first place.
>> If you are saying that one of the criteria in applies, that's a different matter, of course. But really, no AD should hold a DISCUSS over "not the best choice".
> Sorry, that was the second round of Discuss and my politness filter may
> have been overactive.  Allow me to rephrase:
> I think that the use of rfc822Name in this document is inconsistent with
> the specification for that field given in RFC 5280.  I do not believe that there
> is IETF consensus (specifically, including the IETF PKIX community, e.g.,
> the LAMPS WG) for this deviation from the RFC 5280 behavior, and it is not
> documented (and consensus obtained for it) as such a deviation from RFC
> 5280.
> I believe there are several ways in which the necessary functionality for
> this specification can be obtained that remain consistent with RFC 5280;
> specifying the use of any of them would suffice to resolve the Discuss
> point.  The "smallest diff to the text" option would be to define an
> otherName OID to carry the same contents currently specified for
> rfc822Name, but other options involving splitting the semantic components
> into EKU/iPAddress SAN/extension/etc. are possible.  I could probably even
> accept a non-normative note saying that some legacy deployments used the
> rfc822Name field, though given Sean's review there would probably need to
> be a pretty strong disclaimer of the risks of doing so.
> [one more note at the end]
>> Not to mention that this is only a Proposed Standard discussion; perfection not required.
>> I don't consider myself enough of a subject matter expert to comment on the technical issue itself.
>> Regards
>>     Brian
>>>> The explanation is at
>>> 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  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.
> Thinking about this a bit more, it seems like it would be doable (and, more
> importantly, testable) to require that if the otherName (or whatever) is
> present, there MUST NOT be an rfc822Name present.  Which doesn't
> necessarily help with the "need to implement" bit for sites that use
> rfc822Name, of course, but should avoid the worst of the risks for when two
> sources of data don't match.
> -Ben