Hello Michael,
Currently BRSKI Section 5.5.4 has this text:
The MASA MUST verify that the registrar voucher-request is signed by a
registrar
If the Registrar would use a non-RA certificate e.g. ACME (LE) standard EE
certificate, then it seems that it cannot get anything from MASA...?
And BRSKI would not work?
Esko
-----Original Message-----
From: Anima <anima-boun...@ietf.org> On Behalf Of Michael Richardson
Sent: Sunday, April 5, 2020 04:01
To: Esko Dijk <esko.d...@iotconsultancy.nl>
Cc: Benjamin Kaduk <ka...@mit.edu>; anima@ietf.org
Subject: Re: [Anima] Benjamin Kaduk's Discuss on
draft-ietf-anima-bootstrapping-keyinfra-39: (with DISCUSS and COMMENT)
Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
> The current BRSKI text to me suggests that CA:TRUE is a requirement for
> the pinned-domain-cert. But I'm okay with not having CA:TRUE for this
> certificate, as you propose, in which case I think the BRSKI text needs
> some minor updates on the wording.
> For example, if it's just a Registrar cert with CA:FALSE and RA:TRUE
> then it shouldn't be called a "domain CA" cert or "domain cert".
> If the Registrar is not a CA, it does need to be a Registration
> Authority (RA). (See Section 2.5.3 / 2.5.5 / 5.5.4 /
> https://tools.ietf.org/html/rfc6402#section-2.10 )
> So the requirement for the pinned cert is that it is either RA or CA.
> (Both seems also possible to encode in the cert, although that seems
> equivalent to a CA.)
I think you that you are likely correct: every entry in a chain which is not
the EE, has CA:TRUE, and the last one, is the Registrar which ought to have
cmcRA set.
If I were to locate a PKIX-lawyer hat, I would say that the Pledge SHOULD
check this. Given that there is a strong desire to operate registrar's
using only certificates obtained via ACME (LE), and it will be difficult to
get cmcRA set... I don't know what to do here.
<Please insert long EMU Thread here>
We have written in the ACP document that a device SHOULD verify the cmcRA bit
is set on any EST server that the device speaks to to renew it's certificate.
Please note that I am saying "device" and not pledge!
We did not insist on cmcRA be set in section 5.1, specifically because we
didn't know if RA:TRUE was something we could insist upon here.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
