Hi Toerless, I think either a URI or otherName are pretty much functionally equivalent. I might go with URI for one particular reason, which is that the tooling – in particular OpenSSL – will handle it better.
Eliot > On 30 Jun 2020, at 18:10, Toerless Eckert <t...@cs.fau.de> wrote: > > Just had a call with Russ and Barry (thanks Russ, Barry), and here is > what transpired, and it comes with a Q to the ANIMA WG wrt. to > solution options (see below). Hopefully Russ/Barry will correct me if i > misrepresent anything. > > Russ and Barry agreed that a solutions where email addresses are not > primarily intended to be used for actual emails (e.g.: using SMTP/RFC5321) > may be something found in the wild, but in their opinion, it would create > harm (to i guess the Internet email system), significant enough to warrant > an IESG DISCUSS if such use was to be defined into an Internet Standard. > > If i understood it correctly, the choice of otherName by previous solutions > similar might have also been influenced by the same rejection to use > rfc822Name > It sounded to me from the call as if email address/rfc822Name might have > been desired to be used first by e.g.: XMPP but then they had to move to > an otherName (RFC3920 i think) because of resistance to get that standardized. > That at least would be a detail i was missing from the prior explanations on > this thread. > > I continue to disagree, but i think the resolution of this basic > argument would create an inacceptable timeline to progress ANIMA, > so i do not want to afford this discussion any longer for the ACP draft. > [ Hopefully i can get back to after ACP is done because i still think it > is quite fundamental. ] > > a) Russ promised me a text stub or pointers thereto necessary/sufficient to > define a new > use (and i guess IANA registration). Probably something similar to > what is e.g.: found in rfc8398. > > I think IANA registration is here: > https://www.iana.org/assignments/smi-numbers/smi-numbers.xml > See e.g.: id-on-SmtpUTF8Mailbox, > registration procedure: spec required, expert: Russ Housley > > b) I brought up the point that using uniformResourceIdentifier instead > of a new otherName would avoid that any part of the ecosystem including > diagnostic tools would have to be software updated with new ASN.1 > en/decode work and create unique names useable outside certificates as well. > > If we used "acp:<local>@<acp-domain-name>", this would require > review process for the new "acp:" scheme, which according to my reading of > process would take maybe up to one month. Barry suggested to simply > register an IETF URN parameter (RFC3553), e.g.: > > urn:ietf:params:acp:<local>@<acp-domain-name> > > IANA registry: https://www.iana.org/assignments/params/params.xhtml > Registration procedure: IETF review (which i guess is the ACP draft > IETF review). > > So, would love to hear opinions of a) vs. b). Am i overselling the URI option > vs. the otherName option ? I have no experience on this backend side, i am > just trying find the most pragmatic, easy to adopt option for operators, > and i have seen a of backend systems (inventory management or the like) > where names are shuffled around, and we started using email addresses because > those are always supported identifier types in backend systems. No idea if > URI are that common, > but at least they could be there because they are an existing defined > name/address type. > For otherName, those uses outside certificates would need to come up with > their own > field type i think. > > Given how this is not an email address anymore, it > would be prudent to introduce one degree of extensibility easier to manage: > > otherName: node:local@acp-domain-name > URN: urn:ietf:params:acp:node:<local>@<acp-domain-name> > > Where "node" is the value we define in ACP, and other values here > are the extension points. > > Final note: of course we loose the ability to use public CA that an > sign rfc822Name, e.g.: via ietf-acme-email-smime, which we would have > if we whee permitted to use email addresses as ACP names, and i was getting > fond of that option, but given how we did not perceive this nice option > when we started ACP, its at least no set-back from the original ACP goals. > > Cheers > Toerless > > On Sun, Jun 28, 2020 at 06:11:49PM +0200, Toerless Eckert wrote: >> >> On Sun, Jun 28, 2020 at 10:47:51AM -0400, Russ Housley wrote: >>> Brian: >>> >>> The point of a certificate is to bind the public key to the identity of the >>> private key holder. The certificate supports many different forms of names >>> to support many different protocols. The rfc822name is used to bind to an >>> email address. >> >> How do you think IETF should decide on what is a semantic correct >> email address ? RFC5280 simply inherited the non-crypto definitions >> of email address/mailbox. >> >> Do you think it is appropriate for you to recommend blocking progress >> of a document through IESG review based on your interpretation what >> does and what does not constitute a semantic correct email address ? >> >> Do you think that there are rfc2821 email addresses that are >> semantically correct if not used in a certificate, but that are >> not semantically correct for use in rfc5280 certificates ? If so, >> can you please explain how such a differentiation would be justified >> by existing RFC text ? >> >> If you do not think that there is a semantic correct email addresses >> outside and inside of certificate/rfc822Name use, how then would >> it be appropriate for you, Ben or LAMPS to decide on what is and >> what is not a semantic correct email address. >> >>> And, something else is going on here. >> >> Are you saying the addresses are (1) semantic correct email addresses AND >> something else is going on, or are you saying (2) they are NOT >> semantic correct email addresses AND something else is going on. >> >> If you are saying (1), we are back to the above discussion of >> the standing of how to decide what does and what does not >> consitute a semantic correct email address. >> >> If you are saying (2), i fully agree, but i would need an explanation >> of how such "something else" would invalidate the use of such >> email addresses in rfc822Name, because i see no further requirements >> against email addresses in rfc822Name other than what you showed >> in a prior mair on this thread. >> >> If a terminal is assigned an email address of >> "room17.termin...@example.com", and the software says to the >> user "you are sitting in Room17 on Terminal5", because the >> software expected a particular formed local part of its >> email address and parsed it, that is something else going on. >> >> If the same email address is then use together as an >> identifier together with a password for the terminal to >> access some resources, oh, like a library database, that is >> also something else going on. >> >> This is pretty much what ACP does. What is IMHO is NOT going >> on here is that these additional aspects render >> room17.termin...@example.com into a non semantic correct >> email address. They just do more with it. >> >>> That is why I recommend otherName instead of rfc822name. >> >> No, if you would just recommend an alternative that would be great, >> but you are blocking progress of a document that has a lot of >> in our opinion crucial explanations how that alternative would >> create more use-case harm than the solution choosen in the document. >> >>> I think that everyone understands that at this point. >> >> I do not understand how a recommendation like yours can raise to >> a blocking DISCUSS in an IESG review. >> >>> Eric: >>> >>> Please change the write-up for this document. It currently says: >>> >>> (10) Has anyone threatened an appeal or otherwise indicated extreme >>> discontent? >>> If so, please summarise the areas of conflict in separate email messages to >>> the >>> Responsible Area Director. (It should be in a separate email because this >>> questionnaire is publicly available.) >>> >>> No. There was unanimous support for this work and nobody raised any >>> objections. >>> This is no longer the case. >> >> So, it is not a recommendation you are voicing, it is instead >> "extreme discontent". >> >> I wonder what rules of IETF are for betting how such "extreme miscontent" >> has to be technically founded or just needs to be taken into account >> without suficient technical argument. I think you have provided >> no clear technical reasoning for: >> >> - How does the documents choice cause more harm than the alternative >> proposed for the use-cases or any other possible victims ? >> - How is the choice in violation of any relevant RFC ? >> - How are the email addresses not syntactic and semantic correct addresses >> according to rfc2821 ? >> - How are otherwise statements like "i do not think this is the right thing" >> and >> "there is something else going on here" sufficient arguments for blocking >> IESG progressing the document. >> >> Cheers >> Toerless >> >>> >>> Russ >>> >>> >>>> On Jun 27, 2020, at 11:09 PM, Brian E Carpenter >>>> <brian.e.carpen...@gmail.com> wrote: >>>> >>>> Hi Eric, >>>> >>>> On 28-Jun-20 10:58, Eric Rescorla wrote: >>>>> I'm not Russ, but I don't take his point to be about ACME one way or the >>>>> other. >>>>> >>>>> Rather, I take his point to be (as he just said in his response to Brian) >>>>> that while this is *formatted* as an e-mail address, it does not in fact >>>>> correspond to something to which e-mail can be delivered >>>> >>>> It might do, simply because it is so formatted. >>>> >>>>> and therefore does not match the semantics of RFC 5280. >>>> >>>> RFC5280 does not require such a mailbox to exist. Is there another >>>> normative document, e.g. a BCP, that does require one? It's entirely >>>> possible that the authors of RFC5280 assumed that such a mailbox would >>>> exist, but this is not written anywhere that I can see. So IMNSHO, this >>>> objection to the ACP draft is attempting to hold it to a standard that >>>> isn't documented. >>>> >>>>> Taking a step back from the substantive issue, it seems to me that to the >>>>> extent to which their is debate about the meaning of 5280, this is a >>>>> discussion which cannot be resolved entirely on this list, but instead >>>>> needs to involve the LAMPS WG. >>>> >>>> That may be true, but it's not ANIMA's fault and the discussion first >>>> arose last year, so why hasn't LAMPS already considered it, if it's >>>> important enough to continue obstructing ANIMA's progress? >>>> >>>> Brian >>>> >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> >>>>> >>>>> On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <t...@cs.fau.de >>>>> <mailto:t...@cs..fau.de>> wrote: >>>>> >>>>> On Sat, Jun 27, 2020 at 11:52:20AM -0400, Russ Housley wrote: >>>>>> Toerless: >>>>>> >>>>>> I think Brian actually made my point. While the filed contains an email >>>>>> address, using it as such would result in a delivery failure. The >>>>>> private key holder cannot be reached by this address. >>>>> >>>>> Russ, i said: >>>>> >>>>>> First of all, you can if you want to, >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> >>>>> Aka: Yes, if an ACP admin thinks ACME style challenge/reply >>>>> email authentication mechanism is useful, then he can of course >>>>> set up those email addresses accordingly. I did reply to that >>>>> point exhaustively in my reply about the ACME email mechanism. >>>>> >>>>> Why do you ignore that answer ? >>>>> >>>>>> and secondly, i contest that it is a requirement to be able >>>>>> to do that if the recipient doesn't need to support it. >>>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>> >>>>>> Think about nore...@bad-corporation.com >>>>>> <mailto:nore...@bad-corporation.com>. >>>>>> You do want to make sure though that you are in control of >>>>>> the electronic mail address though, and that is given for ACP >>>>>> addresses. >>>>> >>>>> Where in rfc5280 or any other generic RFC about certificates does >>>>> it say you MUST have a mailbox that is reachable ? Where does it >>>>> say that all certificiates with rfc822Name must be email boxes >>>>> that support ACME email style challenge-reply about the email address ? >>>>> I think this is a non-existing requirement against email addresses. >>>>> >>>>> Of course, nore...@bad-corporation.com >>>>> <mailto:nore...@bad-corporation.com> can have a certificate with >>>>> that rfc822Name. It just can't use the ACME mechanism to be >>>>> generated. But the signed mails sent from that address can be >>>>> authenticated. >>>>> >>>>> Or there are never emails, because the email address just serves >>>>> as identifier of an entity such as in wifi roaming identification >>>>> and authentication. In that case you are not authenticating >>>>> e.g.: password ownership for the email address via actual emails >>>>> but via AAA protocols against a DNS domain known AAA server >>>>> for the domain part of the email address. >>>>> >>>>> If you want to write a standards track RFC that all email addresses >>>>> used in any X.509v3 certificate MUST support an ACME style >>>>> challenge/reply email, then please do that, and seee if you get >>>>> thast through. If would invalidate a lot of solutions like >>>>> those wifi roaming ones. It WOULD NOT invalidate the ACP >>>>> solution, because as said (no several times) the ACP solution >>>>> can perfectly be set up to support this. It just does not >>>>> need to. >>>>> >>>>> Cheers >>>>> Toerless >>>>> >>>>>> Russ >>>>>> >>>>>> >>>>>>> On Jun 27, 2020, at 1:40 AM, Toerless Eckert <t...@cs.fau.de >>>>>>> <mailto:t...@cs.fau.de>> wrote: >>>>>>> >>>>>>> Russ, >>>>>>> >>>>>>> Top posting re. your ACP vs. ACME question. >>>>>>> >>>>>>> ACP rfc822name are meant to be under control of the ACP network >>>>>>> operations. >>>>>>> aka: the ACP registrars could be controlling rfcSELF*@example.com >>>>>>> <http://example.com> mailboxes using >>>>>>> ACME S/MIME to get rfcSELF*@example.com <http://example.com> >>>>>>> certificates or IMHO easier control >>>>>>> the acp.example.com <http://acp.example.com> MTA. Just no need/benefit >>>>>>> to do this now IMHO: >>>>>>> >>>>>>> An ACP is a private network which is ideally isolated from other >>>>>>> ACP networks by use of private TA. Using the ACME rfc822name scheme >>>>>>> would >>>>>>> IMHO create a lot of attack components (all the MTA in the mail path >>>>>>> and domain names) if used acros the Internet - without benefits for >>>>>>> ACP. Of course, if it was all a private ACME setup within an enterprise, >>>>>>> and using mailboxes and ACME is a popular choice - sure, why not. >>>>>>> But for private CA setups there are existing IMO easier options >>>>>>> (private CA VMs using EST or the like). >>>>>>> >>>>>>> IMHO public ACME CAwith S/MIME authenitcation could make sense >>>>>>> in the future to enable authentication across different ACP domains. >>>>>>> >>>>>>> Any network has links into other domains and today they are usually >>>>>>> unauthenticated, that could be solved IMHO fairly easily. >>>>>>> >>>>>>> "private" CA of ACP domain , lets call it acpCA signs all ACP certs. >>>>>>> Its own cert is not self-signed, but signed by ACME CA via S/MIME, >>>>>>> maybe email is rfcs...@example.com <mailto:rfcs...@example.com> (no ACP >>>>>>> IPv6 address in it) >>>>>>> >>>>>>> Now the ACP nodes actually use acpCA PLUS ACMA CA's as TA. >>>>>>> After IKEv2 authenticates neigbor the followup ACP domain membership >>>>>>> step checks if the TA of the peer is acpCA. If yes, then peer >>>>>>> becomes ACP member, otherwise we have an authenticated signalling >>>>>>> channel to an interdomain / different CA peer. And that of course >>>>>>> would enable better/secure auto-configuration of such interdomain >>>>>>> links. >>>>>>> >>>>>>> This gives me good mix of security: Its still only relying on >>>>>>> well controlled private TA to get into ACP, but also doubles >>>>>>> at less secure but best available "Internet/Interdomain" >>>>>>> authentication. >>>>>>> >>>>>>> Cheers >>>>>>> Toerless >>>>>>> >>>>>>> On Sun, Jun 21, 2020 at 12:36:06PM -0400, Russ Housley wrote: >>>>>>>>> On Jun 21, 2020, at 12:28 PM, Michael Richardson >>>>>>>>> <mcr+i...@sandelman..ca <mailto:mcr%2bi...@sandelman.ca>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Russ Housley <hous...@vigilsec.com <mailto:hous...@vigilsec.com>> >>>>>>>>> wrote: >>>>>>>>>> One cannot send email to the character string in this specification, >>>>>>>>>> so >>>>>>>>>> it should not be carried in the rfc822name. >>>>>>>>> >>>>>>>>> You can send email to that character string if you configure the MX. >>>>>>>>> It was designed specifically to accomodate that. >>>>>>>>> >>>>>>>>> I objected at the time: I thought it was a stupid feature, that no >>>>>>>>> sensible IKEv2 daemon >>>>>>>>> was going to have to send/receive email. >>>>>>>>> >>>>>>>>> But, Toerless was paranoid that if we did anything at all out of the >>>>>>>>> ordinary, that the corporate CA people, in order to protect their >>>>>>>>> fiefdom, >>>>>>>>> would freak out and throw some huge roadblock in the way of deploying >>>>>>>>> the ACP. >>>>>>>>> >>>>>>>>> And, now have an ACME method past WGLC that does certificate >>>>>>>>> validation by >>>>>>>>> SMTP. >>>>>>>> >>>>>>>> Looking at the email certificate enrollment work in the ACME WG >>>>>>>> (draft-ietf-acme-email-smime-08), I have a hard time seeing how the >>>>>>>> device that knows the private key could participate in such a >>>>>>>> protocol. How do you see it working? >>>>>>>> >>>>>>>> Russ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Anima mailing list >>>>>>>> Anima@ietf.org <mailto:Anima@ietf.org> >>>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --- >>>>>>> t...@cs.fau.de <mailto:t...@cs.fau.de> >>>>> >>>>> -- >>>>> --- >>>>> t...@cs.fau.de <mailto:t...@cs.fau.de> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org <mailto:Anima@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> >>>>> >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>>>> >>>> >> >> -- >> --- >> t...@cs.fau.de >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > -- > --- > t...@cs.fau.de > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
