Subject: [Anima] issues with using public/WebPKI anchors for ACP

From: Michael Richardson <[email-masked]>
Date: Sun, 01 Nov 2020 15:53:54 -0500

A concern came up in a private thread about whether or not a Registrar could
use WebPKI [that is, a public anchor] via ACME (or other interface), within an *ACP* context.

For instance, there are efforts to use ACME with BRSKI:
   draft-ietf-acme-integrations   --- approaching WGLC
   draft-friel-acme-subdomains    -- yet to be adopted, simplifies integrations

These efforts are not aimed at enabling an ACP, but rather just onboarding of
devices.  Avoiding the need for a PKI in a SOHO is a rather useful thing.

The ACP can use a suborbinate-CA or a private-CA equally well.
The distinction between them is whether another level of CA has signed the
anchor certificate, or whether it's self-signed.  As long as *that* level
is what is returned by the EST /cacerts return, then the ACP works just fine.

The ACP fundamentally uses "if X signed Y, then Y is my friend" logic.
Some might say that it is not the best form of authorization for the overlay,
but it is simple, and there aren't a lot of other decentralized authorization
systems which are implemented already into IPsec management systems.

The problem with the above policy is that it fails if the anchor point
is a public trust anchor.  In that case, any entity that can get a
certificate signed by the same trust anchor can probably join the ACP overlay.

We could have made the ACP trust mechanism slightly more sophisticated; we
have the ACP domain in the otherName.  But, we have no way to know what
checks a public anchor will make when its sets the otherName.
At this point, most public anchors will not put anything they can not verify
in the otherName, so it will in fact just fail.

Some Enterprises have subordinate-CAs (aka "Enterprise CA") which chain up to
a public trust root.  The trend (which may be universal at this point due to
CABForum policy), is for those subordinate CAs to be operated by the parent
CA in an outsourced fashion.  Those CAs may be sign anything the Enterprise
says, but only what the Enterprise says.  They aren't public CAs.

My understanding is that they still may not sign iPAdress SANs for reserved
networks, or dNSName for internal names.  The servers and names involved
do not have be visible from the Internet.  So one can have:
   my.private.server.example.com IN A 10.1.1.3

with a dNSName of "my.private.server.example.com", so long as "example.com" is a public (unique) name.
If you have
   my.private.server.example.com IN AAAA 2001:db8::1234

and you want an iPAddress of 2001:db8::1234, you can have that too, since
that's not a reserved IP address, even if 2001:db8::1234 is never visible on
the Internet.

One of the reasons I wrote draft-richardson-anima-registrar-considerations
was so to capture some of my thinking about how different networks can/should
operate their BRSKI Registrar.

If the WG wants to discuss different ways of operating/building a registrar,
perhaps the WG would like to take another look at the above document.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide