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: [email protected]
-----Original Message-----
From: Anima <[email protected]> On Behalf Of Michael Richardson
Sent: Friday, December 4, 2020 21:33
To: [email protected]; [email protected]; [email protected]; [email protected];
[email protected]
Cc: Max Pritikin (pritikin) <[email protected]>
Subject: [Anima] ACME integrations with BRSKI and the cmcRA EKU
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
