Re: [Anima] representing ACP info in X.509 certs

[Toerless Eckert <[e-mail]>]

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 ?

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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/anima
> > 
> > 
> > -- 
> > ---
> > [e-mail]
> 

-- 
---
[e-mail]