💾 Archived View for rawtext.club › ~sloum › geminilist › 002300.gmi captured on 2020-10-31 at 14:27:17. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Gary Johnson lambdatronic at disroot.org
Wed Jul 22 20:24:44 BST 2020
- - - - - - - - - - - - - - - - - - -
Hi Alex,
I follow your rationale, and unfortunately, I don't know whethermatching CNs are required by the x509 spec. I think I'd like to hearSolderpunk weigh in on this issue since it seems like a slightlyambiguous area in the spec.
Cheers, Gary
Alex Schroeder <alex at gnu.org> writes:
On Mon, 2020-07-20 at 23:11 -0400, Gary Johnson wrote:
I was under the impression that the Gemini spec already made it
mandatory to make CNs match the requested domain name. That's why I
implemented SNI in Space Age. Here's the relevant section of the
spec:
From gemini://gemini.circumlunar.space/docs/specification.gmi:
-----------------------------------------------------------------
4 TLS
Use of TLS for Gemini transactions is mandatory.
Use of the Server Name Indication (SNI) extension to TLS is also
mandatory, to facilitate name-based virtual hosting.
-----------------------------------------------------------------
If I'm misunderstanding something here, please clarify.
Hi Gary
Thanks for your response.
My thinking is this: SNI is how the client tells the server which host
it wants to reach in case multiple hosts are hosted on the same IP.
Thus, the spec says: in order to facilitate name-based virtual hosting,
we want SNI to be part of the standard. That is, both users Alex and
Gary could host their sites on a single server, and they could both use
their own server certificates. The server would receive requests from
clients for either Alex's site or Gary's site, know which certificate
to send back to the client, and serve the appropriate content. This is
the benefit of SNI.
In my mind, this doesn't require hostname verification, though! Alex's
certificate could have used the common name "Alex Schroeder" and Gary's
certificate could have used the common name "Gary Johnson". All the
client sees is a certificate, which it trusts on first use (TOFU).
Users might decide to look at the common name of the certificate, or
not. There's not even the need to provide a common name – we could have
generated our certificates using nothing but our email address, or our
organization name.
In short, I'm claiming all of these are valid certificates for a Gemini
site at alexschroeder.ch, even if they are invalid certificates for a
HTTPS site at alexschroeder.ch (maybe? I'm ignoring alt subject name):
openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
Subject: emailAddress = alex at gnu.org
openssl x509 -in cert.pem -noout -sha256 -text | grep Subject
Subject: CN = Gemini Wiki
openssl x509 -in /var/lib/dehydrated/certs/transjovian.org/cert.pem
-noout -sha256 -text | grep Subject
Subject: CN = transjovian.org
What do you think? Do you think SNI inherently mandates that the
subject have a common name field that matches the domain? It would have
to be implied in the X.509 spec somewhere, I guess?
Cheers
Alex
-- GPG Key ID: 7BC158EDUse `gpg --search-keys lambdatronic' to find meProtect yourself from surveillance: https://emailselfdefense.fsf.org=======================================================================() ascii ribbon campaign - against html e-mail/\ www.asciiribbon.org - against proprietary attachments
Please avoid sending me MS-Office attachments.See http://www.gnu.org/philosophy/no-word-attachments.html