I have read acme-profile-sets, (and quickly re-read acme-profile). I don't have a specific need today, which I think the protocol in this document would solve. Having said that, I'm listening.
My concern is centered around the use of human-readable profile descriptions in
acme-profile, and in this document. It was barely acceptable (tolerable) for
acme-profile. I can see a web interface that lets someone pick a profile
from available ones, with the description visible. But, I can't see this
being at all easy for a profile-set.
I wonder if profile sets wouldn't be easier to do by just turning the
right-hand side of the acme-profile profiles{} map into an array, or even a
map without the need for profileSets at all.
(BTW: The example in section 3 would appear to be missing the profileExt,
profile2a, and 2b profiles)
SC says:
Profile sets allow an ACME Server to help ACME Clients configure
themselves appropriately during PKI security transitions, such as a
change in algorithm, a change in trusted CAs, or CA key rotation.
Most PKIs have far fewer ACME Servers than ACME Clients, with ACME
Server operators well-connected to relying party requirements. This
can help transitions complete more quickly, and thus allow the PKI to
realize the security benefits sooner.
(I don't think this belongs in Security Considerations, but rather the
Introduction)
I don't know how the client would know what algorithms to use for each member
of the profile set. If the idea is that I might need an EcDSA-only certificate
and a quantum-safe one (whether it's hybrid or pure), then I'm not sure how
the client figures this out. If it already knows the details , then I'm not
sure what the directory does to help.
Given that the client has to know about profile sets, and has to pick one,
and has to then iterate on each profile, requesting a certificate, I am not
convinced that this even needs to be announced by the server.
So the idea of this document seems useful, but I don't think this document
delivers on what it says it wants to do.
(I'd rather the document use the term "quantum-safe", rather than
"Post-Quantum", even if NIST's competition is called Post-Quantum, because
that might not be the end of quantum-safety. ETSI uses quantum-safe.)
--
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]
