Hi Russ, I think everyone agrees that it's bending the purpose of a protocol element, for pragmatic reasons, and it isn't something I particularly like either. But it was a pragmatic choice made after discussing the alternatives.
Regards Brian On 20-Jun-20 04:32, Russ Housley wrote: > Brian: > > I disagree with your characterization of the situation. RFC 5280 talks about > Subject Alternative Names, and the rfc822Name is used for an email address. > This specification puts something other than an email address in that field, > and I raised a concern when I reviewed the document. Other name forms are > explicitly accommodated by otherName, and in my review, I suggested using > otherName instead of rfc822Name. > > I observe that jabber IDs have the same syntax as an email address, but they > are not carried in rfc822name because the semantics are different. > > One cannot send email to the character string in this specification, so it > should not be carried in the rfc822name. > > Russ > > >> On Jun 19, 2020, at 1:11 AM, Brian E Carpenter <[email protected]> >> wrote: >> >> Hi Ben, >> >> (Back on line after a couple of days spent moving apartments.) >> >> 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. >> >>>>> 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". >> >> 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. >>> >>> -Ben >>> > > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
