single reply to many emails. David Benjamin <[email protected]> wrote: >> 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. >>
> Ah, good question. The JSON encoding is a little wonky. I wrote this
> assuming we weren't to change the profiles{} map because that was already
> shipped, but plenty of room to tweak this if the WG wants to take on
Not shipped. Just adopted as I-D.
I-Ds are specifically mutable.
> Under this model, acme-profile is specifying single-order-profile config
> profiles, and profile-sets lets you express the more general thing. The
> observation is that, even after the human has made all of their decisions,
> the best response may be a couple of different orders combined, if the
> target RPs span a wide range of time, etc.
There is nothing here to allow a client to help a human configure parameters
that would be accepted. The human has to read the description, which either
is overly technical, or overly legal, or both.
> The thinking was that the top-level entries, either in profiles{} or
> profileSets{} are the distinct human choices that the CA has assembled for
> you.
Maybe.
> This isn't meant to help the ACME client decide which keys it needs.
> Automating that seems difficult because what key you have isn't really a
> property of the ACME server. It's a property of the ACME client, taking
> into account...
> - What are the capabilities of the protocol it's using the cert in?
> - What are the capabilities of the software it will install the cert into?
> - How and where does it provision private keys? Maybe it's already
> pre-provisioned all its keys into some HSM and making new keys would be a
> whole ceremony.
> - What kinds of *end-entity* keys will the desired relying parties
support?
> Since that is ultimately a client-side decision, I don't see a clear space
> for the ACME server to help. I think we're going to have to do O(num ACME
> clients) work to perform that part of the transition regardless.
Why not? Will an ACME CA sign certificates with arbitrary algorithms
present? Can I have DSA-768? Or RSA-8192 keys? Or DAGS (one of the
defeated algorithms from PQ-round 1)? Can I use MD5 as the hash?
The answer I hope, is no. So, CAs *DO* determine what keys are used.
But, this profile system doesn't actually help end users know what to do.
The ACME server might not be able to advise me between RSA-2048 vs ECDSA-256
vs ML-DSA, but if it tells me that those are the three acceptable choices
(today), then one can something useful.
mikeO> position to make crypto policy recommendations, I have in the past
mikeO> (when I represented a public CA) been literally yelled at during IETF
mikeO> sessions by browser people (one of your at-the-time esteemed
mikeO> colleagues in fact) and web hosting providers along the lines of "Stay
mikeO> In Your Lane CA! Ain't No CA Gonna Tell Me How To Set Crypto
mikeO> Policy". So I'm not sure that this framing is well motivated by
mikeO> political precedent.
I'm sorry you got yelled at, and yet, the CAs (and CABFORUM) have been
telling people what is acceptable for more than a decade.
db> Profiles don't, and can't determine the end-entity key algorithm because
db> the TLS server operator (or someone even further up the stack) is the one
db> that generates it, based on the capabilities of their server software (or
I strongly disagree.
Of course, you can't use an algorithm that you have no operational code for.
You also can't get a certificate signed for an algorithm the CA doesn't
understand.
The working thing is the common subset of the two.
If profiles or profile-sets can not tell the client what the CA would accept,
then they are useless to me.
db> whatever). I'm not trying to use ACME to help here. ACME consumes the EE
db> key, not producing it. But I think ACME can help with the *CA key and CA
db> signature*, and separating the two is valuable. For security-motivated
db> transitions, it lets us get to a place of downgrade protection
db> sooner. (See that link.) For size-motivated transitions (RSA -> ECDSA),
db> it gives us perf wins immediately.
ACME servers (CA) produce EE certificates.
ACME client propose EE public keys.
--
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]
