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 <tjtncks@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 <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
>>
>