« Return to Thread: SSL Certificate Validation
Re: Re: SSL Certificate Validation
by Rob Withers
::
Rate this Message:
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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.
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@...>
To: Cryptography Team Development List <cryptography@...>
Sent: Thursday, January 25, 2007 12:52:22 PM
Subject: Re: [Cryptography Team] Re: SSL Certificate Validation
From: Cerebus <cerebus2@...>
To: Cryptography Team Development List <cryptography@...>
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@...> 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@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>_______________________________________________
Cryptography mailing list
Cryptography@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
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@...> 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@...
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
>
Cryptography mailing list
Cryptography@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
_______________________________________________
Cryptography mailing list
Cryptography@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/cryptography
« Return to Thread: SSL Certificate Validation
| Free Forum Powered by Nabble | Forum Help |