[Acme] ACME integrations with BRSKI and the cmcRA EKU

[Michael Richardson]

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. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






signature.asc
Description: PGP signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Ryan Sleevi]

Thanks for bringing it to the list, Owen.

This is something we're trying to lock down in the CA/B Forum, at least
with respect to the 'http-01' method, by making it clear that, like
tls-alpn-01, it cannot be used as an Authorization Domain Name (i.e. a
domain and all of its descendents), only as an FQDN.

So this method primarily is for the 'dns-01' method, which seems to suggest
that, at a minimum, the ACME server needs to indicate to the ACME client
what modifications it will accept, since the ACME client will need to
actually modify the DNS record at the appropriate label. If the server only
chooses a single label, then it seems both likely and possible that the
server may choose a dns-01 challenge that the client cannot fulfill (e.g.
the client can only modify subdomain.example.com and descendents, but the
server/CA chooses to challenge against example.com)

So I *think* it would benefit from having the server be able to issue
challenges against several identifiers, and communicate that to the client,
which seems to argue "Yes" for your question #2.

Equally in this scenario, I think you're asking whether or not the client
should be able to indicate its capabilities to the ACME server, for
selecting appropriate challenges. If a client is using dns-01 and can only
modify subdomain.example.com, it doesn't benefit the client at all if the
server chooses to also allow example.com. The question is whether there's a
security risk in doing so; that is, should the client be able to
affirmatively restrict the server or does it not matter.

Does that accurately capture things?

On Fri, Dec 4, 2020 at 10:25 AM Owen Friel (ofriel)  wrote:

> That is what is currently documented – the server simply picks the one
> domain that it wants the client to fulfil the challenge against.
>
>
>
> That was presented as the current documented approach. And I also
> presented the open questions if we needed to build flexibility in client
> request and/or server response. There were no concrete opinions as far as I
> recall (waiting on the exact minutes) and Rich said to bring the qs to the
> mailer for further discussion.
>
>
>
> Cheers,
>
> Owen
>
>
>
>
>
> *From:* Acme  *On Behalf Of *Felipe Gasper
> *Sent:* 04 December 2020 21:35
> *To:* Owen Friel (ofriel) 
> *Cc:* acme@ietf.org
> *Subject:* Re: [Acme] acme subdomains open items
>
>
>
> I wasn’t part of IETF 109 .. was it discussed simply to give CAs the
> ability to choose whether it tries authz against parent domains without the
> client’s requesting it?
>
>
>
> This is how our (non-ACME) Sectigo integration works currently, and it
> suits us well.
>
>
>
> -F
>
>
>
> On Dec 4, 2020, at 02:23, Owen Friel (ofriel) <
> ofriel=40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Hi all,
>
>
>
> As recommended by the chairs at IETF109, bring the two open items to the
> list for discussion. These were raised by Felipe and Ryan previously.
>
>
>
> 1: Does the client need a mechanism to indicate that they want to
> authorize a parent domain and not the explicit subdomain identifier? Or a
> mechanism to indicate that they are happy to authorize against a choice of
> identifiers?
>
>
>
> E.g. for foo1.foo2.bar.example.com, should the client be able to specify
> anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?
>
>
>
> 2: Does the server need a mechanism to provide a choice of identifiers to
> the client and let the client chose which challenge to fulfil?
>
>
>
> E.g. for foo1.foo2.bar.example.com, should the server be able to specify
> anywhere from 1 to 4 identifiers that the client can pick from to fulfil?
>
>
>
> Both 1 and 2 require JSON object definition changes. Currently, the
> document only defines how a client can submit a newOrder / newAuthz for a
> subdomain, and the server can chose any one parent identifier that it
> requires a challenge fulfilment on
>
>
>
> Owen
>
>
>
>
> https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01
>
>
>
> https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4
>
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Owen Friel (ofriel)]

That is what is currently documented – the server simply picks the one domain 
that it wants the client to fulfil the challenge against.

That was presented as the current documented approach. And I also presented the 
open questions if we needed to build flexibility in client request and/or 
server response. There were no concrete opinions as far as I recall (waiting on 
the exact minutes) and Rich said to bring the qs to the mailer for further 
discussion.

Cheers,
Owen


From: Acme  On Behalf Of Felipe Gasper
Sent: 04 December 2020 21:35
To: Owen Friel (ofriel) 
Cc: acme@ietf.org
Subject: Re: [Acme] acme subdomains open items

I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to 
choose whether it tries authz against parent domains without the client’s 
requesting it?

This is how our (non-ACME) Sectigo integration works currently, and it suits us 
well.

-F


On Dec 4, 2020, at 02:23, Owen Friel (ofriel) 
mailto:ofriel=40cisco@dmarc.ietf.org>> 
wrote:

Hi all,

As recommended by the chairs at IETF109, bring the two open items to the list 
for discussion. These were raised by Felipe and Ryan previously.

1: Does the client need a mechanism to indicate that they want to authorize a 
parent domain and not the explicit subdomain identifier? Or a mechanism to 
indicate that they are happy to authorize against a choice of identifiers?

E.g. for foo1.foo2.bar.example.com, should the client be able to specify 
anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?

2: Does the server need a mechanism to provide a choice of identifiers to the 
client and let the client chose which challenge to fulfil?

E.g. for foo1.foo2.bar.example.com, should the server be able to specify 
anywhere from 1 to 4 identifiers that the client can pick from to fulfil?

Both 1 and 2 require JSON object definition changes. Currently, the document 
only defines how a client can submit a newOrder / newAuthz for a subdomain, and 
the server can chose any one parent identifier that it requires a challenge 
fulfilment on

Owen

https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01

https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] acme subdomains open items

[Felipe Gasper]

I wasn’t part of IETF 109 .. was it discussed simply to give CAs the ability to 
choose whether it tries authz against parent domains without the client’s 
requesting it?

This is how our (non-ACME) Sectigo integration works currently, and it suits us 
well.

-F

> On Dec 4, 2020, at 02:23, Owen Friel (ofriel) 
>  wrote:
> 
> 
> Hi all,
>  
> As recommended by the chairs at IETF109, bring the two open items to the list 
> for discussion. These were raised by Felipe and Ryan previously.
>  
> 1: Does the client need a mechanism to indicate that they want to authorize a 
> parent domain and not the explicit subdomain identifier? Or a mechanism to 
> indicate that they are happy to authorize against a choice of identifiers?
>  
> E.g. for foo1.foo2.bar.example.com, should the client be able to specify 
> anywhere from 1 to 4 identifiers they are willing to fulfil challenges for?
>  
> 2: Does the server need a mechanism to provide a choice of identifiers to the 
> client and let the client chose which challenge to fulfil?
>  
> E.g. for foo1.foo2.bar.example.com, should the server be able to specify 
> anywhere from 1 to 4 identifiers that the client can pick from to fulfil?
>  
> Both 1 and 2 require JSON object definition changes. Currently, the document 
> only defines how a client can submit a newOrder / newAuthz for a subdomain, 
> and the server can chose any one parent identifier that it requires a 
> challenge fulfilment on
>  
> Owen
>  
> https://datatracker.ietf.org/meeting/109/materials/slides-109-acme-subdomains-01
>  
> https://tools.ietf.org/html/draft-friel-acme-subdomains-03#section-4
>  
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme