Minimum requirements for client certificates

[Baschdel]

Sorry, that could have been me, dragonstone still generates certificates 
without a subject (And it won't be updated since I'm currently working 
on it successor).
Also there should be s little information as possible stored in the 
client certificates since they get transmitted in the clear to avoid 
giving away extra data to someone who is "just" eavesdropping without 
messing with the connection itself (and therefore having a pretty good 
chance of staying undetected).

Have a nice day!
-  Baschdel

P.s. Apologies to Sean for sending a duplicated mail, I apparently still 
manage to hit the wrong reply button in thunderbird

On 31.08.20 02:11, Sean Conner wrote:
>    I just encounted this issue with my Gemini server (running GLV-1.12556)
> and caused it to stop receiving requests.  Diagnosing the issue, I found it
> was most likely caused by a request to an area requiring a client
> certificate, only the client certificate did NOT have a subject field.  The
> Gemini protocol specification does NOT state what must be in a client
> certificate, and my server made the assumption that a client certificate
> will always have one (and did not check to see if it was missing).  It will
> now return an error of '62' if the subject field is missing.
>
>    So that brings me to my question---what *IS* the minimum we can expect to
> be in a client certificate?  Is a client certificate without a subject
> field even legal?  What about a missing issuer?
>
>    -spc
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200901/f09a0384/attachment.htm>