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

[Toerless Eckert <[e-mail]>]

On Sat, Jun 27, 2020 at 05:18:46PM -0700, Eric Rescorla wrote:
> Well, I understand you think you explained it, but unfortunately I don't
> find that argument persuasive, nor, I suspect, do others.
> 
> The ACP operator can perfectly well set up mailxobxes if he desires to.
> >
> 
> And if ACP required the operators to do so, I think that would also resolve
> this issue from an IETF perspective (although you still would likely not be
> able to get publicly verifiable certificates for this purpose, at least
> from any CA in the Mozilla root program, for the reasons I indicated
> previously).

FInd the email in the thread where i eplained to Russ how a public CA
is useless if not dangerous for what the ACP does right now, but it
could be quite useful in future extensons, such as for interdomain
auhentication via ACMPE S/MIME.

Please understand the use case first before thinking that apply
Internet public PKI requirements is always the right think to do.
This version of ACP is solely for private networks and effectively
for private PKI. We went through all that review together, and 
you and Ben approved of that text.

> The whole question circles around the use of email addresses primairily
> > for purposes other than sending to mailboxes, and i gave other
> > examples where this is common industry practice and also uses
> > certificate rfc822Name.
> 
> I don't see how that makes this a practice which we should be endorsing.

Again, give me any technical reasoning. show me any possible harm.
All i am seeing now is a choice of preference from people who where
not active in the working group, and they had 5 years time. And i think
anyhthing short of showing possible harm should really be the WG
decision.

Especially when i continuously bring technical arguments that nobody
seems to bother to read, at least hey are never acknowledged. Such
as the reasons for differet choice of preference between e.g.:
other uses of email addresses picking a new otherName vs. our
solution preference not to do tht.

And even more the harm that another choice would create for the ease
of adoption of the solution. We have several points how unnecessary
churn in encoding creates much more of harm and pain in a highly
fragmented, ossified environemnt such as that of wide area/enterprise
routers & switches than in your backyard of highly agile, often
vertically integrted cloud/web software. Please do not ignore the
the requirements of the ecosystem when expressing preferences.

Cheers
    Toerless

> 
> -Ekr
> 
> 
> > > 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.
> >
> > Let me answer this to Ben.
> >
> > Cheers
> >     Toerless
> >
> > > -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
> > > >
> >
> > --
> > ---
> > [e-mail]
> >

-- 
---
[e-mail]