Thanks for the feedback Corey. I'll incorporate that into my draft then. On Mon, 17 Apr 2023 at 13:20, Corey Bonnell <Corey.Bonnell= [email protected]> wrote:
> > - 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. > > > > I agree that this is the right approach. While the WebPKI does not mandate > that CAs verify that the applicant actually controls the associated private > key in the request, other PKIs may want to enforce this. One vehicle for > doing so is the CSR signature (preferably with a freshness token/challenge > password included). We (DigiCert) expect that the applicant will provide us > two CSRs, and the language in section 3.2.1 of HARICA’s CPS indicates that > they do the same. > > > > For CAA, section 5.1 of the draft details why CAA tree-climbing is not > necessary, but I don’t see any information regarding checking the CAA RRSet > at the “onion” TLD itself. I don’t believe that doing such a check is > technically feasible, but I think it would be good to clarify this, as > checking the TLD is mandated by the CAA spec. > > > > Thanks, > > Corey > > > > *From:* Acme <[email protected]> *On Behalf Of *Q Misell > *Sent:* Monday, April 17, 2023 7:29 AM > *To:* Seo Suchan <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [Acme] draft-misell-acme-onion > > > > 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 list > > [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 >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
