SSL Certificate Validation

> 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
>

> 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
>>
>
>

> 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
> >>
> >
> >
>
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>

> 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 <[hidden email]> 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

> On 1/25/07, Ron Teitelbaum <[hidden email]> wrote:
>
> > 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?
>
> For a limited application--say, joining a WLAN--or a severely limited
> but broadly available level of access--like getting to the front page
> of a private web server--then mere possession of a certificate can be
> sufficient authorization.  Anything beyond that and you want a
> separation between authN and authZ.
>
> In your case, if your user populations interact a lot then there's a
> good case for having a single identity management system binding them
> all together as a community.  Practically, this means a single PKI, or
> at least a group of cross-certified PKIs (how ever, cross
> certification has its own problem; path construction is a real PITA to
> do right all the time in a cross-cert environment, and then there's
> the whole namespace issue...).
>
> So the cert provides identity proof, as it should.  Once you know
> *who* the entity is, you need to define *what* the entity can do.
> Simply put, the problem is this: authN is forever, but authZ is
> temporary.  An entity's access rights can change at any time, for any
> reason, from being fired to being promoted.  If that data is bound
> *in* the cert, then you will have to revoke the cert whenever access
> rights change.
>
> Revocation is *bad*; it grows the CRL.  CRL growth causes problems.
>
> The DoD PKI CRLs are over 140MB in the aggregate, and growing at a
> prodigious rate--and that's only from the administrative revocations
> (lost smartcards, name changes, rank changes, and affiliation changes
> mostly).  If we had bound up access rights in the cert, the CRLs would
> be terabytes in size.
>
> > 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.
>
> The separation of authN and authZ is one of the basic tenets of
> information assurance, right up there with the Principle of Least
> Privilege.
>
> Start from base principles:  Identify the communities and define how
> they interact.
>
> If you're seriously building a PKI for your company I might be able to
> set you up with business contacts with people who've done this for a
> living.  Let me know off-list.
>
> -- Tim
>

> On 1/25/07, Rob Withers <[hidden email]> wrote:
>
>> I am not currently parsing the certificate extensions, and  
>> discussion of the
>> commonName vs the subjectAltName has always confused me.  This  
>> would be
>> something that could be worked on with X509.
>
> Back when X.500 defined distinguished names, there wasn't a lot of
> thought about non-people being named in this way.  X.509 adopted the
> X.500 naming scheme, but applied to people, services, devices, etc.
> Various kludges were added to DN to accommodate different protocol
> naming needs.
>
> Eventually a light dawned and the subjectAltName extension was
> defined.  The protocol specific names go in there (predefined types
> like rfc822Name, iPaddress, dNSName, etc.), leaving the subject DN for
> a human-readable names.
>
> Also, subject DN is allowed to be empty, in which case the names
> *have* to be in subjectAltName.  :)
>
>> I don't understand what you mean when you say "it's bad practice  
>> to put
>> authorization data into an
>> authentication instrument like a certificate".
>
> Mostly that was aimed at Ron but I was at the airport posting from my
> N800 so I was being lazy.
>
>> I would think that once a
>> certificate is authenticated, then it's identity (commonName or
>> subjectAltName) could be used for authorization.  At least the SSL  
>> spec
>> speaks about it working this way.
>
> Correct.  However, the authZ decision should be made local to the
> service, *not* by the certificate issuer.  IOW, the certificate or
> public key is your index into a local authorization database, and it's
> the information in that database that determines the cert holder's
> access rights.
>
> -- Tim
> _______________________________________________
> Cryptography mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ 
> cryptography