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
