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

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

Think about it this way: If I show you my driver's license, would you give me the key to your house? Probably not; I don't belong in there. But *you* make the decision of who gets the key to your house, not the state that issued the license.

-- Tim

On 1/26/07, Cerebus cerebus2@gmail.com wrote:

On 1/25/07, Ron Teitelbaum Ron@usmedrec.com 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