x509v3-sign-rsa authentication type...

Kevin Stefanik kstef at mtppi.org
Sat May 10 00:56:55 EST 2003


On Friday 09 May 2003 04:24 am, Roumen Petrov wrote:
>   Kevin Stefanik wrote:
> >On Thursday 08 May 2003 02:05 pm, Markus Friedl wrote:
> >>On Thu, Apr 24, 2003 at 01:48:55PM -0400, Kevin Stefanik wrote:
> >>>I've seen a variety of patches on the list for supporting the x509v3
> >>>certificate authentication.   Are there any plans to include any of
> >>> these in the official openssh?
> >>
> >>perhaps a simpler version.
> >
> >I've been using Rouen's patch, quite happily, for a couple of weeks now. 
> > The simpler patches didn't seem to be as full, e.g., lacking CRLs.  From
> > what I saw, most of the complexity was in the x509 store.  The actual
> > changes to openssh code didn't seem extreme. Or were they?
> >
> >Would splitting out the x509 store somehow help?  Maybe there's a way to
> > split the patch out into more digestible parts?
>
> It is possible to remove x509 store, i.e. to split patch, but
> 1.) this make order of applying patches very important.
> 2.) X509 cert. support (versions from 'b' to 'd') contain a pointer to
> function x509store_check(), i.e. when pointer is NULL don't verify cert.
> A program (sshd/ssh) should set this pointer. Take note when pointer is
> NULL this is BUG: when user authorized_keys/known_hosts files contain a
> cert. in blob format it is possible to skip cert. verification, but when
> authorized_keys/known_hosts contain DN (Distinguished Name) we should
> verify sent user/server certificate. Version after "d" call always
> x509store_check().
>
> In conclusion without x509 store we can put a cert. in
> authorized_keys/known_hosts only in blob format, with x509 store we can
> use both (blob and DN).

So it's possible to enable a certificate to be used when it is stored as a 
blob in both the identity file and the authorized keys file?  Without 
including all the x509 store parts?  In order to revoke a certificate, then, 
it would have to be removed from the authorized_keys file, just like a key 
would?  And no info on allowed CA's would be needed?

How much of the x509 store is duplicate to what openssl already does?  Can the 
complexity be reduced by pushing more work over to openssl, which should 
already have it's own setup for allowed CA's, CRL's, etc.

Sorry to pester, but I'd really like to get interoperability with Windows 
clients using certificates in the mainline openssh.  Since the heavy lifting 
has already been done (and well!), I hope it's possible.

Thanks,
Kevin




More information about the openssh-unix-dev mailing list