Re: [Acme] draft-misell-acme-onion

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 <tjtncks@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 listAcme@ietf.orghttps://www.ietf.org/mailman/listinfo/acme
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>