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