On Wed, Jun 24, 2020 at 1:06 PM Toerless Eckert <[email protected]> wrote:
> Thanks, Eliott, inline
>
> Btw: Just seeing that the folks holding the DISCUSS are not
> explicitly included in this thread... not sure if they
> follow the anima WG mailing list overall... Cc them ?
>
I should clarify that I am not holding a DISCUSS as I am no longer on the
IESG. That's what the parentheses around my position in datatracker mean,
which is to say that I dropped off the IESG while my DISCUSS was pending.
To the best of my knowledge it doesn't have any special status and is just
kept around as a historical reference.
I certainly have opinions here, but I'm weighing in as a community member,
as are Stephen, Russ, and Sean.
-Ekr
> On Wed, Jun 24, 2020 at 12:40:48PM +0200, Eliot Lear wrote:
> > > I don't think this is true
> >
> > If the ACP subsystem allocates a name and the user management system
> allocates a name, then you have the potential of a conflict. Again, the
> odds of an actual conflict are very low.
>
> Whether or not there is ACP, we are talking about about an app
> that has access to certificates on routers that could have rfc822name
> and the app would send emails to those rfc822name addresses
> and something good would happen.
>
> I am quite sure that such an app does not exist, but it could
> be nice, so lets call it the unicorn app. The ACP rfc822name
> structure certainly allows for unicorns.
>
> If you want to deploy ACP and you don't care about unicorns,
> you ignore the issue. The conflict you are talking about would
> only hurt the unicorn but not the ACP.
>
> When you do care for unicorns you have several options:
>
> a) You can make sure that the local part name space is well managed
> so local part names for ACP can not be incorrectly assigned
> to other purposes. Likely works by default because common
> solutions that let users assign local names or aliases have
> length limits < ~ 30 characters and ACP local part is 40 + X
> (X being extensions). Upper limit in rfc822name is btw 64
> for local name part.
>
> b) You use a different name or subdomain (see) to separate
> name spaces between users and the names you use inside
> network operations / ACP. Most common solution IMHO.
>
> c) You train the unicorn to forward the names based on where
> they are found to another domain. typical setup in email
> ssytem when there are logical names but distributed MTA.
>
> > You can make an operational recommendation of course. However, some
> enterprises simply do not do subdomains (I email from one such enterprise
> now).
>
> Different (Sub)domains are the standard tool to separate
> local-part namespaces in rfc822. It is widely used in
> enterprises
>
> Do not confuse what you as the user see with whats under
> the hood in RFC822. As soon as you have multi-vendor
> distributed MT setups you will use different subdomains
> under the hood with forwarding and name aliasing/hiding.
> The vendor you work for even sells comms products with MTA
> in them that would do that last i checked (couple years back).
> I am sure if you could look at the whole domain space of
> your employer, you would find a lot of subdomains, including
> for other MTAs.
>
> But then again, whatever is visible to the outside, both
> domains and local name parts is subject to corporate comms
> policies, so indeed it is likely that subdomains would only
> be available to what that department likes. Many
> network operations orgs in SP/enterprise therefore just
> buy their own domain name that has nothing to do wih
> their enterprises "brand" domain name and use that other
> domain to freely asign names for routers, network exquipment
> and network ops related MTA, web servers etc. And then make
> sure none of these domain names are on public accessible
> DNS servers/zones.
>
> So, if example.com was a typical brand-marketing lead enterprise,
> the network ops teams would ask to get acp.example.com and
> even though they may actually run the example.com DNS and MTAs,
> they wouldn't be the one permitted to decide whats on it,
> so after four months of discussion, the network ops team
> would go buy example.org and use acp.example.org.
>
> > > | Certificates for an ACP MUST only be given to nodes that are allowed
> > > | to be members of that ACP. Because the signing CA relies on an ACP
> > > | Registrar, the CA MUST only sign certificates with ACP domain
> > > | information through trusted ACP Registrars. Any existing CA,
> unaware
> > > | of the new ACP domain information field, can be used as long as it
> > > | only allows signing requests from trusted ACP Registrars and from
> > > | nodes or registrars trusted not to include ACP domain information in
> > > | their certificates.
> >
> > Ok, but...
> >
> > > | These requirements can be achieved by using TA private to the owner
> > > | of the ACP domain or potentially through appropriate contractual
> > > | agreements between the involved parties. Public CA without such
> > > | obligations and guarantees can not be used as TA for ACP domains,
> but
> > > | they can be used to obtain certificates for TAs of ACP domain.
> > >
> > > Aka: The ACP trust model is built on controlled access TA and
> > > specific functionality registrar, it does not matter at all which
> > > field the information is encoded into for the trust model described.
> >
> > If the TA is itself signed by a public CA, then the CA can sign other
> names or for that matter issue other signing certs , and (at least by
> normal use of PKI) the name will validate without the TA ever having been
> used. Assuming that???s not what you mean, how does the client know which
> TA is authorized?
>
> ACP nodes are initialized before ACP can run by a registrar
> with a cert and the appropriate TA. Cert and TA are renewed
> via EST automatically before they expire. So TA are fully
> controlled by the registrar(s).
>
> The public CA would never be a feasible TA. Only the private root cert
> would be an appropriate TA. Whether that private root cert is
> self-signed or signed by a public CA is irrelevant, that would
> not change the result of an ACP cert chain validation: The
> cert chain validation MUST terminate in a TA. The attackers
> cert you mention would only be signed by the public CA, which is
> not a TA for the ACP.
>
> I don't think there is any benefit of letting private root CA certs
> as required by ACP to be signed by public CA today. Thats also
> not done with any of the private root CA certs i know from
> enterprises, so nothing new here with ACP.
>
> With ACME mail we would get new options, but one has to see how
> more beneficial they are from just having an enterprise run its
> own private CA solution. You can easily buy private CA solutions
> as a cloud service from the usual suspectsa. I think the ACME
> stuff is primarily when you do want to use the certs for
> external authentication, which ACP wouldn't need unless we
> go into maybe future ACP for federations.
>
> > > Actually right now my personal recommendation would be to allocate that
> > > email address (prefix) rfcSELF{+...}@.. to the ACP admin to see if
> there was ever
> > > some unintended side effect such as email to that address
> > > that was generated by other software.
> >
> > I like that idea.
>
> Cheers
> Toerless
>
> > > Btw: ANIMA and ACME folks had a side meeting last year (i think you
> > > where there ?!), and of course one of the ideas is to be able
> > > to use ACME mail signed certs in the future, but this is outside
> > > the scope of the document. But the recommendation
> > > in the doc to use an ACP domain name part that you own already
> > > prepares for that, so i think it should be fairly easy to use
> > > in the future ACME web PKI as TA just from the perspective of
> > > using the ACP rfc822name as the validation email mechanism. There
> > > may be other ACME issues to resolve though.
> > >
> > >> It???s not perfect.
> > >
> > > Thats how i started to think of initially as well coming from
> > > just the problem of how to overcome ossification of the ecosystem
> > > we have to deal with. But in the meantime i think the format
> > > of rfc822name is near perfect for both human consumption as well
> > > as for managing it - has domain-name to tie into something you
> > > can have authoritatively.
> > >
> > >> That???s the nature of an expedient. But it???s probably Good Enough
> for now. For the eventuality that another name could be used over time,
> it???s probably worth getting an OID and using otherName where possible,
> but we shouldn???t hold this work up over a highly theoretical attack.
> > >
> > > I think the reason for solutions that like to reuse the
> > > rfc822name format of local@domain but choose new encoding
> > > points is so that they can reuse existing local@domain
> > > user identifiers but indicate a specific app. Much
> > > like a uri scheme of newapp:local@domain
> >
> > This requires a broader discussion that need not hold up this draft.
> >
> > Eliot
> > >
> > > In the case of ACP this is not necessary, because we
> > > simply distinguish on the local part and/or the domain
> > > name. No need to support overloading of the same rfc822names
> > > for different uses. That is something more relevant to
> > > humans who like to have a single local@domain ID for
> > > themselves across all apps. ACP IDs are more functional IDs.
> > >
> > > Cheers
> > > Toerless
> > >
> > >> Eliot
> > >
> > >
> > >
> > >> _______________________________________________
> > >> Anima mailing list
> > >> [email protected]
> > >> https://www.ietf.org/mailman/listinfo/anima
> > >
> > >
> > > --
> > > ---
> > > [email protected]
> >
>
> --
> ---
> [email protected]
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
