Re: [Anima] ACME integrations with BRSKI and the cmcRA EKU

[Esko Dijk <[e-mail]>]

Thanks for the useful intro Michael. 

> A Registrar that uses RFC8555 to talk to it's CA could have three different
> kinds of anchors:

The Registrar also could have different identities used at the same time:

1) ACME client TLS identity   (towards ACME server)
2) Registrar/EST-server TLS server identity  (towards Pledges)
3) Registrar/EST-server signing identity  (for signing Voucher Requests)
4) Registrar TLS client identity towards MASA server

For #1, ACME client it could use any identity / 'account' that was able to prove control of the DNS domain, so it can be unrelated to other identities. 

> 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.

These options could be considered for the signing identity #3:

1) it wouldn't work if the 'RA' flag is not set. The BRSKI security architecture depends on 'RA' being set for Registrars, and also ACP does. In my view a MASA MUST check for 'RA'.
2) this can work
3) Registrar signs with a certificate not with a raw-public-key. And a raw-public-key cannot have an 'RA' flag set. So that wouldn't work

Option 2) looks good as an identity for signing Voucher Requests.  Either a single selfsigned RA+CA cert, or a chain of two: RA -> self-signed-CA. The latter is useful as it allows in the future more Registrars (with RA flag set)
to be created within the same private domain (CA).  Of course this certificate / chain must then be created by hand i.e. it cannot be automated using ACME.  Do you see this as a problem? To me it seems acceptable.

Details of this solution: MASA will accept the above signing (since 'RA' is set - check passes) and will pin one of these certs. The Pledge will too accept as per BRSKI 5.6.2 because the Registrar's cert is either equal to, or chains to, the pinned-domain-cert.
The Pledge will do after BRSKI-specific bootstrap operations the GET /cacerts (Section 5.9.1) and the Registrar then serves back 2 CAs: { self-signed CA ,  ACME CA } .  The Pledge will then do EST e.g. /simpleenroll with Registrar; and Registrar 
meanwhile interfaces as a client with the ACME server to obtain  a new operational domain cert for the Pledge under the DNS domain owned by the Registrar. The Pledge can verify this new cert against its trust store that now contains the 
two CAs: { self-signed CA ,  ACME CA } , so it will validate.  Note that the Registrar enrolls the Pledge into a domain (with ACME-issued cert) that the MASA knows nothing about!  I assume this is allowed by BRSKI as I read that the Pledge is
supposed to install the /cacerts response in its trust store. 

Now if above solution option 2) works with ACME, there seems to be no need to request certs with 'RA' set from the ACME CA.  The 'RA' certs are under the control of the Registrar's private domain. The auto-created EE certs are created
by the ACME CA under control of Registrar.  

Or would there still be some need to use option 1) and update the ACME RFC to enable ACME CA handing out certs with cmcRA set?

> One thing that occurs to me that a pledge which *can* form an ACP, probably
> should *not* if the cmcRA bit is not set.  

As said above the BRSKI security architecture depends on 'RA' being set for Registrars, and also ACP does. So it seems risky to assume situations in which it is not set and MASA lets the bootstrap continue.
So the Pledge doesn't need to evaluate if cmcRA is present - because the bootstrap wouldn't succeed in the first place if cmcRA is absent, right? Or do I miss something.

Best regards
Esko

IoTconsultancy.nl  |  Email/Teams: [e-mail] 

-----Original Message-----
From: Anima <[e-mail]> On Behalf Of Michael Richardson
Sent: Friday, December 4, 2020 21:33
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: Max Pritikin (pritikin) <[e-mail]>
Subject: [Anima] ACME integrations with BRSKI and the cmcRA EKU