[Cryptography Team] Re: SSL Certificate Validation

[Ron Teitelbaum]

Hi Tim,

That's interesting.  The differentiation I need to make is at a very high
level.  I suppose you could consider them to be different systems in which
case they are really just different CA's.  I was considering adding that
info on the Cert but still using CRL's as a middle ground.  

For example, there are systems for Hospitals, Doctors, Patients, Labs and
ER's.  Each person has different access, but they also interact with
different systems, so do you see a difference between coding authorization
Permission on a Cert and using different CA's as the instrument that defines
system access?

I understand the problems with coding system authorization and no CRL's, and
I understand the maintenance issues with low level permissions but at a very
high level I think it makes sense.

Thoughts?

Ron

> From: Cerebus
> Sent: Thursday, January 25, 2007 3:52 PM
> 
> Common name FQDNs are deprecated.  FQDNs belong in the subjectAltName
> extension.
> 
> Also, be aware that issuers are usually designated via the
> authorityKeyIdentifier extension, not via the issuer DN.
> 
> Finally, it's bad practice to put authorization data into an
> authentication instrument like a certificate.  You cannot be certain
> that revocation will be performed in a timely fashion.  Authorization
> decisions should rely on local data using the identity proved by the
> certificate.
> 
> On 1/24/07, Robert Withers <reefedjib at yahoo.com> wrote:
> > Ron,
> >
> > I should be clear that there are additional validation requirements
> > that I am not checking.  For instance, the commonName of the
> > certificate is supposed to match the hostname of the server.  There
> > are lots of rules in this area and a careful perusal of the spec is
> > recommended.
> >
> > I think that adding the ability to generate and sign certificates
> > would be useful.  Of course we would need a Squeak root certificate
> > and private key to do so, unless we stick with self-signed certs.  If
> > we generate a root cert and publish the private key/password, that
> > would be little different than access to the swiki for upload - and
> > the same level of security.  YMMV.
> >
> > When I have a little time, I may look into client certificates.  This
> > will require testing with OpenSSL.  I'll keep you informed if I get
> > into it.
> >
> > Rob
> >
> > On Jan 24, 2007, at 6:49 AM, Ron Teitelbaum wrote:
> >
> > > Very cool Rob!
> > >
> > > I've been working with the code, testing on multiple machines and it's
> > > working well!  I haven't been focusing on the actual certificates,
> > > but will
> > > need to do so in a few months.  I'm hoping to be able to create client
> > > certificates automatically during installation and to be able to
> > > renew them
> > > periodically.  For all this to work I'll need to have client and
> > > server
> > > certificates working and validated plus a working CA.  I'm planning
> > > on using
> > > certificate extensions to handle service authorization.  I'm very
> > > pleased
> > > with the code and how well it responds.  I'll start working with
> > > the new
> > > code and let you know if I see any issues.
> > >
> > > Thank you for your work on this!!
> > >
> > > Ron
> > >
> > >
> > >> From: Robert Withers
> > >> Sent: Wednesday, January 24, 2007 12:29 AM
> > >>
> > >> All,
> > >>
> > >> I've been doing a little SSL coding, since it isn't a fully developed
> > >> project yet.  The most glaring omission has been the lack of
> > >> certificate chain processing and validation, thereby leaving a rather
> > >> large security hole in the implementation.  The code still doesn't
> > >> handle client certificates.
> > >>
> > >> I have added the capability for a certificate to verify itself with
> > >> it's parent certificate.  Roughly, this entails comparing the hash of
> > >> the certificate (tbsCertificate) with its decrypted signature. using
> > >> the parent certificate's publicKey.  The parent is identified as
> > >> having the same subject as the child's issuer.  A self-signed
> > >> certificate has the same issuer and subject.  These are currently
> > >> allowed.  Furthermore, the certificate is valid if the validity dates
> > >> enclose the current date.
> > >>
> > >> The code hook for all this is in
> > >> SSLSecurityCoordinator>>#validateCertificateChain: certChain
> > >>
> > >> The test certificate currently passes, but will expire later this
> > >> year.
> > >>
> > >> I also added the CACert, Verisign and Thawte's root CAs to the
> > >> SSLCertificateStore, but there is no mechanism to add external root
> > >> certs.
> > >>
> > >> I also coded and tested MD2 hash function, so that some certs can be
> > >> validated.
> > >>
> > >> Changes to the following packages:
> > >> 	Cryptography-ASN1
> > >> 	Cryptography-MD4
> > >> 	Cryptography-SSL
> > >> 	Cryptography-Tests
> > >> 	Cryptography-X509
> > >>
> > >> cheers,
> > >> Robert