[Acme] ACME integrations with BRSKI and the cmcRA EKU

[Michael Richardson <[e-mail]>]

Please excuse the long intro.
Due to the cross-post, I want to make sure that everyone has the right context.

draft-ietf-acme-integrations proposes some best practices on how to use an
ACME certification authority like LetsEncrypt with an onboarding protocol
like BRSKI (draft-ietf-anima-bootstrapping-keyinfra)

BRSKI is based upon RFC7030 -- Enrollment over Secure Transport.
(One of three methods the IETF has, including CMP and now SCEP)
A "burden" of using BRSKI is that there are two (possibly private) PKIs: one
run my the manufacturer, and one run by (or for) the owner.
{ draft-richardson-t2trg-idevid-considerations and
draft-richardson-anima-masa-considerations is about the manufacturer PKI }

BRSKI is essentially the authorized replacement of a device's manufacturer
identity with a local identity.   This protocol (and others like it) are
critical to having true ownership of devices.

The ACME integration document lightens some of the burden of having the
operator run PKI in smaller environments.
It does not remove the necessicity of having some kind of "home base" which
will manage the enrollment.  The converged 6tisch/BRSKI term for this is JRC,
R being for Registrar.

RFC7030 defines the cmcRA EKU.  The Registrar's EE certificate is supposed to
have this bit set.  This is an indication that the Certification Authority
has effectively authorized that Registrar as legitimate.
If not for this bit, then a peer in the same CA could claim to be a
Registrar, and then could (re-)enroll entities into a different CA.

For the Autonomic Control Plane (ACP/ANIMA) use of BRSKI, this would be a
problem, and draft-ietf-anima-autonomic-control-plane section 6.2.5 discusses
this.   The ACP determines where the edges of the domain are by looking for
nodes that share the same CA.  Homenet participants will remember that
determining the perimiter of the (home) domain was a problem.

Now, if a "public" CA is used via ACME, such as LetsEncrypt, then the
edge-of-domain checks become meaningless.
This is likely not a problem for many of the IoT uses of BRSKI that would
benefit from draft-ietf-acme-integrations, as they don't need/want to form an
ACP.

A Registrar that uses RFC8555 to talk to it's CA could have three different
kinds of anchors:
1) it could use an RFC8555/ACME EE certificate that it obtained for itself.
   In that case, the cmcRA bit is most likely not set.

2) it could have a self-signed EE certificate, where the cmcRA bit could in
   fact be set. {Would it have any real meaning?}

3) it could use a raw-public-key.

The RFC8366 voucher system can cope with of these three things.
BRSKI does not require that the Registrar have a publically validatable EE certificate.
(nor does it forbid it)
Note that MASA can in fact evaluate these things!
The question whether there might be some rules that I haven't thought about.

One thing that occurs to me that a pledge which *can* form an ACP, probably
should *not* if the cmcRA bit is not set.  Or perhaps, the MASA should do
this evaluation, and should a TBD attribute in the voucher.

One thought that I had was whether ACME/8555 uses like envisioned in
draft-friel-acme-subdomains-03 could/should allow the entity requesting
authorization for a subdomain to request an EE certificate for the apex of
that zone with some bit set.  Would some kind of qualified cmcRA EKU make sense?

ofriel> Is this pretty much true for both self-signed and private-CA signed
ofriel> registrar certs? The pinned-domain-cert in the voucher could be EE or
ofriel> CA cert, and in either case it’s the MASA that tells the pledge to
ofriel> trust it. As long as the cert (EE or CA) is added to the trust store
ofriel> of the pledge, you would need different pledge logic to check '(if RA
ofriel> cert == self-signed then ignore cmcRA) else (if RA cert == EE cert
ofriel> then check cmcRA) which seems clunky.

ofriel> And as I believe you cannot get cmcRA from a public CA today, we
ofriel> don’t even have the halfway house of getting the RA EE cert manually
ofriel> from a public CA with the cmcRA EKU set, but automating the bluk
ofriel> pledge certs via ACME.

ofriel> Seems like mixing two sort of orthogonal things - subdomains and cmcRA..

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