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