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

[Eric Rescorla <[e-mail]>]

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 and therefore does
not match the semantics of RFC 5280.

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.

-Ekr




On Sat, Jun 27, 2020 at 3:46 PM Toerless Eckert <[e-mail]> 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].
> > 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] 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]> 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
> mailboxes using
> > > ACME S/MIME to get rfcSELF*@example.com certificates or IMHO easier
> control
> > > the 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] (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 <
> [e-mail]> wrote:
> > >>>
> > >>>
> > >>> Russ Housley <[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]
> > >> https://www.ietf.org/mailman/listinfo/anima
> > >
> > >
> > > --
> > > ---
> > > [e-mail]
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>