Owen Friel (ofriel) <ofr...@cisco.com> wrote:
> This early draft
> https://datatracker.ietf.org/doc/draft-friel-acme-integrations/ covers
> how BRSKI could potentially be integrated with an ACME CA for cert
> issuance.
I read it.
While it is certainly true that a BRSKI RA can use ACME to speak to a CA, I'm
not actually sure what it means from a standards point of view.
My code base does not connect the RA to LetsEncrypt, but rather uses
LetsEncrypt to produce IDevIDs from a provisioning process.
I think that you have a problem in STEP 2 (section 3),
and STEP 3 (section 4), STEP 3 (section 5).
In each place where you post a CSR, you omit the part where you get the
CSRattributes. At some point the pledge needs to learn about what the
delegated domain is ("domain.com").
In section 4, the figures (which need to be numbered, btw), is labelled a
Pledge, but since there is no BRSKI, it should "Client"
> Related work is
>
https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/,
> which covers how ACME could be used to issue device certs, but does not
> use BRSKI. We are currently discussing offline with Rifaat how we could
> potentially integrate both approaches.
I'll read this.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
