Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
johansen at sun.com wrote: [Originally sent this to Darren, but forgot to CC PSARC-ext] I didn't get that email. Hi Darren, I got forwarded a pointer to this case that you filed. Thanks for taking the time to do this. http://sac.eng/Archives/CaseLog/arc/PSARC/2009/430/20090811_darren.moffat I would recommend using the certificate directory approach instead of creating a single file with all certificates. This case doesn't preclude that. The directory allows us to use a single PEM file per-certificate instead of having a huge PEM blob. The single PEM file consumes more memory, since the whole blob gets loaded into memory. If the directory is used, individual keys are loaded into memory instead. It is only 198k Delivering a single blob also has implications for package delivery. If we use a directory, other packages can deliver certs to a common location, if needed. The blob approach blocks multiple party certificate delivery, and requires us to update the entire blob when one certificate changes. It would be more elegant to add/remove the affected files from a certficiate directory. This case doesn't preclude other packages adding additional certs to /etc/certs/ in fact other packages already do. This case is about delivering the well known browser SSL certs and as such I think it is entirely appropriate to do so in a single file. I believer other systems do it that way. Since I had to solve this problem for pkg(5), I've already written code that can extract the certs from mozilla's nss library, or their CVS server, and then build a directory of certs with corresponding hash-value named symlinks. Feel free to use this code instead of writing more from scratch. One reason for using a single file is to avoid having to do the hash-value symlinks. This case is already closed and ready to be delivered, unless you think it is fundamentally broken I really don't want to re-open it. -- Darren J Moffat
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
On Fri, Aug 14, 2009 at 09:24:00AM +0100, Darren J Moffat wrote: johansen at sun.com wrote: http://sac.eng/Archives/CaseLog/arc/PSARC/2009/430/20090811_darren.moffat I would recommend using the certificate directory approach instead of creating a single file with all certificates. This case doesn't preclude that. It may. There are still bugs in OpenSSL's certificate lookup mechanisms that make it difficult to use both a CertificateFile and a CertificateDirectory together: Although the issuer checks are a considerably improvement over the old technique they still suffer from limitations in the underlying X509_LOOKUP API. One consequence of this is that trusted certificates with matching subject name must either appear in a file (as specified by the -CAfile option) or a directory (as specified by -CApath. If they occur in both then only the certificates in the file will be recognised. Previous versions of OpenSSL assume certificates with matching subject name are identical and mishandled them. (http://www.openssl.org/docs/apps/verify.html#BUGS) As another example, Libcurl allows callers to use either the CAFile or the CADirectory approach, but not both. (Although, the documentation makes no mention of this.) The directory allows us to use a single PEM file per-certificate instead of having a huge PEM blob. The single PEM file consumes more memory, since the whole blob gets loaded into memory. If the directory is used, individual keys are loaded into memory instead. It is only 198k The individual certficiates are between 1 and 2k. If an application only needs one or two of those certificates you're wasting 98-99% of that memory. Delivering a single blob also has implications for package delivery. If we use a directory, other packages can deliver certs to a common location, if needed. The blob approach blocks multiple party certificate delivery, and requires us to update the entire blob when one certificate changes. It would be more elegant to add/remove the affected files from a certficiate directory. This case doesn't preclude other packages adding additional certs to /etc/certs/ in fact other packages already do. I don't believe that this response addresses my previous comment. OpenSolaris should be moving towards configuration systems that are self assembling. Delivering well-known certificates into a directory facilitates this kind of self assembly. The directory approach can be used by OpenSSL without need for any assembly service, as long as symlinks are delivered with the certificates. You also haven't addressed the issue of handling individual certificates. The blob approach requires us to deliver a large file every time any of the constituent pieces change. It seems more reasonable to deliver just the pieces that have changed. This case is about delivering the well known browser SSL certs ... I understand that. I'm asking that we do so in such a way that we have maximum flexibility and minimal overhead. I think it is entirely appropriate to do so in a single file. I believer other systems do it that way. I disagree, and I've explained why I think there is a better approach. I don't believe it matters what other systems do, at least in this case. Since I had to solve this problem for pkg(5), I've already written code that can extract the certs from mozilla's nss library, or their CVS server, and then build a directory of certs with corresponding hash-value named symlinks. Feel free to use this code instead of writing more from scratch. One reason for using a single file is to avoid having to do the hash-value symlinks. This isn't a difficult problem, and I have code that already does this. You're welcome to use / borrow / whatever, if you like. This case is already closed and ready to be delivered, unless you think it is fundamentally broken I really don't want to re-open it. I wouldn't have sent these comments unless I thought that they were important. How many posts have I made to PSARC-ext in the last few years? Using a directory based approach may be a little more effort in the short term, but it should save us a lot of headache later on. Thanks, -j
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
johansen at sun.com wrote: On Fri, Aug 14, 2009 at 09:24:00AM +0100, Darren J Moffat wrote: johansen at sun.com wrote: http://sac.eng/Archives/CaseLog/arc/PSARC/2009/430/20090811_darren.moffat I would recommend using the certificate directory approach instead of creating a single file with all certificates. This case doesn't preclude that. It may. There are still bugs in OpenSSL's certificate lookup mechanisms that make it difficult to use both a CertificateFile and a CertificateDirectory together: I wasn't aware of that issue. Given that and the fact that separate files would help self assembly and have things consistent (ie always on cert per file) - I'll re-open this case and post a new spec on Monday morning UK time. -- Darren J Moffat
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
[Originally sent this to Darren, but forgot to CC PSARC-ext] Hi Darren, I got forwarded a pointer to this case that you filed. Thanks for taking the time to do this. http://sac.eng/Archives/CaseLog/arc/PSARC/2009/430/20090811_darren.moffat I would recommend using the certificate directory approach instead of creating a single file with all certificates. The directory allows us to use a single PEM file per-certificate instead of having a huge PEM blob. The single PEM file consumes more memory, since the whole blob gets loaded into memory. If the directory is used, individual keys are loaded into memory instead. Delivering a single blob also has implications for package delivery. If we use a directory, other packages can deliver certs to a common location, if needed. The blob approach blocks multiple party certificate delivery, and requires us to update the entire blob when one certificate changes. It would be more elegant to add/remove the affected files from a certficiate directory. Since I had to solve this problem for pkg(5), I've already written code that can extract the certs from mozilla's nss library, or their CVS server, and then build a directory of certs with corresponding hash-value named symlinks. Feel free to use this code instead of writing more from scratch. Thanks, -j
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Default system CA (X.509) Certificates 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 11 August, 2009 4. Technical Description Background -- OpenSolaris does not currently ship a set of X.509 CA certs in a format suitable for use by OpenSSL consumers. This was a concious decision made when the Cryptographic Framework and Key Management Framework projects were initially designed. The intent was that we the OS vendor shouldn't tell you who to trust. There are/were also political issues on choosing which certificates appear in the list of CA certs. OpenSSL previously included a set of CA files in PEM format. Solaris has never included those and the upstream OpenSSL community no longer provides them. However this has a significant usability impacts on several existing and future components including (but not limited to): wget(1), curl(1), openssl(1), pkg(5), neon(3), WebKit OpenSolaris/Solaris need to deliver a set of CA certs in PEM format in a system wide location for use by those applications. These applications do not need to be changed to use this as it is an API option or CLI option to use a CA cert bundle, eg: $ openssl s_client -CAfile /etc/certs/cacert.pem -connect www.sun.com:443 $ curl --cacert /etc/certs/cacert.pem https://www.sun.com Proposal The Mozilla NSS libraries, as used by Firefox/Thunderbird, include a useful set of CA certs for the main public CAs. However this is in the form of objects in a PKCS#11 library (/usr/lib/mps/$ISA/libnssckbi.so) and isn't suitable for use by OpenSSL consumers. The Java runtime also includes a set of CA certs. There are various methods for extracting the list of CA certs out of the Mozilla NSS libraries. An appropriate method will be chosen, but is considered an implementation detail. The result will be a single PEM format file that is installed as: /etc/certs/cacert.pem Note that the /etc/certs directory already exists and is a delivered component of Solaris (via SUNWcsr). The intent is to deliver the cacert.pem file from the ON consolidation, mainly because the existing content of /etc/certs is delivered from there. It will be delivered from a new package SUNWcacerts. Exported Interfaces +-+ | package name SUNWcacerts| Volatile | | location of the cacert.pem file | Committed | | format of the cacert.pem file | Committed | | CAs in the cacert.pem file is Volatile | Volatile | +-+ It is expected that the SUNWcacerts package be included on the system by default. The current size of the cacert.pem file is 198K. Alternate Proposal -- The following alternate proposal was considered and it or something like it may be delivered in the future. If that happens a case will be run to define the architecture A new SMF service svc://network/security/cacerts is introduced, this service would responsible for updating the /etc/certs/cacert.pem file. Related Cases - LSARC/2001/373 Delivery of the Sun Certificates 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
Putting all the certs in one mondo file gives me a few minor concerns, which might be insignificant, but I want to ask them anyway: 1) Do end users have any control over which CAs they do or do not trust? (What if they want all of the CAs except one?) 2) How are CRL handled? 3) How will updates to the cacert file be handled? I'd like to see a sentence or two responding to each of those points, please. - Garrett Darren J Moffat wrote: Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Default system CA (X.509) Certificates 1.2. Name of Document Author/Supplier: Author: Darren Moffat 1.3 Date of This Document: 11 August, 2009 4. Technical Description Background -- OpenSolaris does not currently ship a set of X.509 CA certs in a format suitable for use by OpenSSL consumers. This was a concious decision made when the Cryptographic Framework and Key Management Framework projects were initially designed. The intent was that we the OS vendor shouldn't tell you who to trust. There are/were also political issues on choosing which certificates appear in the list of CA certs. OpenSSL previously included a set of CA files in PEM format. Solaris has never included those and the upstream OpenSSL community no longer provides them. However this has a significant usability impacts on several existing and future components including (but not limited to): wget(1), curl(1), openssl(1), pkg(5), neon(3), WebKit OpenSolaris/Solaris need to deliver a set of CA certs in PEM format in a system wide location for use by those applications. These applications do not need to be changed to use this as it is an API option or CLI option to use a CA cert bundle, eg: $ openssl s_client -CAfile /etc/certs/cacert.pem -connect www.sun.com:443 $ curl --cacert /etc/certs/cacert.pem https://www.sun.com Proposal The Mozilla NSS libraries, as used by Firefox/Thunderbird, include a useful set of CA certs for the main public CAs. However this is in the form of objects in a PKCS#11 library (/usr/lib/mps/$ISA/libnssckbi.so) and isn't suitable for use by OpenSSL consumers. The Java runtime also includes a set of CA certs. There are various methods for extracting the list of CA certs out of the Mozilla NSS libraries. An appropriate method will be chosen, but is considered an implementation detail. The result will be a single PEM format file that is installed as: /etc/certs/cacert.pem Note that the /etc/certs directory already exists and is a delivered component of Solaris (via SUNWcsr). The intent is to deliver the cacert.pem file from the ON consolidation, mainly because the existing content of /etc/certs is delivered from there. It will be delivered from a new package SUNWcacerts. Exported Interfaces +-+ | package name SUNWcacerts| Volatile | | location of the cacert.pem file | Committed | | format of the cacert.pem file | Committed | | CAs in the cacert.pem file is Volatile | Volatile | +-+ It is expected that the SUNWcacerts package be included on the system by default. The current size of the cacert.pem file is 198K. Alternate Proposal -- The following alternate proposal was considered and it or something like it may be delivered in the future. If that happens a case will be run to define the architecture A new SMF service svc://network/security/cacerts is introduced, this service would responsible for updating the /etc/certs/cacert.pem file. Related Cases - LSARC/2001/373 Delivery of the Sun Certificates 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
Garrett D'Amore wrote: Putting all the certs in one mondo file gives me a few minor concerns, which might be insignificant, but I want to ask them anyway: 1) Do end users have any control over which CAs they do or do not trust? (What if they want all of the CAs except one?) The end user using the command/tool can point to a separate CA file. All of the tools I know about can take a single file not all of them appear to be able to take a directory of PEM files. 2) How are CRL handled? If there is an issue with needing to expire any of these root CAs then the way to deal with that is to redeliver the cacert file not to use a CRL. CRLs are for a specific CA and it is their responsibility to manage those - note that some of them are huge, OCSP is the recommended way of checking certificate revocation. 3) How will updates to the cacert file be handled? By delivering a new version of the SUNWcacert package containing a new cacert.pem file. The method used to get the new version of the cacert.pem file is an implementation detail but it will be done using the extraction method from the Mozilla NSS files. -- Darren J Moffat
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
Darren J Moffat wrote: Garrett D'Amore wrote: Putting all the certs in one mondo file gives me a few minor concerns, which might be insignificant, but I want to ask them anyway: 1) Do end users have any control over which CAs they do or do not trust? (What if they want all of the CAs except one?) The end user using the command/tool can point to a separate CA file. All of the tools I know about can take a single file not all of them appear to be able to take a directory of PEM files. Ah, that explains this choice. Is there a way (relatively easy for customers) to extract a single Cert from the PEM file? (Some tool? Or is the file in some ASCII encoding such that it can just manually be extracted with an editor?) 2) How are CRL handled? If there is an issue with needing to expire any of these root CAs then the way to deal with that is to redeliver the cacert file not to use a CRL. CRLs are for a specific CA and it is their responsibility to manage those - note that some of them are huge, OCSP is the recommended way of checking certificate revocation. So the tools are responsible for making this check themselves, using OCSP, right? That makes sense -- end users don't have to take any specific action to get the CRL checking. 3) How will updates to the cacert file be handled? By delivering a new version of the SUNWcacert package containing a new cacert.pem file. The method used to get the new version of the cacert.pem file is an implementation detail but it will be done using the extraction method from the Mozilla NSS files. Okay, thanks for the clarifications. With that, +1 - Garrett
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
Garrett D'Amore wrote: Darren J Moffat wrote: Garrett D'Amore wrote: Putting all the certs in one mondo file gives me a few minor concerns, which might be insignificant, but I want to ask them anyway: 1) Do end users have any control over which CAs they do or do not trust? (What if they want all of the CAs except one?) The end user using the command/tool can point to a separate CA file. All of the tools I know about can take a single file not all of them appear to be able to take a directory of PEM files. Ah, that explains this choice. Is there a way (relatively easy for customers) to extract a single Cert from the PEM file? (Some tool? Or is the file in some ASCII encoding such that it can just manually be extracted with an editor?) PEM is an ASCII encoding the certs them selfs are bounded by: -BEGIN CERTIFICATE- -END CERTIFICATE- 2) How are CRL handled? If there is an issue with needing to expire any of these root CAs then the way to deal with that is to redeliver the cacert file not to use a CRL. CRLs are for a specific CA and it is their responsibility to manage those - note that some of them are huge, OCSP is the recommended way of checking certificate revocation. So the tools are responsible for making this check themselves, using OCSP, right? That makes sense -- end users don't have to take any specific action to get the CRL checking. In general they may use OCSP but not on the CA certs files only on the SSL server certs they receive as part of the SSL protocol. The hole point of the CA certs is the buck stops here. -- Darren J Moffat
Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009]
Darren J Moffat wrote: So the tools are responsible for making this check themselves, using OCSP, right? That makes sense -- end users don't have to take any specific action to get the CRL checking. In general they may use OCSP but not on the CA certs files only on the SSL server certs they receive as part of the SSL protocol. The hole point of the CA certs is the buck stops here. Ok, thanks again for the clarifications. - Garrett
