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

[Seo Suchan <[e-mail]>]

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 <[e-mail]> 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
>>     [e-mail]
>>     https://www.ietf.org/mailman/listinfo/acme
>     _______________________________________________
>     Acme mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/acme
>