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

[Seo Suchan <[e-mail]>]

Does tor itself allows including random things in their hidden service 
descriptor?  tor-addr-spec-v3 2.5.1.2 says for first level plaintext 
field "Here are all the supported fields" and does not say client to 
ignore any additional field, so I don't think we can add descriptor 
field in 5.3 without amending breaking change to tor add spec first - 
which make . second level plaintext format still lists all formats they 
have: although for this they do make clients to ignore unrecognized 
lines. but just for compatibility with future revisions over tor spec.

I think we need to call tor people to include CAA into descriptor: looks 
like they are open to modifying tor spec quite fast, 4-5 commit per 
month in rend-spce-v3 file alone

https://gitlab.torproject.org/tpo/core/torspec/


2023-04-17 오후 8:29에 Q Misell 이(가) 쓴 글:
> 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 <[e-mail]> 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 <[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
>>