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