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