* 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 <acme-boun...@ietf.org> On Behalf Of Q Misell Sent: Monday, April 17, 2023 7:29 AM To: Seo Suchan <tjtn...@gmail.com> Cc: acme@ietf.org 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 <tjtn...@gmail.com <mailto:tjtn...@gmail.com> > 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 <tjtn...@gmail.com <mailto:tjtn...@gmail.com> > 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 Acme@ietf.org <mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org <mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
