Open Stack

All,

Allow me to point out that these issues have been well-studied in deployment of the X.509 infrastructure used for many years by grids.  The relevant document from OGF is GFD.125, presently in the process of finalizing its transition between being a long-standing community practice document to becoming a "proposed recommendation" (P-REC).

This document captures the hard-earned and well-established practices, based on the relevant IETF, ISO and ITU-T standards and references, that lead to good interoperability between certificate providers in a large-scale distributed computing setting.

The document may be found at: 

	http://ogf.org/documents/GFD.125.pdf

The revision to bring this into status as a proposed recommendation may be found in the working area of the Certificate Authority Operations (CAOPS) group at OGF:

	http://redmine.ogf.org/dmsf/caops-wg

This document will shortly go into public comment and opportunity for community input into its contents as it makes this transition will exist.  Meanwhile, it provides good guidance into issues exactly like this and should save you a lot of time, if applied, in avoiding interoperability problems.

Hope this helps!

Alan Sill
Vice President of Standards, Open Grid Forum



On Oct 30, 2012, at 11:25 AM, "Clark, Robert Graham" <robert.clark at hp.com>
 wrote:

> Nate,
> 
> It absolutely makes a bunch of sense to standardise on something but understanding what and why will be tricky. I'm hoping that the SSL Review will inform the decision somewhat.
> 
> -Rob
> 
> Robert,
> 
> Yeah, I've noticed similar issues with subjectAltNames in the past. For keystone, which uses python-httplib2, it currently only works with subjectAltNames if you have the CN repeated otherwise it only thinks the names in the subjectAltNames are the valid hostnames and doesn't even use the CN. I would call that a bug in httplib2. I also don't think httplib2 currently works when IPs are used in the subjectAltName because it only looks at ones with 'DNS' tagged names.
> 
> Separate but related, would it be worthwhile making all the clients standardize on a particular SSL http library? Some use python-httplib, python-httplib2, etc...
> 
> Nate
> 
> On Oct 30, 2012 11:47 AM, "Clark, Robert Graham" <robert.clark at hp.com<mailto:robert.clark at hp.com>> wrote:
> Hi Nate,
> 
> In this context yes, when I (or my esteemed colleague Stuart) mention
> CNAME we actually mean the x509 Common Name otherwise referred to as CN.
> 
> You make a good point around subjectAlternativeNames, whenever a
> certificate is presented we should check against the CN and the SANs, if
> the certificate has SANs.
> 
> There's often confusion as to wether the stated CN of a certificate should
> appear in the SANs, this often gets people confused so to get ahead of
> that, here's what RFC 5280 Section 4.1.2.6 has to say:
> 
> """
> The subject field identifies the entity associated with the public key
> stored in the subject public key field. The subject name MAY be carried in
> the subject field and/or the subjectAltName extension.However, there are
> some compatibility issues with some TLS implementations, LDAP appears to
> require the Common Name to be repeated in the SAN.
> """
> 
> I'm going to add this into the 'standard' grade of SSL, below.
> 
> 
> 
>> I presume with your usage of the term CNAME you actually mean the x509
>> 'common name' or 'CN', not DNS canonical names(CNAMEs)? That does bring
>> up the point that we should verify all clients/servers work correctly
>> with certificates using subjectAltNames.
>> Nate
>> On Oct 30, 2012 6:05 AM, <stuart.mclaren at hp.com<mailto:stuart.mclaren at hp.com>> wrote:
>> 
>> Hi Rob,
>> 
>> For python-glanceclient, which is now using pyopenssl, we are checking
>> the server cert, but probably need to also add the 'CNAME is valid for
>> the server' check -- I'd be interested if you could confirm this.
>> 
>> If so, would adding something like 'match_hostname' from:
>> 
>> http://svn.python.org/projects/python/branches/pep-0384/Lib/ssl.py
>> 
>> into the 'verify_callback' function be appropriate?
>> 
>> Also, will openssl check that the certificate is in date by default, or
>> should an explicit check for this also be added to the 'verify_callback'?
>> 
>> Thanks,
>> 
>> -Stuart
>> 
>> Date: Tue, 30 Oct 2012 08:31:07 +0000
>> From: "Clark, Robert Graham" <robert.clark at hp.com<mailto:robert.clark at hp.com>>
>> To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
>> Subject: [openstack-dev] [OSSG] SSL Review
>> Message-ID: <CCB540CA.E6B5%robert.clark at hp.com<mailto:CCB540CA.E6B5%25robert.clark at hp.com>
>> <mailto:CCB540CA.E6B5%25robert.clark at hp.com<mailto:CCB540CA.E6B5%2525robert.clark at hp.com>>>
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> All,
>> 
>> During the summit Bryan highlighted the poor SSL implementations being
>> used in various OpenStack clients, with some doing no verification at all.
>> 
>> Sadly the state of OpenStack internally (where SSL can be enabled) is
>> often little better. I'm going to start a body of work to navigate through
>> the code and check exactly what is (or isn't) enabled for each SSL
>> interface on offer.
>> 
>> I'm planning on checking the ability to execute a wide range of controls
>> because we want this 'enhanced' level of security on some particular
>> interfaces.
>> 
>> (For each interface)
>> Fundamental:
>>       * Certificate provided is signed by a CA that the client
>> recognises as a
>> valid trust anchor
>>       * Certificate is in-date
>>       * No support for known-poor algorithms
>>       * Service offering SSL cannot be forced into plaintext
>>       * SSLv3 TLSv1 Minimum
>> 
>> Standard:
>>       * Revocation information is checked (CRL/OCSP)
>>       * CN is valid for the server
>          * SANs checked for valid match
>> 
>> Enhanced:
>>       * Support only for strongest available algorithms
>>       * X.509v3 Extended Key Usage flags OID verified
>>       * Client Certificates have Role-Specific CNAME and verification is
>> supported
>> 
>> Please comment or add things to the list, also if you've already done some
>> similar work please drop me a line so I can include your results.
>> 
>> Finally, if you want to help do some of this please feel free!
>> 
>> -Rob
>> 
>> 
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> 
>> 
>> 
>> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev