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

[Russ Housley <[e-mail]>]

One minor additional point, otherName would allow binary encoding, which might be helpful for the IoT environment.  The URN approach does require ASCII string.

Russ

> On Jun 30, 2020, at 12:10 PM, Toerless Eckert <[e-mail]> 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
>> "[e-mail]", 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
>> [e-mail] 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 <[e-mail]> 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 <[e-mail] <mailto:tte@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 [e-mail] <mailto:[e-mail]>.
>>>>>> 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, [e-mail] <mailto:[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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 [e-mail] <mailto:[e-mail]> (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+ietf@sandelman..ca <mailto:[e-mail]>> wrote:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Russ Housley <[e-mail] <mailto:[e-mail]>> 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
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> ---
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>> 
>>>>>   -- 
>>>>>   ---
>>>>>   [e-mail] <mailto:[e-mail]>
>>>>> 
>>>>>   _______________________________________________
>>>>>   Anima mailing list
>>>>>   [e-mail] <mailto:[e-mail]>
>>>>>   https://www.ietf.org/mailman/listinfo/anima
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Anima mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/anima
>>>>> 
>>>> 
>> 
>> -- 
>> ---
>> [e-mail]
>> 
>> _______________________________________________
>> Anima mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
> 
> -- 
> ---
> [e-mail]