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

Deb Cooley <> Mon, 21 December 2020 10:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 563F43A109E; Mon, 21 Dec 2020 02:54:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xZzf7OGXvL2T; Mon, 21 Dec 2020 02:54:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0487F3A103D; Mon, 21 Dec 2020 02:54:35 -0800 (PST)
Received: by with SMTP id w124so10863412oia.6; Mon, 21 Dec 2020 02:54:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rx7HI/ZcMZU9qJEFx/63DEd5yqFm3TDIgMIKjJjMnoY=; b=qSGGNXskNK5KoTzO2ObvVu4MqelVOOi7c4TBFSLnYR+XKbH8rIzlJ5V9BpKOw5hKjm IDYm2y+kaupUxnHXKXnwY2sEAl/sWxilr5Q2PSrRMQ0uI4ggFnaGsp/fxatqkhH8PbVq EzUHc3QWAeQMeIdrrhxd4CccTc0ZAVFE8F6mUFgoj6jHA/a4J6OVk/ZEHTFTYs7QLImP H94Pycxu2Wl0rB0KZuJ0BzldrUV45jdnzhcV1bdhejXLb2JnpwdqOoq5mDZSP/4kDFRc eN7svnT/DNdPjJE8P6vZ7vcMZ75XsesGwaZAc8iE83Xz0JlVOAA2eI4/ylhS+4171qZY /jpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rx7HI/ZcMZU9qJEFx/63DEd5yqFm3TDIgMIKjJjMnoY=; b=kpAQyvOZyovcm+hjjQVVpxXrFL5h4PbX5vlUORFNKAN8e0EVP/oiQYbEemBznmrEDG pgbeXJgN5CY45psHLnoq52OlC9GYJqN7bA97n90xFH5g5jVCl1DDkFdESpxGjTFTYPRI 6D/WSeoNn7TJKgNU/y9XMpmhtJWt/xHX7yqI8QxwNDb0ytJc+GvN8l0nbqviKCBjRcNG pWfYj3c5ZmRskBuL/vX4/9IapCXz+4Vs9EuJ+p/Ztzw6u1cbRdcTbz9cv9173voD2wvA 54PWLIwRnuWqm57p6kmV4w7udYSzoOoD/yoTa3irjWaUhOiEEIi1puW5dJodtaPrsc30 7L5Q==
X-Gm-Message-State: AOAM532IupCyJjxcWHXCoe3sFjiVrRhiCCb+snDkwvdPhLRbl1Ur8zVp 6XjdxIKJmB66GnE7HuDOvU88p9riBHiSOroYHQ==
X-Google-Smtp-Source: ABdhPJyEiY5vwEuml7qyGcSGhQmTvKPJIJXqmpWIURrnZPwJ2CGt1htjROl3i/MjSIKoYW6ap17B+Ff7YxhxXpdeKYQ=
X-Received: by 2002:aca:4303:: with SMTP id q3mr10655010oia.133.1608548074907; Mon, 21 Dec 2020 02:54:34 -0800 (PST)
MIME-Version: 1.0
References: <> <4603.1585620652@localhost> <> <600.1585687336@localhost> <AM5P190MB02751866462AE590EAD2EB14FDC90@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <5633.1585770340@localhost> <AM5P190MB027524F2D1530746DD48C4DDFDC60@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <13227.1586052088@localhost> <AM5P190MB0275BA7298686DBADD31F0A3FDC20@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <14837.1586479192@localhost> <AM5P190MB027501C1759C042E54C40137FDD40@AM5P190MB0275.EURP190.PROD.OUTLOOK.COM> <> <23785.1605650162@localhost> <> <26304.1607113986@localhost> <AM8P190MB097940886FE07FDA40227781FDCE0@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <AM8P190MB097940886FE07FDA40227781FDCE0@AM8P190MB0979.EURP190.PROD.OUTLOOK.COM>
From: Deb Cooley <>
Date: Mon, 21 Dec 2020 05:54:23 -0500
Message-ID: <>
To: Michael Richardson <>
Cc: "" <>, "" <>, "" <>, "" <>, "" <>, "Max Pritikin (pritikin)" <>, "Cooley, Dorothy E" <>
Content-Type: multipart/alternative; boundary="0000000000009beb7505b6f7489d"
Archived-At: <>
Subject: Re: [Iotops] [Acme] [Anima] ACME integrations with BRSKI and the cmcRA EKU
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IOT Operations <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Dec 2020 10:54:39 -0000

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

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
for real work address:

On Mon, Dec 7, 2020 at 8:54 AM Esko Dijk <>

> 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
>  |  Email/Teams:
> -----Original Message-----
> From: Anima <> On Behalf Of Michael Richardson
> Sent: Friday, December 4, 2020 21:33
> To:;;;
> Cc: Max Pritikin (pritikin) <>
> Subject: [Anima] ACME integrations with BRSKI and the cmcRA EKU
> _______________________________________________
> Acme mailing list