Point taken, I think you're right. Might I suggest then two CSRs, one signed with the onion key to be submitted as a challenge response, and one submitted to finalize the order.
On Sun, 16 Apr 2023 at 22:08, Seo Suchan <[email protected]> wrote: > I think this section implies CSR has to be signed by what > subjectPublickeyinfo be used for verify it: > > rfc2986 section 3 note 2. > > Note 2 - The signature on the certification request prevents an > entity from requesting a certificate with another party's public key. > Such an attack would give the entity the minor ability to pretend to > be the originator of any message signed by the other party. This > attack is significant only if the entity does not know the message > being signed and the signed part of the message does not identify the > signer. The entity would still not be able to decrypt messages > intended for the other party, of course. > > subject public key and subject entity's private key not being matching pair > feels stretching the rule as written. > and even if csr is allowed I don't think merging finalization and challenge > verify is a good idea here: > 1. Pre-authorization (rfc8555 7.4.1) makes challenge may not have parent > order. > 2. a order capable of finalize in pending state makes ready state check > useless, in boulder that's only place actually checks for order's validity > before calling CA to sign the certificate > 3. most acme CA moved to async order finalization, so it will move to > processing if it wants or not. > > 2023-04-17 오전 12:58에 Q Misell 이(가) 쓴 글: > > Hi, > > Thanks for the comments. I'll fix the typos. > > With regard to running a Tor client or not I don't think it is too much of > a ask from CAs to run a Tor client (it needn't even be that feature > complete to simply fetch a HS descriptor), for the added benefit of CAA > enforcement. > > Regarding your comment about CSRs I think you've misunderstood how the CSR > is used. RFC2986 section 3 states that the CertificationRequestInfo > contains the public key to be included in the final certificate > (subjectPKInfo), > whilst the entire CertificationRequest can be signed with a different key > entirely, and this is what the CA/BF rules permit, and indeed what they > were designed to achieve and how HARICA implements this. > > Thanks, > Q > > On Sun, 16 Apr 2023 at 03:44, Seo Suchan <[email protected]> wrote: > >> 5.2 has few typos CAA when it should mean CA: (CAA can't read any >> descriptor, it's a text) >> >> For running CAA in general, I think appendix B of CA/B BR method b made >> in a way that CA doesn't have to run Tor client at all. And it actually >> allows signing a cert for not yet hosted onion domain, given they control >> right private key to induce that domain name. In that case making CA >> required to run Tor client to read CAA conflicts this goal. >> >> And challenge 3.2, it doesn't work for public CA: in acme context, CSR's >> pubkey sent in finalization is what CA will sign, but for challange >> perspective key there need to be ed25519 key (because it's onion v3 private >> key,) but CA/B does not allow signing ed25519 key in TLS certificate, you >> can't reuse CSR for both purpose. >> >> >> 2023-04-16 오전 1:22에 Q Misell 이(가) 쓴 글: >> >> Hi all, >> >> Hope you've all recovered from IETF116, it was lovely seeing you all >> there. Thanks to those who already gave me feedback on my draft. >> >> As promised in my brief presentation at the WG meeting, here's my post >> introducing my draft draft >> <https://datatracker.ietf.org/doc/draft-misell-acme-onion/> >> -misell-acme-onion >> <https://datatracker.ietf.org/doc/draft-misell-acme-onion/> to ease >> issuance of certificates to Tor hidden services. >> >> DigiCert and HARICA already issue X.509 certificates to Tor hidden >> services but there is no automation whatsoever on this. From my >> discussions with the Tor community this is something that bothers them so >> I've taken to writing this draft to hopefully address that. >> >> The draft defines three ways of validation: >> - http-01 over Tor >> - tls-alpn-01 over Tor >> - A new method onion-csr-01, where the CSR is signed by the key of the >> onion service >> >> An explicit non goal is to define validation methods not already approved >> by the CA/BF, however if someone can make a compelling argument for an >> entirely novel method I wouldn't be entirely opposed to it. >> >> Looking forward to your feedback, and some indication that this would be >> worth adopting as a WG draft. >> >> Thanks, >> Q Misell >> >> _______________________________________________ >> Acme mailing [email protected]https://www.ietf.org/mailman/listinfo/acme >> >> _______________________________________________ >> Acme mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
