From darrenm@sac.sfbay.sun.com Tue Aug 11 08:53:15 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BFrF7f012712; Tue, 11 Aug 2009 08:53:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BFrFK1013531; Tue, 11 Aug 2009 08:53:15 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO70030LYSP2M00@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 09:53:13 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO7009PAYSOKBD0@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 09:53:12 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7BFrCKV062600; Tue, 11 Aug 2009 08:53:12 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BFrAGG012707; Tue, 11 Aug 2009 08:53:10 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n7BFrATc012703; Tue, 11 Aug 2009 08:53:10 -0700 (PDT) Date: Tue, 11 Aug 2009 08:53:10 -0700 (PDT) From: Darren J Moffat Subject: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] To: PSARC-ext@sun.com Cc: LSARC-ext@sun.com Message-id: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3576 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 From darrenm@sac.sfbay.sun.com Tue Aug 11 08:53:15 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BFrF7f012712; Tue, 11 Aug 2009 08:53:15 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BFrFK1013531; Tue, 11 Aug 2009 08:53:15 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO70030LYSP2M00@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 09:53:13 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO7009PAYSOKBD0@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 09:53:12 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7BFrCKV062600; Tue, 11 Aug 2009 08:53:12 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BFrAGG012707; Tue, 11 Aug 2009 08:53:10 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n7BFrATc012703; Tue, 11 Aug 2009 08:53:10 -0700 (PDT) Date: Tue, 11 Aug 2009 08:53:10 -0700 (PDT) From: Darren J Moffat Subject: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] To: PSARC-ext@sun.com Cc: LSARC-ext@sun.com Message-id: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3576 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 From gdamore@sun.com Tue Aug 11 09:02:10 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BG2Avc013403; Tue, 11 Aug 2009 09:02:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BG27V5024935; Tue, 11 Aug 2009 09:02:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO700D09Z7L3Y00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:02:09 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO70009PZ7K15E0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:02:08 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BG28lw017429; Tue, 11 Aug 2009 09:02:08 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO700900YX6IM00@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 09:02:08 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO700KF5Z7CMJE0@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 09:02:01 -0700 (PDT) Date: Tue, 11 Aug 2009 09:02:00 -0700 From: "Garrett D'Amore" Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com, LSARC-ext@sun.com Message-id: <4A8195F8.80004@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4200 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 > > From gdamore@sun.com Tue Aug 11 09:02:10 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BG2Avc013403; Tue, 11 Aug 2009 09:02:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BG27V5024935; Tue, 11 Aug 2009 09:02:10 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO700D09Z7L3Y00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:02:09 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO70009PZ7K15E0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:02:08 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BG28lw017429; Tue, 11 Aug 2009 09:02:08 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO700900YX6IM00@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 09:02:08 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO700KF5Z7CMJE0@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 09:02:01 -0700 (PDT) Date: Tue, 11 Aug 2009 09:02:00 -0700 From: "Garrett D'Amore" Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: PSARC-ext@sun.com, LSARC-ext@sun.com Message-id: <4A8195F8.80004@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4200 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 > > From Darren.Moffat@sun.com Tue Aug 11 09:15:49 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BGFmnd013512; Tue, 11 Aug 2009 09:15:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BGFljW036478; Tue, 11 Aug 2009 10:15:48 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO700E13ZUAQ700@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:15:46 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO700ESWZU9BL00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:15:45 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BGFhow004630; Tue, 11 Aug 2009 16:15:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO700200ZEY4Y00@fe-emea-09.sun.com>; Tue, 11 Aug 2009 17:15:28 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO700JOQZTSBQB0@fe-emea-09.sun.com>; Tue, 11 Aug 2009 17:15:28 +0100 (BST) Date: Tue, 11 Aug 2009 17:15:20 +0100 From: Darren J Moffat Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A8195F8.80004@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com, LSARC-ext@sun.com Message-id: <4A819918.5060108@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> <4A8195F8.80004@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1169 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 From Darren.Moffat@sun.com Tue Aug 11 09:15:49 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BGFmnd013512; Tue, 11 Aug 2009 09:15:48 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BGFljW036478; Tue, 11 Aug 2009 10:15:48 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO700E13ZUAQ700@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:15:46 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO700ESWZU9BL00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:15:45 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BGFhow004630; Tue, 11 Aug 2009 16:15:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO700200ZEY4Y00@fe-emea-09.sun.com>; Tue, 11 Aug 2009 17:15:28 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO700JOQZTSBQB0@fe-emea-09.sun.com>; Tue, 11 Aug 2009 17:15:28 +0100 (BST) Date: Tue, 11 Aug 2009 17:15:20 +0100 From: Darren J Moffat Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A8195F8.80004@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com, LSARC-ext@sun.com Message-id: <4A819918.5060108@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> <4A8195F8.80004@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1169 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 From gdamore@sun.com Tue Aug 11 09:52:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BGqpNm014417; Tue, 11 Aug 2009 09:52:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7BGqk0V008850; Tue, 11 Aug 2009 17:52:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800J0R1K14R00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:52:49 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800EYR1K0BB40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:52:48 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BGqmc6016860; Tue, 11 Aug 2009 09:52:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800100112HK00@fe-sfbay-09.sun.com>; Tue, 11 Aug 2009 09:52:48 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO8003JY1JTLQ30@fe-sfbay-09.sun.com>; Tue, 11 Aug 2009 09:52:42 -0700 (PDT) Date: Tue, 11 Aug 2009 09:52:41 -0700 From: "Garrett D'Amore" Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A819918.5060108@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Darren J Moffat , PSARC-ext@sun.com, lsarc-ext@sun.com Message-id: <4A81A1D9.1020204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> <4A8195F8.80004@sun.com> <4A819918.5060108@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1702 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 From gdamore@sun.com Tue Aug 11 09:52:52 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BGqpNm014417; Tue, 11 Aug 2009 09:52:51 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7BGqk0V008850; Tue, 11 Aug 2009 17:52:50 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800J0R1K14R00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:52:49 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800EYR1K0BB40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 11 Aug 2009 09:52:48 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BGqmc6016860; Tue, 11 Aug 2009 09:52:48 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800100112HK00@fe-sfbay-09.sun.com>; Tue, 11 Aug 2009 09:52:48 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO8003JY1JTLQ30@fe-sfbay-09.sun.com>; Tue, 11 Aug 2009 09:52:42 -0700 (PDT) Date: Tue, 11 Aug 2009 09:52:41 -0700 From: "Garrett D'Amore" Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A819918.5060108@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Darren J Moffat , PSARC-ext@sun.com, lsarc-ext@sun.com Message-id: <4A81A1D9.1020204@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> <4A8195F8.80004@sun.com> <4A819918.5060108@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1702 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 From Darren.Moffat@sun.com Tue Aug 11 10:01:34 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BH1YhG014972; Tue, 11 Aug 2009 10:01:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BH1WmS000244; Tue, 11 Aug 2009 11:01:33 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO80092B1YKWA00@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 11:01:32 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO8004P81YGIA70@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 11:01:29 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BH1SMc008454; Tue, 11 Aug 2009 17:01:28 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800L001OMDM00@fe-emea-10.sun.com>; Tue, 11 Aug 2009 18:01:07 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO800F2W1XSXHC0@fe-emea-10.sun.com>; Tue, 11 Aug 2009 18:01:05 +0100 (BST) Date: Tue, 11 Aug 2009 18:00:56 +0100 From: Darren J Moffat Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A81A1D9.1020204@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com, lsarc-ext@sun.com Message-id: <4A81A3C8.1000608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> <4A8195F8.80004@sun.com> <4A819918.5060108@Sun.COM> <4A81A1D9.1020204@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1694 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 From Darren.Moffat@sun.com Tue Aug 11 10:01:34 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BH1YhG014972; Tue, 11 Aug 2009 10:01:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BH1WmS000244; Tue, 11 Aug 2009 11:01:33 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO80092B1YKWA00@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 11:01:32 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO8004P81YGIA70@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 11:01:29 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BH1SMc008454; Tue, 11 Aug 2009 17:01:28 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800L001OMDM00@fe-emea-10.sun.com>; Tue, 11 Aug 2009 18:01:07 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO800F2W1XSXHC0@fe-emea-10.sun.com>; Tue, 11 Aug 2009 18:01:05 +0100 (BST) Date: Tue, 11 Aug 2009 18:00:56 +0100 From: Darren J Moffat Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A81A1D9.1020204@sun.com> Sender: Darren.Moffat@sun.com To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com, lsarc-ext@sun.com Message-id: <4A81A3C8.1000608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> <4A8195F8.80004@sun.com> <4A819918.5060108@Sun.COM> <4A81A1D9.1020204@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1694 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 From gdamore@sun.com Tue Aug 11 10:26:05 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BHQ5Nh016151; Tue, 11 Aug 2009 10:26:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BHQ4DJ002523; Tue, 11 Aug 2009 10:26:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO80011B33GOW00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Aug 2009 10:26:04 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800JEZ33FHF70@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Aug 2009 10:26:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BHQ3xe027890; Tue, 11 Aug 2009 10:26:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO8004002V6JY00@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 10:26:03 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO800FH833ESXC0@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 10:26:03 -0700 (PDT) Date: Tue, 11 Aug 2009 10:26:02 -0700 From: "Garrett D'Amore" Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A81A3C8.1000608@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Darren J Moffat , PSARC-ext@sun.com, lsarc-ext@sun.com Message-id: <4A81A9AA.90706@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> <4A8195F8.80004@sun.com> <4A819918.5060108@Sun.COM> <4A81A1D9.1020204@sun.com> <4A81A3C8.1000608@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 471 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 From gdamore@sun.com Tue Aug 11 10:26:05 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BHQ5Nh016151; Tue, 11 Aug 2009 10:26:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BHQ4DJ002523; Tue, 11 Aug 2009 10:26:05 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO80011B33GOW00@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Aug 2009 10:26:04 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800JEZ33FHF70@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Aug 2009 10:26:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BHQ3xe027890; Tue, 11 Aug 2009 10:26:03 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO8004002V6JY00@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 10:26:03 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO800FH833ESXC0@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 10:26:03 -0700 (PDT) Date: Tue, 11 Aug 2009 10:26:02 -0700 From: "Garrett D'Amore" Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A81A3C8.1000608@Sun.COM> Sender: Garrett.Damore@sun.com To: Darren J Moffat Cc: Darren J Moffat , PSARC-ext@sun.com, lsarc-ext@sun.com Message-id: <4A81A9AA.90706@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908111553.n7BFrATc012703@sac.sfbay.sun.com> <4A8195F8.80004@sun.com> <4A819918.5060108@Sun.COM> <4A81A1D9.1020204@sun.com> <4A81A3C8.1000608@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 471 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 From Darren.Moffat@sun.com Thu Aug 13 00:47:29 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7D7lTMx016307 for ; Thu, 13 Aug 2009 00:47:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7D7lQVc018325 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 13 Aug 2009 15:47:28 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0080J1N1BP00@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.com); Thu, 13 Aug 2009 01:47:25 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB003DX1N0ZXC0@brm-avmta-1.central.sun.com> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@Sun.com); Thu, 13 Aug 2009 01:47:25 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7D7lOEW004416 for ; Thu, 13 Aug 2009 07:47:24 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOB0080014EXN00@fe-emea-10.sun.com> for PSARC-EXT@Sun.com (ORCPT PSARC-EXT@Sun.com); Thu, 13 Aug 2009 08:47:17 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOB00HVM1LWHC00@fe-emea-10.sun.com> for PSARC-EXT@Sun.com (ORCPT PSARC-EXT@Sun.com); Thu, 13 Aug 2009 08:46:44 +0100 (BST) Date: Thu, 13 Aug 2009 08:46:35 +0100 From: Darren J Moffat Subject: PSARC/2009/430 Default system CA (X.509) Certificates Sender: Darren.Moffat@sun.com To: PSARC-EXT@sun.com Message-id: <4A83C4DB.6020502@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 79 This case was approved in PSARC on Wednesday 12th August. -- Darren J Moffat From johansen@sun.com Thu Aug 13 17:08:28 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E08ROn022644 for ; Thu, 13 Aug 2009 17:08:27 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7E08N6g019926 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Aug 2009 08:08:26 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00N01B215300@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Aug 2009 17:08:25 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC006M1B21P860@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 13 Aug 2009 17:08:25 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7E08P6m988096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Aug 2009 17:08:25 -0700 (PDT) Received: (from johansen@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n7E08PXE988082 for PSARC-ext@sun.com; Thu, 13 Aug 2009 17:08:25 -0700 (PDT) Date: Thu, 13 Aug 2009 17:08:24 -0700 From: johansen@sun.com Subject: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] To: PSARC-ext@sun.com Message-id: <20090814000824.GL727117@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Authentication-warning: jurassic-x4600.sfbay.sun.com: johansen set sender to johansen@sun.com using -f User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 1323 [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 From Alfred.Peng@sun.com Thu Aug 13 23:28:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E6Sbhi002680 for ; Thu, 13 Aug 2009 23:28:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7E6SYj0029517 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Aug 2009 07:28:37 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00E03SNN0J00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 00:28:35 -0600 (MDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC009YLSNMD210@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 00:28:35 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7E6SXBs018534 for ; Fri, 14 Aug 2009 06:28:33 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOC00900SDMVB00@mail-apac.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 14:28:33 +0800 (SGT) Received: from [192.168.1.71] ([unknown] [121.6.32.168]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOC00E39SNL4MH0@mail-apac.sun.com>; Fri, 14 Aug 2009 14:28:33 +0800 (SGT) Date: Fri, 14 Aug 2009 14:28:41 +0800 From: Alfred Peng Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <20090814000824.GL727117@eng.sun.com> Sender: Alfred.Peng@sun.com To: johansen@sun.com Cc: PSARC-ext@sun.com Message-id: <4A850419.6030406@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20090814000824.GL727117@eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090721 Lightning/1.0pre Thunderbird/3.0b3 Status: RO Content-Length: 1723 On 08/14/09 08:08 AM, johansen@sun.com wrote: > [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. > I think one use case is to match all the certificates with the server's certificate, in the case of https connection for example. Just curious: would it be more efficient to read the certificates from one single file than from a directory containing individual keys? Thanks, -Alfred > 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 From Darren.Moffat@Sun.com Fri Aug 14 01:24:52 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E8OquP008899 for ; Fri, 14 Aug 2009 01:24:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7E8OpoF035720 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Aug 2009 02:24:51 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00307Y1ELS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 02:24:50 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC009YMY1ED590@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 02:24:50 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7E8On75028408 for ; Fri, 14 Aug 2009 08:24:49 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOC00N00XSS0Q00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 09:24:29 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOC009E9Y09S1E0@fe-emea-10.sun.com>; Fri, 14 Aug 2009 09:24:10 +0100 (BST) Date: Fri, 14 Aug 2009 09:24:00 +0100 From: Darren J Moffat Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <20090814000824.GL727117@eng.sun.com> Sender: Darren.Moffat@Sun.com To: johansen@Sun.com Cc: PSARC-ext@Sun.com Message-id: <4A851F20.8090804@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20090814000824.GL727117@eng.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 2004 johansen@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 From johansen@sun.com Fri Aug 14 09:10:33 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EGAX22022052 for ; Fri, 14 Aug 2009 09:10:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7EGAKtr018297; Fri, 14 Aug 2009 09:10:31 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00655JLIMM00@brm-avmta-1.central.sun.com>; Fri, 14 Aug 2009 10:10:30 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00LOKJLHRR50@brm-avmta-1.central.sun.com>; Fri, 14 Aug 2009 10:10:29 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7EGATps198867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Aug 2009 09:10:29 -0700 (PDT) Received: (from johansen@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n7EGAQB0198857; Fri, 14 Aug 2009 09:10:26 -0700 (PDT) Date: Fri, 14 Aug 2009 09:10:26 -0700 From: johansen@sun.com Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <4A851F20.8090804@Sun.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, Stephen Hahn Message-id: <20090814161026.GB193253@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <20090814000824.GL727117@eng.sun.com> <4A851F20.8090804@Sun.COM> X-Authentication-warning: jurassic-x4600.sfbay.sun.com: johansen set sender to johansen@sun.com using -f User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 4276 On Fri, Aug 14, 2009 at 09:24:00AM +0100, Darren J Moffat wrote: > johansen@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 From Darren.Moffat@sun.com Fri Aug 14 13:02:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EK2l7q000834 for ; Fri, 14 Aug 2009 13:02:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7EK2iU2050493 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 14 Aug 2009 14:02:46 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD0010ZUCL9S00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 13:02:45 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00LKBUCKH210@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 13:02:45 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7EK2iMI024488 for ; Fri, 14 Aug 2009 20:02:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOD00E00U0FHX00@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 14 Aug 2009 21:02:39 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOD009Y8UCESW00@fe-emea-10.sun.com>; Fri, 14 Aug 2009 21:02:39 +0100 (BST) Date: Fri, 14 Aug 2009 21:02:30 +0100 From: Darren J Moffat Subject: Re: Default system CA (X.509) Certificates [PSARC/2009/430 FastTrack timeout 08/19/2009] In-reply-to: <20090814161026.GB193253@eng.sun.com> Sender: Darren.Moffat@sun.com To: johansen@sun.com Cc: PSARC-ext@sun.com, Stephen Hahn Message-id: <4A85C2D6.2030105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <20090814000824.GL727117@eng.sun.com> <4A851F20.8090804@Sun.COM> <20090814161026.GB193253@eng.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 781 johansen@sun.com wrote: > On Fri, Aug 14, 2009 at 09:24:00AM +0100, Darren J Moffat wrote: >> johansen@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 From Darren.Moffat@oracle.com Thu Jun 17 02:56:22 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5H9uM4Q015573 for ; Thu, 17 Jun 2010 02:56:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5H9uLAp021247 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 04:56:21 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L450001PKXXMX00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 03:56:21 -0600 (MDT) Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L45009KBKXWKSA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 03:56:20 -0600 (MDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o5H9uJFQ017946 for ; Thu, 17 Jun 2010 09:56:20 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5H8pKk0030689 for ; Thu, 17 Jun 2010 09:56:18 +0000 (GMT) Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 333795571276768496; Thu, 17 Jun 2010 02:54:56 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 02:54:56 -0700 Date: Thu, 17 Jun 2010 10:54:54 +0100 From: Darren J Moffat Subject: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] To: PSARC-ext@sun.com, Hai-May Chao Message-id: <4C19F0EE.1030701@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C19F143.015E:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 1759 I'm restarting this case, given the previous review and the fact that this just addresses the issues it brought up I'm marking it closed approved now. If anyone things it needs further review I'll start a timer. The new technical part spec is as follows (and is in the case directory as spec.txt) Proposal -------- This case is about the architecture of where and in what format CA certifcates are delivered. The specific list of certs to deliver is a "business" issue for any given distribution. The project team intends to initially deliver the same set of CA certificates that is used in the Mozilla NSS libraries. The project team reserves the right to revise the exact list of certificates and/or choose an entirely different source of certifcates at anytime without requiring further ARC review. A separate X.509 certificate in PEM format for each CA will be placed in /etc/certs/CA/. The files will be named by taking the X.509 DN and replacing the spaces and other unprintables with an '_'. A symlink named using the 'openssl x509 hash' command to each of those PEM files is also created for those consumers that do fast lookups using a hash of the cert DN. The package name is pkg:/system/ca-certs Exported Interfaces +---------------------------------------------------------+ | pkg:/system/ca-certs | Volatile | | /etc/certs/CA/ [1] | Committed | | format CA files (PEM) | Committed | | Exact list of CA files | Volatile | +---------------------------------------------------------+ [1] Note that the /etc/certs directory already exists and is a delivered component of Solaris (via pkg:/SUNWcs). -- Darren J Moffat From garrett@damore.org Thu Jun 17 08:21:32 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5HFLVQa021166 for ; Thu, 17 Jun 2010 08:21:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o5HFLUbG036742 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 09:21:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4500205ZZVI900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 08:21:31 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4500LO9ZZU0X30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 08:21:31 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5HFLTSP007926 for ; Thu, 17 Jun 2010 15:21:30 +0000 (GMT) Received: from mmp14es.mmp.us.syntegra.com ([160.41.208.14] [160.41.208.14]) by relay15i.sun.com with ESMTP id BT-MMP-2434565 for PSARC-ext@sun.com; Thu, 17 Jun 2010 15:21:29 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp14es.mmp.us.syntegra.com with ESMTP id BT-MMP-26548 for PSARC-ext@sun.com; Thu, 17 Jun 2010 15:21:28 +0000 (Z) Received: from oproxy3-pub.bluehost.com ([69.89.21.8] [69.89.21.8]) by relay1i.sun.com id BT-MMP-17389813 for PSARC-ext@sun.com; Thu, 17 Jun 2010 15:21:28 +0000 (Z) Received: (qmail 22713 invoked by uid 0); Thu, 17 Jun 2010 15:21:27 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy3.bluehost.com with SMTP; Thu, 17 Jun 2010 15:21:27 +0000 Received: from cpe-76-93-15-33.socal.res.rr.com ([76.93.15.33] helo=[192.168.251.110]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OPGuF-000233-D8; Thu, 17 Jun 2010 09:21:27 -0600 Date: Thu, 17 Jun 2010 08:21:45 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <4C19F0EE.1030701@Oracle.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, Hai-May Chao Message-id: <1276788105.2729.86.camel@velocity> MIME-version: 1.0 X-Mailer: Evolution 2.28.3 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=nTR4w8xHylP1P8uB1E/Y1bSQhABnf1w+zCMG0DXlCRQo6j2OILW72zlk237eIQGkDs2LS6K07wifTAPqq0BoPjobfsd+v3DMa4iLtQLi+OQ7g7ibsn1+rJwL33AVfcW9; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 76.93.15.33 authed with garrett+damore.org} X-Antispam: No, score=0.0/5.0, scanned in 0.245sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C19F0EE.1030701@Oracle.COM> Status: RO Content-Length: 950 On Thu, 2010-06-17 at 10:54 +0100, Darren J Moffat wrote: My only concern is this paragraph: > > The project team reserves the right to revise the exact list of > certificates and/or choose an entirely different source of certifcates > at anytime without requiring further ARC review. > While ARC may or may not be the best place to review changes to the certificate list (it probably isn't), I think we should like to know how revisions will be made -- i.e. who decides when a change is appropriate and what the change will be? The project team? You? C-Team? P-Team? I think there should be at least *some* review by some group of people when something so important to the security of the underlying system is changed. So I'd like to know more about what is intended here. And I think understanding what this review would be is part of the fundamental architecture of the case, so I think its appropriate to discuss here. - Garrett From sebastien.roy@oracle.com Thu Jun 17 08:33:35 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5HFXYDR021454 for ; Thu, 17 Jun 2010 08:33:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5HFXXQW020314 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 10:33:34 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4600K0T0JY8Q00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 08:33:34 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4600FF10JXWGE0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 08:33:33 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5HFXWjQ000408 for ; Thu, 17 Jun 2010 15:33:32 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HFXSHr000601; Thu, 17 Jun 2010 15:33:28 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 352954971276788778; Thu, 17 Jun 2010 08:32:58 -0700 Received: from [129.148.19.4] (/129.148.19.4) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 08:32:53 -0700 Date: Thu, 17 Jun 2010 11:32:51 -0400 From: Sebastien Roy Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <1276788105.2729.86.camel@velocity> To: "Garrett D'Amore" Cc: Darren J Moffat , PSARC-ext@sun.com, Hai-May Chao Message-id: <4C1A4023.2050608@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4C1A4049.0050:SCFMA4539814,ss=1,fgs=0 References: <4C19F0EE.1030701@Oracle.COM> <1276788105.2729.86.camel@velocity> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100524 Lightning/1.0b1 Thunderbird/3.0.4 Status: RO Content-Length: 1350 On 06/17/10 11:21 AM, Garrett D'Amore wrote: > On Thu, 2010-06-17 at 10:54 +0100, Darren J Moffat wrote: > > My only concern is this paragraph: > >> >> The project team reserves the right to revise the exact list of >> certificates and/or choose an entirely different source of certifcates >> at anytime without requiring further ARC review. >> > > While ARC may or may not be the best place to review changes to the > certificate list (it probably isn't), I think we should like to know how > revisions will be made -- i.e. who decides when a change is appropriate > and what the change will be? The project team? You? C-Team? P-Team? > > I think there should be at least *some* review by some group of people > when something so important to the security of the underlying system is > changed. So I'd like to know more about what is intended here. > > And I think understanding what this review would be is part of the > fundamental architecture of the case, so I think its appropriate to > discuss here. It seems to me like this is something that the security team should be able to handle this within the team (i.e. during code-review), and verified during the RTI process. I don't think that this is an architectural issue, much like the specific list of certificates bundled with firefox has never been an architectural issue. -Seb From Darren.Moffat@oracle.com Thu Jun 17 09:13:00 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5HGCxms022229 for ; Thu, 17 Jun 2010 09:12:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5HGCxZ9023412 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 09:12:59 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L460080X2DNTF00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 10:12:59 -0600 (MDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4600BTL2DNM9E0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 10:12:59 -0600 (MDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5HGCwIH002183 for ; Thu, 17 Jun 2010 16:12:58 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HDWBTc012700; Thu, 17 Jun 2010 16:12:55 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 335141101276791144; Thu, 17 Jun 2010 09:12:24 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 09:12:24 -0700 Date: Thu, 17 Jun 2010 17:12:18 +0100 From: Darren J Moffat Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <1276788105.2729.86.camel@velocity> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, Hai-May Chao Message-id: <4C1A4962.4000505@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4C1A4988.0051:SCFMA4539814,ss=1,fgs=0 References: <4C19F0EE.1030701@Oracle.COM> <1276788105.2729.86.camel@velocity> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 891 On 17/06/2010 16:21, Garrett D'Amore wrote: > While ARC may or may not be the best place to review changes to the > certificate list (it probably isn't), I think we should like to know how > revisions will be made -- i.e. who decides when a change is appropriate > and what the change will be? The project team? You? C-Team? P-Team? The appropriate security team at the company producing the distribution based on the OpenSolaris source code. That may not be the same people as the security functionality engineering teams. This is an internal policy decision for each distribution and as such for Oracle's distribution(s) based on the OpenSolaris codebase will not be discussed further here. This project is delivering into the onnv gate the same initial set as what Firefox/Thunderbird uses, other distributions are free to use that as a starting point. -- Darren J Moffat From garrett@damore.org Thu Jun 17 11:28:56 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5HIStKZ024873 for ; Thu, 17 Jun 2010 11:28:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5HIStcx014773 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 11:28:55 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4600K018O7EU00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 17 Jun 2010 12:28:55 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L46009MD8O6P8D0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 17 Jun 2010 12:28:54 -0600 (MDT) Received: from relay44i.sun.com ([192.5.209.118]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5HI7vKf004656 for ; Thu, 17 Jun 2010 18:28:54 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay44i.sun.com with ESMTP id BT-MMP-136393 for PSARC-ext@Sun.COM; Thu, 17 Jun 2010 18:28:54 +0000 (Z) Received: from relay45i.sun.com (relay45i.sun.com [192.5.209.94]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-214616538 for PSARC-ext@Sun.COM; Thu, 17 Jun 2010 18:28:54 +0000 (Z) Received: from oproxy1-pub.bluehost.com ([66.147.249.253] [66.147.249.253]) by relay4i.sun.com id BT-MMP-17761282 for PSARC-ext@Sun.COM; Thu, 17 Jun 2010 18:28:53 +0000 (Z) Received: (qmail 4889 invoked by uid 0); Thu, 17 Jun 2010 18:28:53 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy1.bluehost.com.bluehost.com with SMTP; Thu, 17 Jun 2010 18:28:53 +0000 Received: from cpe-76-93-15-33.socal.res.rr.com ([76.93.15.33] helo=[192.168.251.110]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OPJpd-0001SC-5i; Thu, 17 Jun 2010 12:28:53 -0600 Date: Thu, 17 Jun 2010 11:29:12 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <4C1A4962.4000505@Oracle.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, Hai-May Chao Message-id: <1276799352.2729.105.camel@velocity> MIME-version: 1.0 X-Mailer: Evolution 2.28.3 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=3Hu+6zBjBNZyvW/8Y2eMek5/BFIXF5xjeosyd0strSJrXK/X7DAWzDIonALs00pNZyKbfDWvChFBmFFu3UAu2RbwP9/WVN5F4vCR2hhvmFaKHDutlPWUgTaGuYE9YVFj; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 76.93.15.33 authed with garrett+damore.org} X-Antispam: No, score=-2.6/5.0, scanned in 0.298sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C19F0EE.1030701@Oracle.COM> <1276788105.2729.86.camel@velocity> <4C1A4962.4000505@Oracle.COM> Status: RO Content-Length: 2321 On Thu, 2010-06-17 at 17:12 +0100, Darren J Moffat wrote: > On 17/06/2010 16:21, Garrett D'Amore wrote: > > While ARC may or may not be the best place to review changes to the > > certificate list (it probably isn't), I think we should like to know how > > revisions will be made -- i.e. who decides when a change is appropriate > > and what the change will be? The project team? You? C-Team? P-Team? > > The appropriate security team at the company producing the distribution > based on the OpenSolaris source code. That may not be the same people > as the security functionality engineering teams. > > This is an internal policy decision for each distribution and as such > for Oracle's distribution(s) based on the OpenSolaris codebase will not > be discussed further here. > > This project is delivering into the onnv gate the same initial set as > what Firefox/Thunderbird uses, other distributions are free to use that > as a starting point. By that argument, one could say the same thing about Oracle's distribution -- that it could modify the initial set in its distribution without having to change what is in ON. I realize that this is probably not an acceptable answer. :-) But its also the case that ARC has historically been responsible for reviewing the decisions that go into the final binary product ("distribution", or "WOS", if you prefer). So issues that affect that product certainly fall within ARC review, unless mgmt has changed the rules in a way that I don't know about. I don't think it is necessarily true that these decisions or review, or even a review of the process itself, have to be in the "open", but I do think that it is probably best if there is at least an internal closed review covering the process used to manage this list in the final product. One hopes there is a documented process somewhere! For the purposes of this case, a link (even one only available internally) to a document describing the process would IMO satisfy the architectural considerations. As far as the open community goes, I think its perfectly reasonable to state that the list in the source code is a sample set only, and subject to change at whim; and that distribution builders are responsible for ensuring that the set they ship is appropriate for their own needs. - Garrett From Darren.Moffat@oracle.com Thu Jun 17 12:04:47 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5HJ4lTY025598 for ; Thu, 17 Jun 2010 12:04:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o5HJ4kbb038908 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 13:04:46 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4600A1PABYST00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 12:04:46 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4600IVSABWQF90@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 12:04:44 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o5HJ4ies003057 for ; Thu, 17 Jun 2010 19:04:44 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HEhvcR016307; Thu, 17 Jun 2010 19:04:40 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 335720611276801477; Thu, 17 Jun 2010 12:04:37 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 12:04:37 -0700 Date: Thu, 17 Jun 2010 20:04:33 +0100 From: Darren J Moffat Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <1276799352.2729.105.camel@velocity> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, Hai-May Chao Message-id: <4C1A71C1.3050201@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C1A71C9.004A:SCFMA4539814,ss=1,fgs=0 References: <4C19F0EE.1030701@Oracle.COM> <1276788105.2729.86.camel@velocity> <4C1A4962.4000505@Oracle.COM> <1276799352.2729.105.camel@velocity> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 660 On 17/06/2010 19:29, Garrett D'Amore wrote: > I don't think it is necessarily true that these decisions or review, or > even a review of the process itself, have to be in the "open", but I do > think that it is probably best if there is at least an internal closed > review covering the process used to manage this list in the final > product. One hopes there is a documented process somewhere! For the > purposes of this case, a link (even one only available internally) to a > document describing the process would IMO satisfy the architectural > considerations. There is a process internally, but I won't post the link to this case. -- Darren J Moffat From garrett@damore.org Thu Jun 17 12:07:24 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5HJ7N0g025632 for ; Thu, 17 Jun 2010 12:07:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5HJ7MTY016784 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 14:07:23 -0500 (CDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L460000HAG7OW00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 17 Jun 2010 13:07:19 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L460096DAG5PCF0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Thu, 17 Jun 2010 13:07:17 -0600 (MDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o5HIvd2u029747 for ; Thu, 17 Jun 2010 19:07:17 +0000 (GMT) Received: from mms49es.mms.us.syntegra.com ([160.41.221.232] [160.41.221.232]) by relay41i.sun.com with ESMTP id BT-MMP-380857 for PSARC-ext@Sun.COM; Thu, 17 Jun 2010 19:07:17 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms49es.mms.us.syntegra.com with ESMTP id BT-MMP-214397702 for PSARC-ext@Sun.COM; Thu, 17 Jun 2010 19:07:16 +0000 (Z) Received: from oproxy2-pub.bluehost.com ([67.222.39.60] [67.222.39.60]) by relay4i.sun.com id BT-MMP-14798969 for PSARC-ext@Sun.COM; Thu, 17 Jun 2010 19:07:16 +0000 (Z) Received: (qmail 26596 invoked by uid 0); Thu, 17 Jun 2010 19:07:16 +0000 Received: from unknown (HELO box374.bluehost.com) (69.89.31.174) by oproxy2.bluehost.com with SMTP; Thu, 17 Jun 2010 19:07:15 +0000 Received: from cpe-76-93-15-33.socal.res.rr.com ([76.93.15.33] helo=[192.168.251.110]) by box374.bluehost.com with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OPKQl-0000YD-F0; Thu, 17 Jun 2010 13:07:15 -0600 Date: Thu, 17 Jun 2010 12:07:34 -0700 From: "Garrett D'Amore" Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <4C1A71C1.3050201@Oracle.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, Hai-May Chao Message-id: <1276801654.2729.109.camel@velocity> MIME-version: 1.0 X-Mailer: Evolution 2.28.3 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=damore.org; h=Received:Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer:Content-Transfer-Encoding:X-Identified-User; b=6AnCDf3rWym/VlmcS5OGzpTpSVy4l9RGqOXlg4I7vt7FgcExdWxvtOqgbGZNUjf41wQ2AhFkWQ+vQ9W7NFTvEW/YWcU0g+1X3SBrRp11O+mGzu27gDia0YXwORJh6sP3; X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Identified-User: {2225:box374.bluehost.com:damoreor:damore.org} {sentby:smtp auth 76.93.15.33 authed with garrett+damore.org} X-Antispam: No, score=0.0/5.0, scanned in 0.110sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4C19F0EE.1030701@Oracle.COM> <1276788105.2729.86.camel@velocity> <4C1A4962.4000505@Oracle.COM> <1276799352.2729.105.camel@velocity> <4C1A71C1.3050201@Oracle.COM> Status: RO Content-Length: 976 On Thu, 2010-06-17 at 20:04 +0100, Darren J Moffat wrote: > On 17/06/2010 19:29, Garrett D'Amore wrote: > > I don't think it is necessarily true that these decisions or review, or > > even a review of the process itself, have to be in the "open", but I do > > think that it is probably best if there is at least an internal closed > > review covering the process used to manage this list in the final > > product. One hopes there is a documented process somewhere! For the > > purposes of this case, a link (even one only available internally) to a > > document describing the process would IMO satisfy the architectural > > considerations. > > There is a process internally, but I won't post the link to this case. > Can you at least post it somewhere where the other internal ARC members can see it, or tell them how to verify the process if they should need/want to? That said, I'm satisfied that this case does not need any further review of its own. - Garrett From Darren.Moffat@Oracle.COM Thu Jun 17 12:21:34 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5HJLXMN025788 for ; Thu, 17 Jun 2010 12:21:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5HJLXOB024203 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 14:21:33 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4600709B3XJX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 12:21:33 -0700 (PDT) Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L46006AEB3WCI10@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 12:21:32 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5HJLWrv010521 for ; Thu, 17 Jun 2010 19:21:32 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5HJLNfn008300; Thu, 17 Jun 2010 19:21:24 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt353.oracle.com with ESMTP id 353567901276802453; Thu, 17 Jun 2010 12:20:53 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 17 Jun 2010 12:20:52 -0700 Date: Thu, 17 Jun 2010 20:20:50 +0100 From: Darren J Moffat Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <1276801654.2729.109.camel@velocity> To: "Garrett D'Amore" Cc: PSARC-ext@sun.com, Hai-May Chao Message-id: <4C1A7592.5090509@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090209.4C1A75B7.0108:SCFMA4539814,ss=1,fgs=0 References: <4C19F0EE.1030701@Oracle.COM> <1276788105.2729.86.camel@velocity> <4C1A4962.4000505@Oracle.COM> <1276799352.2729.105.camel@velocity> <4C1A71C1.3050201@Oracle.COM> <1276801654.2729.109.camel@velocity> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 308 On 17/06/2010 20:07, Garrett D'Amore wrote: >> There is a process internally, but I won't post the link to this case. >> > > Can you at least post it somewhere where the other internal ARC members > can see it, or tell them how to verify the process if they should > need/want to? Yes. -- Darren J Moffat From johansen@opensolaris.org Thu Jun 17 17:19:35 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5I0JZih002972 for ; Thu, 17 Jun 2010 17:19:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5I0JZXX015807 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 17 Jun 2010 17:19:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4600005OWNOX00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 17:19:35 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L46006LHOWMCFD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 17 Jun 2010 17:19:34 -0700 (PDT) Received: from kotuk.sfbay.sun.com (kotuk.SFBay.Sun.COM [129.146.228.79]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5I0JY89025532; Thu, 17 Jun 2010 17:19:34 -0700 (PDT) Received: from kotuk.sfbay.sun.com (kotuk.local [127.0.0.1]) by kotuk.sfbay.sun.com (8.14.4+Sun/8.14.4) with ESMTP id o5I0JYU9002436; Thu, 17 Jun 2010 17:19:34 -0700 (PDT) Received: (from johansen@localhost) by kotuk.sfbay.sun.com (8.14.4+Sun/8.14.4/Submit) id o5I0JYm1002427; Thu, 17 Jun 2010 17:19:34 -0700 (PDT) Date: Thu, 17 Jun 2010 17:19:34 -0700 From: johansen@opensolaris.org Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <4C19F0EE.1030701@Oracle.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com, Hai-May Chao Message-id: <20100618001934.GL28138@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4C19F0EE.1030701@Oracle.COM> User-Agent: Mutt/1.5.20 (2009-06-14) Status: RO Content-Length: 1613 Darren, On Thu, Jun 17, 2010 at 10:54:54AM +0100, Darren J Moffat wrote: > I'm restarting this case, given the previous review and the fact > that this just addresses the issues it brought up I'm marking it > closed approved now. If anyone things it needs further review I'll > start a timer. This may need further review. In the 10 months that have passed since I initially commented on this proposal, OpenSSL 1.0.0 has been released, and there are interoperability problems between 0.9.8 and 1.0.0. Unfortunately, these pertain directly to how CA certificates are hashed and looked up when stored in a CA directory. > Proposal > -------- > A separate X.509 certificate in PEM format for each CA will be placed > in /etc/certs/CA/. The files will be named by taking the X.509 DN and > replacing the spaces and other unprintables with an '_'. A symlink > named using the 'openssl x509 hash' command to each of those PEM files > is also created for those consumers that do fast lookups using a hash > of the cert DN. Do we ever anticipate having both OpenSSL 0.9.8 and 1.0.0 installed on a machine at the same time? If so, or if we allow these libraries to be interchangable, the method that is used to compute the X.509 DN hash in 0.9.8 is different from 1.0.0. If we'd like these CA certs to be usable by both library versions, we'll need to create symlinks in 0.9.8 and 1.0.0 format that both point to the underlying CA certificate. There is slightly more detail on the problem here, though it is in the context of Postfix. http://tech.groups.yahoo.com/group/postfix-users/message/265662 -j From Darren.Moffat@Oracle.COM Tue Jun 22 03:41:22 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5MAfMtL024222 for ; Tue, 22 Jun 2010 03:41:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o5MAfLCP065351 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 22 Jun 2010 04:41:22 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4E00207WCXY400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Jun 2010 03:41:21 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4E0005DWCX0A30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 22 Jun 2010 03:41:21 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5MAfK9U012224 for ; Tue, 22 Jun 2010 10:41:21 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5M6aCCg010404; Tue, 22 Jun 2010 10:41:17 +0000 (GMT) Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 363182521277203228; Tue, 22 Jun 2010 03:40:28 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 22 Jun 2010 03:40:28 -0700 Date: Tue, 22 Jun 2010 11:40:25 +0100 From: Darren J Moffat Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <20100618001934.GL28138@oracle.com> To: johansen@opensolaris.org Cc: PSARC-ext@sun.com, Hai-May Chao Message-id: <4C209319.5060705@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C20934D.01E8:SCFMA4539814,ss=1,fgs=0 References: <4C19F0EE.1030701@Oracle.COM> <20100618001934.GL28138@oracle.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.8) Gecko/20100412 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.3 Status: RO Content-Length: 726 To address the issue of different versions of OpenSSL potentially needing different certificate hashes this case will store the certificates files in /etc/certs/CA but the hashes to them will be stored in the default OpenSSL cert directory, namely /etc/openssl/certs, as listed in the default /etc/openssl/openssl.cnf file. If we end up delivering multiple versions of OpenSSL at the same time (soemthing we hope very much to avoid if at all possible) then there will be multiple configuration files and thus multiple OpenSSL certs directories. The nature of how that is done if it turns out to be necessary will be part of a possible future case if delivery of multiple version is unavoidable. -- Darren J Moffat From Darren.Moffat@Oracle.COM Thu Jun 24 10:53:44 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5OHriKX025806 for ; Thu, 24 Jun 2010 10:53:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o5OHrhal007262 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 24 Jun 2010 10:53:43 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4J004015PJ5W00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 24 Jun 2010 10:53:43 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4J008DI5PJHD80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 24 Jun 2010 10:53:43 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5OHrhfd012944 for ; Thu, 24 Jun 2010 17:53:43 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5O98EmX012385 for ; Thu, 24 Jun 2010 17:53:42 +0000 (GMT) Received: from abhmt018.oracle.com by acsmt355.oracle.com with ESMTP id 371503521277401958; Thu, 24 Jun 2010 10:52:38 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Jun 2010 10:52:37 -0700 Date: Thu, 24 Jun 2010 18:52:35 +0100 From: Darren J Moffat Subject: PSARC/2009/430 Default system CA (X.509) Certificates [ pkg(5) name update ] To: PSARC-ext@sun.com Message-id: <4C239B63.2050000@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C239BA6.01CF:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 Status: RO Content-Length: 216 After some discussion at RTI time the package name settled on based on using preexisting hierarchies and getting as close as possible a name match to OEL/RedHat is pkg:/crypto/ca-certificates. -- Darren J Moffat From haimay.chao@oracle.com Thu Jun 24 12:55:20 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o5OJtKJo028550 for ; Thu, 24 Jun 2010 12:55:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o5OJtI5I015467 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 24 Jun 2010 13:55:19 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L4J00E0JBC7X300@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 24 Jun 2010 12:55:19 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L4J0022FBC7JSC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 24 Jun 2010 12:55:19 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o5OJtItf011608 for ; Thu, 24 Jun 2010 19:55:18 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5OCAN6m012803 for ; Thu, 24 Jun 2010 19:55:16 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 354871441277409313; Thu, 24 Jun 2010 12:55:13 -0700 Received: from [129.150.12.253] (/129.150.12.253) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Jun 2010 12:55:12 -0700 Date: Thu, 24 Jun 2010 12:57:35 -0700 From: Hai-May Chao Subject: Re: PSARC 2009/430 Default system CA (X.509) Certificates [closed approved 06/17/2010] In-reply-to: <4C19F0EE.1030701@Oracle.COM> To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: <4C23B8AF.9010000@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C23B826.0078:SCFMA4539814,ss=1,fgs=0 References: <4C19F0EE.1030701@Oracle.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 192 The package name for this case is changed to be pkg:/crypto/ca-certificates. This was recommended by David Comay as we already have 'crypto' as the top level name in the hierarchy. Hai-May