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.
Regards
Brian
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
not.
Brian
>
>>>>> 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.
>> "Not the best choice" is not a DISCUSS criterion according to the IESG's own
>> rules at
>> https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-undisc
>>
>> 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
>> https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/#stand-disc
>> 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
>>>> 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.
>>>
>
> 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
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
