On Tue, Jun 30, 2020 at 08:59:24PM +0200, Eliot Lear wrote:
> 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.
Thanks, Eliot. This was/is my initial thinking. let me see what i can
put into the ntext rev. quickly.
Just learned of one benefit of otherName in that it should also be
possible to signal it in IKEv2 for IDi/IDr via ID_DER_ASN1_GN...
I think ultimately we can define them to be interchangeably, but not quite sure
how yet.
Cheers
toerless
>
> Eliot
>
> > On 30 Jun 2020, at 18:10, Toerless Eckert <[email protected]> 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
> >> "[email protected]", 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
> >> [email protected] 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
> >>>> <[email protected]> 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 <[email protected]
> >>>>> <mailto:[email protected]>> 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 [email protected]
> >>>>>> <mailto:[email protected]>.
> >>>>>> 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, [email protected]
> >>>>> <mailto:[email protected]> 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 <[email protected]
> >>>>>>> <mailto:[email protected]>> 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 [email protected] <mailto:[email protected]> (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
> >>>>>>>>> <[email protected] <mailto:mcr%[email protected]>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Russ Housley <[email protected] <mailto:[email protected]>>
> >>>>>>>>> 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
> >>>>>>>> [email protected] <mailto:[email protected]>
> >>>>>>>> https://www.ietf.org/mailman/listinfo/anima
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> ---
> >>>>>>> [email protected] <mailto:[email protected]>
> >>>>>
> >>>>> --
> >>>>> ---
> >>>>> [email protected] <mailto:[email protected]>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Anima mailing list
> >>>>> [email protected] <mailto:[email protected]>
> >>>>> https://www.ietf.org/mailman/listinfo/anima
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Anima mailing list
> >>>>> [email protected]
> >>>>> https://www.ietf.org/mailman/listinfo/anima
> >>>>>
> >>>>
> >>
> >> --
> >> ---
> >> [email protected]
> >>
> >> _______________________________________________
> >> Anima mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/anima
> >
> > --
> > ---
> > [email protected]
> >
> > _______________________________________________
> > Anima mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/anima
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
