I have read draft-aaron-acme-profiles. It seems like a good idea, please adopt.
Q: If a CA can offer legacy, quantum-safe hybrid, and maybe quantum-safe
only, certificates, are these *profiles*?
Some random comments that can be fixed after adoption:
Section 4:
The client MUST NOT request a profile name that is not
advertised in the server's Directory metadata object.
Clients will client... so yeah, tell them not to, but the paragraph after
says that they can expect to be rejected. The sentence seems unnecessary to
me. I rather we document what happens when a client misbehaves, rather than
say not to be bad.
It's also possible, since the list of profiles is not client ("Account")
specific, that some profiles are simply unavailable to that client.
So, even if they use a profile name that is listed, it still might not be
allowed.
Like, maybe clients get *one* code signing certificate per quarter or something.
That's probably two different things to reply with.. [PROBLEM-DETAILS] to the
rescue.
Section 5, Security Considerations
The one exception is in regards to CA Policy Considerations. RFC
8555 did not address how a server should determine whether it is
willing to issue the certificate as requested by the finalize CSR.
This document greatly simplifies this determination by making the
contents of the CSR (beyond the Subject Alternative Names and Subject
Public Key) irrelevant to the decision-making process.
This looks like a normative update to RFC8555.
I think it should be moved to a new section, and explicitely made into such
an update. I'm not even sure the SAN in the CSR should be trusted!
The CSR is a container for public key only, and
!!draft-ietf-lamps-csr-attestation!!
As a minor thought:
"profiles": {
"profile1": "https://example.com/acme/docs/profiles#profile1";,
"profile2": "https://example.com/acme/docs/profiles#profile2";,
}
maybe instead:
"profiles": {
"profile1": { "doc" : "https://example.com/acme/docs/profile1"; }
"profile2": { "doc" : "https://example.com/acme/docs/profile2"; }
}
I don't have a good suggestion right now for a machine readable version of
the profile. I don't know if there is one beyond some legal template for a
CSP, but perhaps there will be one in the future.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
