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.
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". 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.
Rob
----- Original Message ---- From: Cerebus cerebus2@gmail.com To: Cryptography Team Development List cryptography@lists.squeakfoundation.org Sent: Thursday, January 25, 2007 12:52:22 PM Subject: Re: [Cryptography Team] Re: SSL Certificate Validation
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
Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
_______________________________________________ Cryptography mailing list Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
On 1/25/07, Rob Withers reefedjib@yahoo.com 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
Thanks for the clarifications, Tim. It makes much sense, now.
Robert
On Jan 26, 2007, at 4:50 PM, Cerebus wrote:
On 1/25/07, Rob Withers reefedjib@yahoo.com 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 Cryptography@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/ cryptography
cryptography@lists.squeakfoundation.org
-
Cerebus -
Rob Withers -
Robert Withers