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

[Deb Cooley <[e-mail]>]

I don't post often, so go easy. And I've not read up on the current state
of BRSKI or MASA.  This response is based only on the original post.

If you are looking for some sort of trust for an identity, then option 2 -
the self signed cert w/ cmcRA bit set - is not it (as you allude to in your
parenthetical).  It is in the same category as a random certificate w/out
the cmcRA bit (from your background).

Option 3 is similarly flawed.  raw public keys have no identity (obviously)
and rely on knowledge of which ID goes with it via some sort of out of band
mechanism.

Now, I don't know how happy I would be to see cmcRA be an option in an auto
issued certificate (i.e. via ACME).  I'm not sure how that would work.  We
need to know the entity holding the key/certificate is actually supposed to
have it.

These are hard problems, for sure.

Deb Cooley
NSA
for real work address:  [e-mail]


On Mon, Dec 7, 2020 at 8:54 AM Esko Dijk <[e-mail]>
wrote:

> 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
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>