Carl Wallace <[email protected]> wrote: mcr> TL;DR> no overlap between them. Reasonable to mix and match.
CW> I don’t think the front part of this is true (and I’m also doubtful
CW> the words on acme-client are altogether right). There’s bound to be
CW> overlap between device-attest, acme-client and csr-attestation and
CW> that’s OK (I’m not familiar yet with draft-liu-acme-rats, so not sure
CW> offhand if there’s overlap with it or not). Format reuse has already
CW> been noted. Additionally, one shop might use acme-client to get a
CW> code-signing cert and another shop might use csr-attestation. This is
CW> an artifact of the multitude of certificate request protocols and is
CW> not likely something that we’re going to fix here.
I can't see the overlap myself.
I'd love to update my description to either clarify lack of overlap to your
satisfaction, or to detail a case where one is a superset, or where there are
subsets of different mechanisms which do the same thing.
Maybe my post belongs in the ACME Wiki.
Format re-use might imply some common code, sure, but that's not important to
the decision as to whether doing X implies you don't need to do Y.
Did you read to the end, where I postulated a scenario that uses all 4+RFC8823?
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
