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
>
>
