From brian.utterback@sun.com Wed Jul 1 08:36:38 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 n61Faben010170 for ; Wed, 1 Jul 2009 08:36:38 -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 n61Faa3R049669 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 1 Jul 2009 09:36:37 -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 <0KM400A0L0P02Y00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 08:36:36 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KM4005JV0OZWVD0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 08:36:35 -0700 (PDT) Received: from [129.148.9.87] (sr1-ubur-08.East.Sun.COM [129.148.9.87]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n61FaXHs052332; Wed, 01 Jul 2009 11:36:34 -0400 (EDT) Date: Wed, 01 Jul 2009 11:36:33 -0400 From: Brian Utterback Subject: PSARC/2009/374 libxmlsec To: PSARC-ext Cc: William Young Message-id: <4A4B8281.3030601@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_771LxkjqOIa+qE4gOHpFcA)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.22pre (X11/20090603) Status: RO Content-Length: 12451 This is a multi-part message in MIME format. --Boundary_(ID_771LxkjqOIa+qE4gOHpFcA) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT The email from this apparently got eaten in yesterday's outages, so I am resending this. I am sponsoring this fast track on behalf of Will Young. The timer is set for 07/08/2009. The binding is minor. The template is a one-pager, but this is being submitted as a fasttrack. -- blu "The advertising giveth and the EULA taketh away." ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom --Boundary_(ID_771LxkjqOIa+qE4gOHpFcA) Content-type: text/plain; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=proposal.txt Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: libxmlsec 1.2. Name of Document Author/Supplier: William Young 1.3. Date of This Document: 06/ /09 // MM/DD/YY 1.3.1. Date this project was conceived: 11/07/07 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Kathy.Jenks@sun.com 1.4.4. The name of your business unit: Solaris Security 1.5. Email Aliases: 1.5.1. Responsible Manager: Craig.Payne@sun.com 1.5.2. Responsible Engineer: William.Young@sun.com 1.5.3. Marketing Manager: Mark.Thacker@sun.com 1.5.4. Interest List: valex-core@sun.com 2. Project Summary 2.1. Project Description: Libxmlsec is a C library that implements XML Digital Signature and XML Encryption. It is based on libxml[1] which is already integrated in the SFW consolidation. With the integration of libxmlsec, applications that use XML can take advantage of XML standards for integrity and privacy. 2.2. Risks and Assumptions: As an open community project it is always possible decisions will be made that affect interfaces. But libxmlsec has a historical track record back to 2002 that shows this has been relatively unlikely since it reached maturity in 2003. Since libxmlsec is dependent on libxml2 and openssl, API changes in these underlying libraries can require a corresponding libxmlsec update. 3. Business Summary The Signed Execution project at a minimum needs the ability to verify XML-DSIG signatures from other vendors. While an understanding of a specific subset of the standard could be hard-coded there would be no benefit and considerable risks of incompatibility relative to importing libxmlsec and making it generally available. The availability of libxmlsec creates opportunities to improve security for other Solaris components that already use XML, and makes Solaris a richer platform for application development in areas like secure transactions. 3.1. Problem Area: Creating and verifying assurances of integrity and secrecy within XML has broad applications. It is most applicable when a combination of interoperability and "data at rest" or end-to-end integrity or secrecy is needed. For example, it is used by Openoffice to secure ODF documents and to secure transaction protocols where later repudiation make simple transport security inappropriate. 3.2. Market/Requester: The Signed Execution project is the primary requester of this feature. 3.3. Business Justification: 3.4. Competitive Analysis: 3.5. Opportunity Window/Exposure: 3.6. How will you know when you are done?: libxmlsec will be available on Solaris. Solaris components that compile against libxml2 can also compile against libxmlsec. The libxmlsec library will be accessible before filesystem/usr is available. 4. Technical Description: 4.1. Details: The libxmlsec source code tarball will be in the SFW gate and use a build harness similar to other libxml2 libraries. It will be configured and compiled with only its libxmlsec-openssl module to support OpenSSL as the underlying encryption library. The libxmlsec-openssl crypto module is libxmlsec's default module, is MIT licensed and can make use of Sun's OpenSSL crypto engine to use the Userland Encryption Framework. Legal approval for this usage is covered by OSR 7806. A follow up ARC cases may be filed after RFE#6479874 integrates in our OpenSSL implementation to improve crypto engine usage. A future ARC case could also switch us from using the OpenSSL module to a new module with more direct access to the crypto framework. Such a module would first need to be integrated in the community project. 4.2. Bug/RFE Number(s): 6663027 Using XMLDSig and libxmlsec in Solaris 4.3. In Scope: The libxmlsec and libxmlsec-openssl libraries, headers and utility commands (xmlsec1, xmlsec1-config) of libxmlsec. The move of libxslt from /usr/lib to /lib as libxmlsec and therefore libxslt will be needed by early Validated Execution[5]. 4.4. Out of Scope: Support for NSS keystores or usage of gnutls, or libnss in place of OpenSSL as the underlying encryption provider. 4.5. Interfaces: The libxslt[4] library is relocated to /lib but otherwise has the same status. The provided commands and underlying crypto provider are Volatile and could change based on new bits from the upstream community and changes to the Solaris selection of crypto providers. The use of libxmlsec is Uncommitted. In the unlikely event that the upstream community changes an existing interface means of remediation will be investigated. Include files, Uncommitted: usr/include/xmlsec/transforms.h usr/include/xmlsec/errors.h usr/include/xmlsec/crypto.h usr/include/xmlsec/xmlenc.h usr/include/xmlsec/xmlsec.h usr/include/xmlsec/buffer.h usr/include/xmlsec/exports.h usr/include/xmlsec/app.h usr/include/xmlsec/xmltree.h usr/include/xmlsec/xkms.h usr/include/xmlsec/io.h usr/include/xmlsec/keysmngr.h usr/include/xmlsec/keyinfo.h usr/include/xmlsec/bn.h usr/include/xmlsec/version.h usr/include/xmlsec/membuf.h usr/include/xmlsec/keysdata.h usr/include/xmlsec/keys.h usr/include/xmlsec/dl.h usr/include/xmlsec/nodeset.h usr/include/xmlsec/xmldsig.h usr/include/xmlsec/strings.h usr/include/xmlsec/templates.h usr/include/xmlsec/x509.h usr/include/xmlsec/list.h usr/include/xmlsec/base64.h usr/include/xmlsec/soap.h usr/include/xmlsec/parser.h pkgconfig data, Volatile: usr/lib/pkgconfig/xmlsec1.pc usr/lib/pkgconfig/xmlsec1-openssl.pc automake data, Volatile: usr/share/aclocal/xmlsec1.m4 Root Libraries + links, Uncommitted: lib/libxmlsec1.so lib/libxmlsec1.so.1 lib/amd64/libxmlsec1.so lib/amd64/libxmlsec1.so.1 lib/sparcv9/libxmlsec1.so lib/sparcv9/libxmlsec1.so.1 lib/libxmlsec1-openssl.so lib/libxmlsec1-openssl.so.1 lib/amd64/libxmlsec1-openssl.so lib/amd64/libxmlsec1-openssl.so.1 lib/sparcv9/libxmlsec1-openssl.so lib/sparcv9/libxmlsec1-openssl.so.1 Library access via /usr links Uncommitted: usr/lib/libxmlsec1.so usr/lib/libxmlsec1.so.1 usr/lib/amd64/libxmlsec1.so usr/lib/amd64/libxmlsec1.so.1 usr/lib/sparcv9/libxmlsec1.so usr/lib/sparcv9/libxmlsec1.so.1 Volatile: usr/lib/libxmlsec1-openssl.so usr/lib/libxmlsec1-openssl.so.1 usr/lib/amd64/libxmlsec1-openssl.so usr/lib/amd64/libxmlsec1-openssl.so.1 usr/lib/sparcv9/libxmlsec1-openssl.so usr/lib/sparcv9/libxmlsec1-openssl.so.1 Commands, Volatile: usr/bin/xmlsec1-config usr/bin/xmlsec1 4.6. Doc Impact: Import from community: xmlsec1(1) xmlsec1-config(1) New: libxmlsec(3) 4.7. Admin/Config Impact: None. (No configuration.) 4.8. HA Impact: None. (No daemon or configuration.) 4.9. I18N/L10N Impact: Similar to other libxml2 based libraries, such as libxslt[4], libxmlsec provides a CLI utility primarily used for testing which is not localized in the upstream project and will not be localized in Solaris. 4.10. Packaging & Delivery: The following new packages: SUNWlxmlsecr lib/libxmlsec1.so lib/libxmlsec1.so.1 lib/amd64/libxmlsec1.so lib/amd64/libxmlsec1.so.1 lib/sparcv9/libxmlsec1.so lib/sparcv9/libxmlsec1.so.1 lib/libxmlsec1-openssl.so lib/libxmlsec1-openssl.so.1 lib/amd64/libxmlsec1-openssl.so lib/amd64/libxmlsec1-openssl.so.1 lib/sparcv9/libxmlsec1-openssl.so lib/sparcv9/libxmlsec1-openssl.so.1 SUNWlxmlsec usr/bin/xmlsec1 usr/lib/libxmlsec1.so usr/lib/libxmlsec1.so.1 usr/lib/amd64/libxmlsec1.so usr/lib/amd64/libxmlsec1.so.1 usr/lib/sparcv9/libxmlsec1.so usr/lib/sparcv9/libxmlsec1.so.1 usr/lib/libxmlsec1-openssl.so usr/lib/libxmlsec1-openssl.so.1 usr/lib/amd64/libxmlsec1-openssl.so usr/lib/amd64/libxmlsec1-openssl.so.1 usr/lib/sparcv9/libxmlsec1-openssl.so usr/lib/sparcv9/libxmlsec1-openssl.so.1 SUNWlxmlsec-devel usr/include/xmlsec/transforms.h usr/include/xmlsec/errors.h usr/include/xmlsec/crypto.h usr/include/xmlsec/xmlenc.h usr/include/xmlsec/xmlsec.h usr/include/xmlsec/buffer.h usr/include/xmlsec/exports.h usr/include/xmlsec/app.h usr/include/xmlsec/xmltree.h usr/include/xmlsec/xkms.h usr/include/xmlsec/io.h usr/include/xmlsec/keysmngr.h usr/include/xmlsec/keyinfo.h usr/include/xmlsec/bn.h usr/include/xmlsec/version.h usr/include/xmlsec/membuf.h usr/include/xmlsec/keysdata.h usr/include/xmlsec/keys.h usr/include/xmlsec/dl.h usr/include/xmlsec/nodeset.h usr/include/xmlsec/xmldsig.h usr/include/xmlsec/strings.h usr/include/xmlsec/templates.h usr/include/xmlsec/x509.h usr/include/xmlsec/list.h usr/include/xmlsec/base64.h usr/include/xmlsec/soap.h usr/include/xmlsec/parser.h usr/lib/pkgconfig/xmlsec1.pc usr/lib/pkgconfig/xmlsec1-openssl.pc usr/share/aclocal/xmlsec1.m4 usr/bin/xmlsec1-config SUNWlxslr lib/libxslt.so.1 lib/libxslt.so lib/llib-lxslt.ln lib/amd64/libxslt.so.1 lib/amd64/libxslt.so lib/amd64/llib-lxslt.ln lib/sparcv9/libxslt.so.1 lib/sparcv9/libxslt.so lib/sparcv9/llib-lxslt.ln Modifications: SUNWlxsl usr/lib/libxslt.so.1 becomes a link to lib/libxslt.so.1 usr/lib/amd64/libxslt.so.1 becomes a link to lib/amd64/libxslt.so.1 usr/lib/sparcv9/libxslt.so.1 becomes a link to lib/sparcv9/libxslt.so.1 SUNWlxsl-devel usr/lib/llib-lxslt.ln becomes a link to lib/llib-lxslt.ln usr/lib/amd64/llib-lxslt.ln becomes a link to lib/amd64/llib-lxslt.ln usr/lib/sparcv9/llib-lxslt.ln becomes a link to lib/sparcv9/llib-lxslt.ln 4.11. Security Impact: Introduction of libxmlsec has no immediate security ramifications. Buffer overflows in libxmlsec or dependencies like libxml2 could lead to vulnerabilities when it is used to manipulate untrusted content, so careful review is warranted. 4.12. Dependencies: libxmlsec is dependent on libxml2[1], libxslt[4] and OpenSSL. 5. Reference Documents: [1] http://sac.eng/Archives/CaseLog/arc/PSARC/2001/175/ "PSARC/2001/175 Using XML and libxml in Solaris" libxml2's ARC case [2] http://sac.sfbay/PSARC/2001/488/ "UEF: Userland Encryption Framework" Encryption framework ARC case [3] http://www.aleksey.com/xmlsec/ "XML Security Library" libxmlsec's Community homepage [4] http://sac.sfbay/PSARC/2002/244/ "Using XSLT and libxslt in Solaris" libxslt's ARC case [5] http://sac.sfbay/PSARC/2007/674/ "Enabling Early Signature Validation" Relocation of libxml2 and related libraries to /lib 6. Resources and Schedule: 6.1. Projected Availability: September 2009 6.2. Cost of Effort: 3-6 employee-months 6.3. Cost of Capital Resources: $0 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: // Give the document's URL http://.... 6.4.5. Is this a necessary project for OEM agreements: No. 6.4.6. Notes: // See dependencies section above. 6.4.7. Target RTI Date/Release: August 2009 6.4.8. Target Code Design Review Date: July 2009 6.4.9. Update approval addition: This project is not targeting an Update Release. 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: 7. Prototype Availability: 7.1. Prototype Availability: Prototype compiles libxmlsec in the SFW gate and builds example SYSV packages. 7.2. Prototype Cost: 1 person-month --Boundary_(ID_771LxkjqOIa+qE4gOHpFcA)-- From Sebastien.Roy@sun.com Wed Jul 1 08:45:41 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 n61Fjf4L010333 for ; Wed, 1 Jul 2009 08:45:41 -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.2) with ESMTP id n61FjefZ055820 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 1 Jul 2009 09:45:40 -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 <0KM400K05144RN00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 08:45:40 -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 <0KM400BFC143D1B0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 08:45:40 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n61FjdnA006348 for ; Wed, 01 Jul 2009 15:45:39 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KM4006000PTNQ00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 09:45:39 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KM400IFR142CF00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 09:45:39 -0600 (MDT) Date: Wed, 01 Jul 2009 11:44:22 -0400 From: Sebastien Roy Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <4A4B8281.3030601@sun.com> Sender: Sebastien.Roy@sun.com To: Brian Utterback Cc: PSARC-ext , William Young Message-id: <1246463062.8298.9.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.26.1.1 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> Status: RO Content-Length: 664 I have not fully reviewed this case, but I do have one quick comment: On Wed, 2009-07-01 at 11:36 -0400, Brian Utterback wrote: > pkgconfig data, Volatile: > usr/lib/pkgconfig/xmlsec1.pc > usr/lib/pkgconfig/xmlsec1-openssl.pc > > automake data, Volatile: > usr/share/aclocal/xmlsec1.m4 ... > Volatile: > usr/lib/libxmlsec1-openssl.so > usr/lib/libxmlsec1-openssl.so.1 > usr/lib/amd64/libxmlsec1-openssl.so > usr/lib/amd64/libxmlsec1-openssl.so.1 > usr/lib/sparcv9/libxmlsec1-openssl.so > usr/lib/sparcv9/libxmlsec1-openssl.so.1 > > Commands, Volatile: > usr/bin/xmlsec1-config > usr/bin/xmlsec1 "Volatile" is not in the existing interface taxonomy. -Seb From Sebastien.Roy@Sun.COM Wed Jul 1 09:05:07 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 n61G57JI010935 for ; Wed, 1 Jul 2009 09:05:07 -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 n61G53XV014891 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 1 Jul 2009 09:05:07 -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 <0KM400E2D20H5X00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 09:05:05 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KM400BR420FLY10@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 09:05:03 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n61G53Kx024970 for ; Wed, 01 Jul 2009 16:05:03 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KM400J001S4T000@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 10:05:03 -0600 (MDT) Received: from [129.148.174.103] ([unknown] [129.148.174.103]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KM4003TE1ZXTSD0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 01 Jul 2009 10:04:46 -0600 (MDT) Date: Wed, 01 Jul 2009 12:03:29 -0400 From: Sebastien Roy Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <1246463062.8298.9.camel@strat> Sender: Sebastien.Roy@Sun.COM To: Brian Utterback Cc: PSARC-ext , William Young Message-id: <1246464209.8298.15.camel@strat> Organization: Sun Microsystems MIME-version: 1.0 X-Mailer: Evolution 2.26.1.1 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> <1246463062.8298.9.camel@strat> Status: RO Content-Length: 273 On Wed, 2009-07-01 at 11:44 -0400, Sebastien Roy wrote: > I have not fully reviewed this case, but I do have one quick comment: ... > "Volatile" is not in the existing interface taxonomy. Oh my, pardon me, of course it is (thanks Nico). Please ignore my comment. -Seb From Kais.Belgaied@Sun.COM Wed Jul 8 12:12:09 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 n68JC9WB019467 for ; Wed, 8 Jul 2009 12:12:09 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n68JC6Pb010136; Wed, 8 Jul 2009 12:12:08 -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 <0KMH00A179C74800@nwk-avmta-2.sfbay.sun.com>; Wed, 08 Jul 2009 12:12:07 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH001RL9C5P5A0@nwk-avmta-2.sfbay.sun.com>; Wed, 08 Jul 2009 12:12:05 -0700 (PDT) Received: from [10.5.238.201] (sr2-opensolaris.SFBay.Sun.COM [10.5.238.201]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n68JC52s208593; Wed, 08 Jul 2009 12:12:05 -0700 (PDT) Date: Wed, 08 Jul 2009 12:11:54 -0700 From: Kais Belgaied Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <4A4B8281.3030601@sun.com> To: Brian Utterback Cc: PSARC-ext , William Young Reply-to: Kais.Belgaied@Sun.COM Message-id: <4A54EF7A.7070007@Sun.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 References: <4A4B8281.3030601@sun.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 1040 > > The libxmlsec source code tarball will be in the SFW gate and use > a build harness similar to other libxml2 libraries. It will be > configured and compiled with only its libxmlsec-openssl module > to support OpenSSL as the underlying encryption library. > The libxmlsec-openssl crypto module is libxmlsec's default > module, is MIT licensed and can make use of Sun's OpenSSL crypto > engine to use the Userland Encryption Framework. Legal approval for > this usage is covered by OSR 7806. > A follow up ARC cases may be filed after RFE#6479874 integrates > in our OpenSSL implementation to improve crypto engine usage. > A future ARC case could also switch us from using the OpenSSL > module to a new module with more direct access to the crypto framework. > Such a module would first need to be integrated in the community > project. so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? doesn't this case require an ARC contract against PSARC/2003/500 for the import of OpenSSL ? Kais From Nicolas.Williams@sun.com Wed Jul 8 12:27: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 n68JRqMv013756 for ; Wed, 8 Jul 2009 12:27:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n68JRfwK004843; Wed, 8 Jul 2009 20:27:50 +0100 (BST) 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 <0KMH00B07A2B3N00@nwk-avmta-2.sfbay.sun.com>; Wed, 08 Jul 2009 12:27:47 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH001KUA2BOSB0@nwk-avmta-2.sfbay.sun.com>; Wed, 08 Jul 2009 12:27:47 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n68JP3DL001940; Wed, 08 Jul 2009 14:25:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n68JP3Fx001939; Wed, 08 Jul 2009 14:25:03 -0500 (CDT) Date: Wed, 08 Jul 2009 14:25:03 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <4A4B8281.3030601@sun.com> To: Brian Utterback Cc: PSARC-ext , William Young Message-id: <20090708192503.GS1064@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: <4A4B8281.3030601@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1328 On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote: > A future ARC case could also switch us from using the OpenSSL > module to a new module with more direct access to the crypto framework. > Such a module would first need to be integrated in the community > project. What sort of module are we talking? Where would it plug in? There already is a way to access the Solaris crypto framework more directly than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly. > 4.4. Out of Scope: > > Support for NSS keystores or usage of gnutls, or libnss in place of > OpenSSL as the underlying encryption provider. Sounds like libxmlsec could use KMF. You should talk to the KMF project team. > 4.5. Interfaces: > > The libxslt[4] library is relocated to /lib but otherwise has > the same status. > > The provided commands and underlying crypto provider are > Volatile and could change based on new bits from the upstream > community and changes to the Solaris selection of crypto > providers. It strikes me that /usr/bin/xmlsec1-config should have the same commitment level as the API, i.e., Uncommitted in this case. (Also, I thought that -config commands nowadays were being deprecated in favor of pc files. Are there autoconf scripts that depend on xmlsec1-config?) Nico -- From will.young@sun.com Wed Jul 8 13:07:53 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 n68K7r04014756 for ; Wed, 8 Jul 2009 13:07:53 -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 n68K7nGa000215 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 21:07:52 +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 <0KMH00L01BX3O400@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 08 Jul 2009 14:07:51 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00HI2BX3AC70@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 08 Jul 2009 14:07:51 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n68K7p0M007329 for ; Wed, 08 Jul 2009 20:07:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMH00500BONNF00@mail-amer.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 08 Jul 2009 14:07:51 -0600 (MDT) Received: from lumpy.local ([unknown] [71.192.37.217]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH0013MBWSTH20@mail-amer.sun.com>; Wed, 08 Jul 2009 14:07:45 -0600 (MDT) Date: Wed, 08 Jul 2009 16:06:53 -0400 From: Will Young Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <4A54EF7A.7070007@Sun.COM> Sender: William.Young@sun.com To: Kais.Belgaied@sun.com Cc: Brian Utterback , PSARC-ext , William Young Message-id: <1247083613.5231.0.camel@lumpy> MIME-version: 1.0 X-Mailer: Evolution 2.6.3 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> Status: RO Content-Length: 1252 On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote: > > > > The libxmlsec source code tarball will be in the SFW gate and use > > a build harness similar to other libxml2 libraries. It will be > > configured and compiled with only its libxmlsec-openssl module > > to support OpenSSL as the underlying encryption library. > > The libxmlsec-openssl crypto module is libxmlsec's default > > module, is MIT licensed and can make use of Sun's OpenSSL crypto > > engine to use the Userland Encryption Framework. Legal approval for > > this usage is covered by OSR 7806. > > A follow up ARC cases may be filed after RFE#6479874 integrates > > in our OpenSSL implementation to improve crypto engine usage. > > A future ARC case could also switch us from using the OpenSSL > > module to a new module with more direct access to the crypto framework. > > Such a module would first need to be integrated in the community > > project. > > so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? > > doesn't this case require an ARC contract against PSARC/2003/500 for the > import of OpenSSL ? I no longer saw a need for a contract as of the integration of: 6806387 Move OpenSSL from ON to SFW -Will > > Kais > From Nicolas.Williams@sun.com Wed Jul 8 13:22:20 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 n68KMJKU015049 for ; Wed, 8 Jul 2009 13:22:19 -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 n68KMI05060264; Wed, 8 Jul 2009 14:22:18 -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 <0KMH0000FCL53H00@brm-avmta-1.central.sun.com>; Wed, 08 Jul 2009 14:22:17 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00HTPCL4AD70@brm-avmta-1.central.sun.com>; Wed, 08 Jul 2009 14:22:17 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n68KJVoc001952; Wed, 08 Jul 2009 15:19:31 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n68KJVTb001951; Wed, 08 Jul 2009 15:19:31 -0500 (CDT) Date: Wed, 08 Jul 2009 15:19:31 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <1247083613.5231.0.camel@lumpy> To: Will Young Cc: Kais.Belgaied@sun.com, Brian Utterback , PSARC-ext , William Young Message-id: <20090708201931.GT1064@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: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 621 On Wed, Jul 08, 2009 at 04:06:53PM -0400, Will Young wrote: > On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote: > > so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? > > > > doesn't this case require an ARC contract against PSARC/2003/500 for the > > import of OpenSSL ? > > I no longer saw a need for a contract as of the integration of: > 6806387 Move OpenSSL from ON to SFW The move alone could not imply a change of interface stability. PSARC/2006/555 (Move OpenSSL to /usr) did not change the interface stability of any part of OpenSSL (see section 4.5 of the one-pager). Nico -- From will.young@sun.com Wed Jul 8 13:22:59 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 n68KMwkK015125 for ; Wed, 8 Jul 2009 13:22:59 -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 n68KMtmB010936 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 21:22:58 +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 <0KMH00001CM76200@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:22:55 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00H56CM7ACB0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:22:55 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n68KMtNh007246 for ; Wed, 08 Jul 2009 20:22:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMH00200B65K700@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:22:54 -0600 (MDT) Received: from lumpy.local ([unknown] [71.192.37.217]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH0080FCLNGI80@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:22:36 -0600 (MDT) Date: Wed, 08 Jul 2009 16:21:47 -0400 From: Will Young Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <20090708192503.GS1064@Sun.COM> Sender: William.Young@sun.com To: Nicolas Williams Cc: Brian Utterback , PSARC-ext , William Young Message-id: <1247084507.5231.15.camel@lumpy> MIME-version: 1.0 X-Mailer: Evolution 2.6.3 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> <20090708192503.GS1064@Sun.COM> Status: RO Content-Length: 2446 On Wed, 2009-07-08 at 14:25 -0500, Nicolas Williams wrote: > On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote: > > A future ARC case could also switch us from using the OpenSSL > > module to a new module with more direct access to the crypto framework. > > Such a module would first need to be integrated in the community > > project. > > What sort of module are we talking? Where would it plug in? There > already is a way to access the Solaris crypto framework more directly > than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly. Writing a xmlsec security module for libpkcs#11 is a possible future project if OpenSSL's engine support is not able to support keys by reference in the near term. However OpenSSL is the default crypto provider for xmlsec and seems to provide better APIs for tasks around certificates so a PKCS#11 xmlsec module that is an adequate replacement for the OpenSSL one is non-trivial. > > > 4.4. Out of Scope: > > > > Support for NSS keystores or usage of gnutls, or libnss in place of > > OpenSSL as the underlying encryption provider. > > Sounds like libxmlsec could use KMF. You should talk to the KMF project > team. A kmf/PKCS#11 hybrid module seems to be the only possibility aside from OpenSSL or NSS that adequately covers the needed crypto operations and certificate management operations. But this combination also doesn't solve anything for all store types so its is not a worthwhile immediate investment. Meanwhile, OpenSSL solves the basic needs with no investment and can potentially solve PKCS#11 requirements with small investment. > > > 4.5. Interfaces: > > > > The libxslt[4] library is relocated to /lib but otherwise has > > the same status. > > > > The provided commands and underlying crypto provider are > > Volatile and could change based on new bits from the upstream > > community and changes to the Solaris selection of crypto > > providers. > > It strikes me that /usr/bin/xmlsec1-config should have the same > commitment level as the API, i.e., Uncommitted in this case. (Also, I > thought that -config commands nowadays were being deprecated in favor of > pc files. Are there autoconf scripts that depend on xmlsec1-config?) I don't know. I think I felt it prudent to provide whatever libxml2 and xslt provide, but I am on vacation and have no Solaris system handy to verify this. Thanks, Will > > Nico From will.young@sun.com Wed Jul 8 13:25:04 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 n68KP428015139 for ; Wed, 8 Jul 2009 13:25:04 -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.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n68KP0VW013037 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 13:25:04 -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 <0KMH00017CPQEG00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:25:02 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00H7HCPQAD80@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:25:02 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n68KP2Kj015230 for ; Wed, 08 Jul 2009 20:25:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMH00D00CFVU500@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:25:02 -0600 (MDT) Received: from lumpy.local ([unknown] [71.192.37.217]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH001XGCPLTH90@mail-amer.sun.com>; Wed, 08 Jul 2009 14:24:59 -0600 (MDT) Date: Wed, 08 Jul 2009 16:24:10 -0400 From: Will Young Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <20090708201931.GT1064@Sun.COM> Sender: William.Young@sun.com To: Nicolas Williams Cc: Kais.Belgaied@sun.com, Brian Utterback , PSARC-ext , William Young Message-id: <1247084650.5231.18.camel@lumpy> MIME-version: 1.0 X-Mailer: Evolution 2.6.3 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> Status: RO Content-Length: 899 On Wed, 2009-07-08 at 15:19 -0500, Nicolas Williams wrote: > On Wed, Jul 08, 2009 at 04:06:53PM -0400, Will Young wrote: > > On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote: > > > so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? > > > > > > doesn't this case require an ARC contract against PSARC/2003/500 for the > > > import of OpenSSL ? > > > > I no longer saw a need for a contract as of the integration of: > > 6806387 Move OpenSSL from ON to SFW > > The move alone could not imply a change of interface stability. > PSARC/2006/555 (Move OpenSSL to /usr) did not change the interface > stability of any part of OpenSSL (see section 4.5 of the one-pager). It's my understanding that within one gate no contract is needed (updating any element of the gate one is responsible for examining/updating related elements.) Is that not accurate? Will > > Nico From Alan.Coopersmith@sun.com Wed Jul 8 13:27:07 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 n68KR6RM015155 for ; Wed, 8 Jul 2009 13:27:06 -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 n68KR2wv013560 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 21:27:05 +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 <0KMH00G0DCT46W00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 13:27:04 -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 <0KMH00F2SCT33ED0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 13:27:03 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n68KR3El024078 for ; Wed, 08 Jul 2009 13:27: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 <0KMH00F00CPSH400@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 13:27:03 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH00C0QCT3TZI0@fe-sfbay-10.sun.com>; Wed, 08 Jul 2009 13:27:03 -0700 (PDT) Date: Wed, 08 Jul 2009 13:27:03 -0700 From: Alan Coopersmith Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <20090708201931.GT1064@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Nicolas Williams Cc: Will Young , Kais.Belgaied@sun.com, Brian Utterback , PSARC-ext , William Young Message-id: <4A550117.5030402@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1001 Nicolas Williams wrote: > On Wed, Jul 08, 2009 at 04:06:53PM -0400, Will Young wrote: >> On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote: >>> so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? >>> >>> doesn't this case require an ARC contract against PSARC/2003/500 for the >>> import of OpenSSL ? >> I no longer saw a need for a contract as of the integration of: >> 6806387 Move OpenSSL from ON to SFW > > The move alone could not imply a change of interface stability. But it does change the need for contracts. At least LSARC, and I thought PSARC as well, had accepted the precedent that Volatile interfaces were similar to Consolidation Private, only needing contracts when consumed outside the Consolidation, to avoid overwhelming the ARC's and engineers with dozens of contracts between different parts of consolidations like JDS, SFW, & X. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Nicolas.Williams@sun.com Wed Jul 8 13:38:58 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 n68KcwCO015644 for ; Wed, 8 Jul 2009 13:38:58 -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 n68KcuPW004797; Wed, 8 Jul 2009 14:38:57 -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 <0KMH0010JDCXZL00@brm-avmta-1.central.sun.com>; Wed, 08 Jul 2009 14:38:57 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00HVEDCWAF90@brm-avmta-1.central.sun.com>; Wed, 08 Jul 2009 14:38:56 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n68KaBR0001960; Wed, 08 Jul 2009 15:36:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n68KaBu0001959; Wed, 08 Jul 2009 15:36:11 -0500 (CDT) Date: Wed, 08 Jul 2009 15:36:11 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <1247084507.5231.15.camel@lumpy> To: Will Young Cc: Brian Utterback , PSARC-ext , William Young Message-id: <20090708203610.GU1064@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: <4A4B8281.3030601@sun.com> <20090708192503.GS1064@Sun.COM> <1247084507.5231.15.camel@lumpy> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2372 On Wed, Jul 08, 2009 at 04:21:47PM -0400, Will Young wrote: > On Wed, 2009-07-08 at 14:25 -0500, Nicolas Williams wrote: > > On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote: > > > A future ARC case could also switch us from using the OpenSSL > > > module to a new module with more direct access to the crypto framework. > > > Such a module would first need to be integrated in the community > > > project. > > > > What sort of module are we talking? Where would it plug in? There > > already is a way to access the Solaris crypto framework more directly > > than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly. > [...] I didn't mean to get into a design discussion. I meant that it's not clear what "switch...from using the OpenSSL module to a new module" meant. But I think it was a thinko on my part: I think you implied that libxmlsec has "modules" and currently the only one is for using OpenSSL. > > Sounds like libxmlsec could use KMF. You should talk to the KMF project > > team. > > A kmf/PKCS#11 hybrid module seems to be the only possibility aside from > OpenSSL or NSS that adequately covers the needed crypto operations and > certificate management operations. The nice thing about KMF is that it gives you a single interface to OpenSSL and NSS keystores. > But this combination also doesn't solve anything for all store types so > its is not a worthwhile immediate investment. I don't understand this last statement. > Meanwhile, OpenSSL solves the basic needs with no investment and can > potentially solve PKCS#11 requirements with small investment. Indeed. > > It strikes me that /usr/bin/xmlsec1-config should have the same > > commitment level as the API, i.e., Uncommitted in this case. (Also, I > > thought that -config commands nowadays were being deprecated in favor of > > pc files. Are there autoconf scripts that depend on xmlsec1-config?) > > I don't know. I think I felt it prudent to provide whatever libxml2 > and xslt provide, but I am on vacation and have no Solaris system handy > to verify this. The thing is that xyz-config programs are typically used in autoconf scripts (think ./configure) to auto-detect 'xyz' and compiler/linker flags needed to build against 'xyz'. On second thought, I think it's best not to worry about this (you might replace it with a .pc file later). From Nicolas.Williams@Sun.COM Wed Jul 8 13:39:43 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 n68Kdgqu015710 for ; Wed, 8 Jul 2009 13:39:42 -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 n68KdRBT016070; Thu, 9 Jul 2009 04:39:37 +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 <0KMH00I01DE0KN00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Jul 2009 13:39:36 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00ITODDZBX00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Jul 2009 13:39:36 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n68KaleR001966; Wed, 08 Jul 2009 15:36:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n68KalPs001965; Wed, 08 Jul 2009 15:36:47 -0500 (CDT) Date: Wed, 08 Jul 2009 15:36:47 -0500 From: Nicolas Williams Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <1247084650.5231.18.camel@lumpy> To: Will Young Cc: Kais.Belgaied@Sun.COM, Brian Utterback , PSARC-ext , William Young Message-id: <20090708203647.GV1064@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: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1016 On Wed, Jul 08, 2009 at 04:24:10PM -0400, Will Young wrote: > On Wed, 2009-07-08 at 15:19 -0500, Nicolas Williams wrote: > > On Wed, Jul 08, 2009 at 04:06:53PM -0400, Will Young wrote: > > > On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote: > > > > so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? > > > > > > > > doesn't this case require an ARC contract against PSARC/2003/500 for the > > > > import of OpenSSL ? > > > > > > I no longer saw a need for a contract as of the integration of: > > > 6806387 Move OpenSSL from ON to SFW > > > > The move alone could not imply a change of interface stability. > > PSARC/2006/555 (Move OpenSSL to /usr) did not change the interface > > stability of any part of OpenSSL (see section 4.5 of the one-pager). > > It's my understanding that within one gate no contract is needed > (updating any element of the gate one is responsible for > examining/updating related elements.) Is that not accurate? Ah, sorry, another thinko on my part. From gdamore@sun.com Wed Jul 8 13:48:55 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 n68KmsZW016442 for ; Wed, 8 Jul 2009 13:48:54 -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 n68KmomE027448 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 21:48:53 +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 <0KMH00307DTG1700@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:48:52 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00H9ODTFACE0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:48:51 -0600 (MDT) 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 n68KmpS6024467 for ; Wed, 08 Jul 2009 13:48:51 -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 <0KMH00J00DSUZM00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 13:48:51 -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 <0KMH00IXADTD9A70@fe-sfbay-10.sun.com>; Wed, 08 Jul 2009 13:48:49 -0700 (PDT) Date: Wed, 08 Jul 2009 13:48:49 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <20090708203647.GV1064@Sun.COM> Sender: Garrett.Damore@sun.com To: Nicolas Williams Cc: Will Young , Kais.Belgaied@sun.com, Brian Utterback , PSARC-ext , William Young Message-id: <4A550631.9060301@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: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> <20090708203647.GV1064@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1633 Nicolas Williams wrote: > On Wed, Jul 08, 2009 at 04:24:10PM -0400, Will Young wrote: > >> On Wed, 2009-07-08 at 15:19 -0500, Nicolas Williams wrote: >> >>> On Wed, Jul 08, 2009 at 04:06:53PM -0400, Will Young wrote: >>> >>>> On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote: >>>> >>>>> so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? >>>>> >>>>> doesn't this case require an ARC contract against PSARC/2003/500 for the >>>>> import of OpenSSL ? >>>>> >>>> I no longer saw a need for a contract as of the integration of: >>>> 6806387 Move OpenSSL from ON to SFW >>>> >>> The move alone could not imply a change of interface stability. >>> PSARC/2006/555 (Move OpenSSL to /usr) did not change the interface >>> stability of any part of OpenSSL (see section 4.5 of the one-pager). >>> >> It's my understanding that within one gate no contract is needed >> (updating any element of the gate one is responsible for >> examining/updating related elements.) Is that not accurate? >> > > Ah, sorry, another thinko on my part. > Actually, it depends. A contract would be required if the interfaces are "Project Private", even within the same consolidation. If the interfaces are "Consolidation Private", then yes, no contract would be required. Actually, with that last statement, its clear that moving a subsystem which has Consolidation Private interfaces to a new subsystem has *ARCHITECTURAL* impact. With that in mind, I hope such moves are properly reviewed at ARC. (Something for folks doing such moves to consider...) - Garrett From Kais.Belgaied@sun.com Wed Jul 8 14:03:31 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 n68L3V1F017785 for ; Wed, 8 Jul 2009 14:03:31 -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 n68L3R6f004753; Wed, 8 Jul 2009 14:03:30 -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 <0KMH0041DEHSJZ00@brm-avmta-1.central.sun.com>; Wed, 08 Jul 2009 15:03:28 -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 <0KMH00HYVEHSADC0@brm-avmta-1.central.sun.com>; Wed, 08 Jul 2009 15:03:28 -0600 (MDT) Received: from [10.5.238.201] (sr2-opensolaris.SFBay.Sun.COM [10.5.238.201]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n68L3RQm225647; Wed, 08 Jul 2009 14:03:27 -0700 (PDT) Date: Wed, 08 Jul 2009 14:03:17 -0700 From: Kais Belgaied Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <20090708203647.GV1064@Sun.COM> To: Nicolas Williams Cc: Will Young , Brian Utterback , PSARC-ext , William Young Reply-to: Kais.Belgaied@sun.com Message-id: <4A550995.4070403@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tZQ/gkiKkQuoH9zPbBMvCQ)" X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> <20090708203647.GV1064@Sun.COM> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 4019 This is a multi-part message in MIME format. --Boundary_(ID_tZQ/gkiKkQuoH9zPbBMvCQ) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT On 07/08/09 13:36, Nicolas Williams wrote: > On Wed, Jul 08, 2009 at 04:24:10PM -0400, Will Young wrote: > >> On Wed, 2009-07-08 at 15:19 -0500, Nicolas Williams wrote: >> >>> On Wed, Jul 08, 2009 at 04:06:53PM -0400, Will Young wrote: >>> >>>> On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote: >>>> >>>>> so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? >>>>> >>>>> doesn't this case require an ARC contract against PSARC/2003/500 for the >>>>> import of OpenSSL ? >>>>> >>>> I no longer saw a need for a contract as of the integration of: >>>> 6806387 Move OpenSSL from ON to SFW >>>> >>> The move alone could not imply a change of interface stability. >>> PSARC/2006/555 (Move OpenSSL to /usr) did not change the interface >>> stability of any part of OpenSSL (see section 4.5 of the one-pager). >>> >> It's my understanding that within one gate no contract is needed >> (updating any element of the gate one is responsible for >> examining/updating related elements.) Is that not accurate? >> well, looking back at PSARC/2003/500. it exports the interfaces as Project Private not Consolidation Private. So the contract would still be needed. Alternatively, the supplier of PSARC/2003/500 can judge if it is the right thing for the openssl libs' visibility to be upgraded to consolidation private. Kais. > > Ah, sorry, another thinko on my part. > > --Boundary_(ID_tZQ/gkiKkQuoH9zPbBMvCQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT On 07/08/09 13:36, Nicolas Williams wrote: 
On Wed, Jul 08, 2009 at 04:24:10PM -0400, Will Young wrote:
  
On Wed, 2009-07-08 at 15:19 -0500, Nicolas Williams wrote:
    
On Wed, Jul 08, 2009 at 04:06:53PM -0400, Will Young wrote:
      
On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote:
        
so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ?

doesn't this case require an ARC contract against PSARC/2003/500 for the 
import of OpenSSL ?
          
I no longer saw a need for a contract as of the integration of:
6806387 Move OpenSSL from ON to SFW
        
The move alone could not imply a change of interface stability.
PSARC/2006/555 (Move OpenSSL to /usr) did not change the interface
stability of any part of OpenSSL (see section 4.5 of the one-pager).
      
	It's my understanding that within one gate no contract is needed
(updating any element of the gate one is responsible for
examining/updating related elements.)  Is that not accurate?


well, looking back at  PSARC/2003/500. it exports the interfaces as Project Private not Consolidation Private.
So the contract would still be needed.

Alternatively, the supplier of PSARC/2003/500 can judge if it is the right thing for
the openssl libs' visibility  to be upgraded to  consolidation private.

    Kais.

Ah, sorry, another thinko on my part.

--Boundary_(ID_tZQ/gkiKkQuoH9zPbBMvCQ)-- From will.young@sun.com Wed Jul 8 14:05:06 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 n68L55ct017890 for ; Wed, 8 Jul 2009 14:05:05 -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 n68L52u0029160 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Jul 2009 05:05:04 +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 <0KMH0001BEKEEB00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:05:02 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00I8EEKDBXE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 14:05:01 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n68L50cI003166 for ; Wed, 08 Jul 2009 21:05:00 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMH00500DIHSO00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 15:05:00 -0600 (MDT) Received: from lumpy.local ([unknown] [71.192.37.217]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH0010QEK352C0@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 15:04:53 -0600 (MDT) Date: Wed, 08 Jul 2009 17:04:04 -0400 From: Will Young Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <20090708203610.GU1064@Sun.COM> Sender: William.Young@sun.com To: Nicolas Williams Cc: Brian Utterback , PSARC-ext , William Young Message-id: <1247087044.5231.40.camel@lumpy> MIME-version: 1.0 X-Mailer: Evolution 2.6.3 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> <20090708192503.GS1064@Sun.COM> <1247084507.5231.15.camel@lumpy> <20090708203610.GU1064@Sun.COM> Status: RO Content-Length: 1362 On Wed, 2009-07-08 at 15:36 -0500, Nicolas Williams wrote: > On Wed, Jul 08, 2009 at 04:21:47PM -0400, Will Young wrote: > > On Wed, 2009-07-08 at 14:25 -0500, Nicolas Williams wrote: ... > > > > A kmf/PKCS#11 hybrid module seems to be the only possibility aside from > > OpenSSL or NSS that adequately covers the needed crypto operations and > > certificate management operations. > > The nice thing about KMF is that it gives you a single interface to > OpenSSL and NSS keystores. > > > But this combination also doesn't solve anything for all store types so > > its is not a worthwhile immediate investment. > > I don't understand this last statement. KMF gives nice capabilities for certificate operations, i.e. to determine the trust of a cert given a store of any type. But it really has crypto operations that are also geared towards certificate management purposes. I.e. atomic since certificates are small, not so many algorithms since no one wants an odd one for their certs. So once one has done one's cert operations and is then ready to use the key, one needs to drop to a specific underlying provider to do operations xmlsec requires with the key. This means either an implementation of crypto for each keystore type or key extraction and the assumption that key extraction will always be allowed by the non-default keystores. -Will From Kais.Belgaied@sun.com Wed Jul 8 14:36:50 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 n68Laneq018804 for ; Wed, 8 Jul 2009 14:36:50 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n68LafDf028935; Wed, 8 Jul 2009 22:36:46 +0100 (BST) 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 <0KMH00J0XG19IH00@nwk-avmta-2.sfbay.sun.com>; Wed, 08 Jul 2009 14:36:45 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMH00EW6G18LI40@nwk-avmta-2.sfbay.sun.com>; Wed, 08 Jul 2009 14:36:44 -0700 (PDT) Received: from [10.5.238.201] (sr2-opensolaris.SFBay.Sun.COM [10.5.238.201]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n68Laixq231401; Wed, 08 Jul 2009 14:36:44 -0700 (PDT) Date: Wed, 08 Jul 2009 14:36:33 -0700 From: Kais Belgaied Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <4A550631.9060301@sun.com> To: "Garrett D'Amore" Cc: Nicolas Williams , Will Young , Brian Utterback , PSARC-ext , William Young Reply-to: Kais.Belgaied@sun.com Message-id: <4A551161.7020601@Sun.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 References: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> <20090708203647.GV1064@Sun.COM> <4A550631.9060301@sun.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 718 On 07/08/09 13:48, Garrett D'Amore wrote: > > Actually, it depends. A contract would be required if the interfaces > are "Project Private", even within the same consolidation. If the > interfaces are "Consolidation Private", then yes, no contract would be > required. > > Actually, with that last statement, its clear that moving a subsystem > which has Consolidation Private interfaces to a new subsystem has > *ARCHITECTURAL* impact. With that in mind, I hope such moves are > properly reviewed at ARC. (Something for folks doing such moves to > consider...) yep. Also, I haven't seen an answer to my other question about dependency on a particular version of openssl libs. Kais > > - Garrett > > > From will.young@sun.com Wed Jul 8 15:19:07 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 n68MJ7E9020812 for ; Wed, 8 Jul 2009 15:19:07 -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 n68MJ46h029246 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 8 Jul 2009 15:19:07 -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 <0KMH00M01HZABI00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 15:18:46 -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 <0KMH00EWOHZALP70@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 15:18:46 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n68MIjLW024597 for ; Wed, 08 Jul 2009 22:18:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMH00200HUS3800@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 08 Jul 2009 16:18:45 -0600 (MDT) Received: from lumpy.local ([unknown] [71.192.37.217]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMH0052OHZ8Y870@mail-amer.sun.com>; Wed, 08 Jul 2009 16:18:45 -0600 (MDT) Date: Wed, 08 Jul 2009 18:17:56 -0400 From: Will Young Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <4A551161.7020601@Sun.COM> Sender: William.Young@sun.com To: Kais.Belgaied@sun.com Cc: "Garrett D'Amore" , Nicolas Williams , Brian Utterback , PSARC-ext , William Young Message-id: <1247091476.5231.72.camel@lumpy> MIME-version: 1.0 X-Mailer: Evolution 2.6.3 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> <20090708203647.GV1064@Sun.COM> <4A550631.9060301@sun.com> <4A551161.7020601@Sun.COM> Status: RO Content-Length: 935 On Wed, 2009-07-08 at 14:36 -0700, Kais Belgaied wrote: > On 07/08/09 13:48, Garrett D'Amore wrote: > > > > Actually, it depends. A contract would be required if the interfaces > > are "Project Private", even within the same consolidation. If the > > interfaces are "Consolidation Private", then yes, no contract would be > > required. > > > > Actually, with that last statement, its clear that moving a subsystem > > which has Consolidation Private interfaces to a new subsystem has > > *ARCHITECTURAL* impact. With that in mind, I hope such moves are > > properly reviewed at ARC. (Something for folks doing such moves to > > consider...) > > yep. > > Also, I haven't seen an answer to my other question about dependency on > a particular version of openssl libs. It requires a 0.9.8 version or it can work with either 0.9.7 or 0.9.6 with degraded capabilities. -Will > > Kais > > > > > - Garrett > > > > > > > From Darren.Moffat@sun.com Thu Jul 9 01:48:06 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 n698m52p010746 for ; Thu, 9 Jul 2009 01:48:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n698lx2P000702 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Jul 2009 16:48:04 +0800 (SGT) 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 <0KMI00K09B42OZ00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 01:48:02 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMI0089LB41VHB0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 01:48:02 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n698m10c000288 for ; Thu, 09 Jul 2009 08:48:01 +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 <0KMI0050090GJ900@fe-emea-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 09:48:01 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMI00J1RB3V70A0@fe-emea-10.sun.com>; Thu, 09 Jul 2009 09:47:55 +0100 (BST) Date: Thu, 09 Jul 2009 09:47:55 +0100 From: Darren J Moffat Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <1247084650.5231.18.camel@lumpy> Sender: Darren.Moffat@sun.com To: Will Young Cc: Nicolas Williams , Kais.Belgaied@sun.com, Brian Utterback , William Young , PSARC-ext Message-id: <4A55AEBB.3030107@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: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 1191 Will Young wrote: > On Wed, 2009-07-08 at 15:19 -0500, Nicolas Williams wrote: >> On Wed, Jul 08, 2009 at 04:06:53PM -0400, Will Young wrote: >>> On Wed, 2009-07-08 at 12:11 -0700, Kais Belgaied wrote: >>>> so, any dependency on a particular version of OpenSSL's lib{crypto,ssl} ? >>>> >>>> doesn't this case require an ARC contract against PSARC/2003/500 for the >>>> import of OpenSSL ? >>> I no longer saw a need for a contract as of the integration of: >>> 6806387 Move OpenSSL from ON to SFW >> The move alone could not imply a change of interface stability. >> PSARC/2006/555 (Move OpenSSL to /usr) did not change the interface >> stability of any part of OpenSSL (see section 4.5 of the one-pager). > > It's my understanding that within one gate no contract is needed > (updating any element of the gate one is responsible for > examining/updating related elements.) Is that not accurate? Only true of the word "Consolidation" is part of the interface taxonomy assigned and that is not the case for OpenSSL. We plan to remove the ARC contract requirement from OpenSSL once it reaches version 1.0.0 (which should be soon since it is currently in Beta 2). -- Darren J Moffat From Wyllys.Ingersoll@sun.com Thu Jul 9 05:30:49 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 n69CUmu1017656 for ; Thu, 9 Jul 2009 05:30:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n69CUjgj003002 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Thu, 9 Jul 2009 13:30:48 +0100 (BST) 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 <0KMI00C0FLFAG700@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 05:30:46 -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 <0KMI0017ILF9MQC0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 05:30:45 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n69CUjKk019913 for ; Thu, 09 Jul 2009 12:30:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMI00A00LDV0Z00@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 06:30:45 -0600 (MDT) Received: from [192.168.1.50] (pool-173-72-131-209.clppva.fios.verizon.net [173.72.131.209]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMI00DJ0LF82B30@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Thu, 09 Jul 2009 06:30:45 -0600 (MDT) Date: Thu, 09 Jul 2009 08:30:44 -0400 From: Wyllys Ingersoll Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <1247087044.5231.40.camel@lumpy> Sender: Wyllys.Ingersoll@sun.com To: Will Young Cc: Nicolas Williams , PSARC-ext , Brian Utterback , William Young Message-id: <4A55E2F4.8070900@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: <4A4B8281.3030601@sun.com> <20090708192503.GS1064@Sun.COM> <1247084507.5231.15.camel@lumpy> <20090708203610.GU1064@Sun.COM> <1247087044.5231.40.camel@lumpy> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1759 Will Young wrote: > On Wed, 2009-07-08 at 15:36 -0500, Nicolas Williams wrote: >> On Wed, Jul 08, 2009 at 04:21:47PM -0400, Will Young wrote: >>> On Wed, 2009-07-08 at 14:25 -0500, Nicolas Williams wrote: > ... >>> A kmf/PKCS#11 hybrid module seems to be the only possibility aside from >>> OpenSSL or NSS that adequately covers the needed crypto operations and >>> certificate management operations. >> The nice thing about KMF is that it gives you a single interface to >> OpenSSL and NSS keystores. >> >>> But this combination also doesn't solve anything for all store types so >>> its is not a worthwhile immediate investment. >> I don't understand this last statement. > > KMF gives nice capabilities for certificate operations, i.e. to > determine the trust of a cert given a store of any type. But it really > has crypto operations that are also geared towards certificate > management purposes. I.e. atomic since certificates are small, not so > many algorithms since no one wants an odd one for their certs. > > So once one has done one's cert operations and is then ready to use the > key, one needs to drop to a specific underlying provider to do > operations xmlsec requires with the key. This means either an > implementation of crypto for each keystore type or key extraction and > the assumption that key extraction will always be allowed by the > non-default keystores. > -Will KMF was not designed to offer a full set of crypto operations, just those that would be relevant when dealing with PKI objects - X.509 certs, RSA/DSA keys, CRLs. You can use KMF though to fetch a key handle from NSS, PKCS11, or OpenSSL and then use that key handle to do further crypto using the crypto API appropriate for the keystore. -Wyllys From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Fri Jul 10 07:16:02 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 n6AEG1pr001354 for ; Fri, 10 Jul 2009 07:16:02 -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.2) with ESMTP id n6AEFodt015850 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 10 Jul 2009 08:16:01 -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 <0KMK0001JKYOPF00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Jul 2009 07:16:00 -0700 (PDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMK00HC3KYMS660@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Jul 2009 07:15:58 -0700 (PDT) Received: from relay44i.sun.com ([192.5.209.118]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6AEDcJi023017 for ; Fri, 10 Jul 2009 14:15:57 +0000 (GMT) Received: from mmp43es.mmp.us.syntegra.com ([160.41.221.12] [160.41.221.12]) by relay44i.sun.com with ESMTP id BT-MMP-250557 for PSARC-ext@sun.com; Fri, 10 Jul 2009 14:15:55 +0000 (Z) Received: from relay43i.sun.com (relay43i.sun.com [192.5.209.74]) by mmp43es.mmp.us.syntegra.com with ESMTP id BT-MMP-25182359 for PSARC-ext@sun.com; Fri, 10 Jul 2009 14:15:54 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay4i.sun.com with ESMTP id BT-MMP-16402511 for PSARC-ext@sun.com; Fri, 10 Jul 2009 14:15:06 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id C663894184; Fri, 10 Jul 2009 16:14:59 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 1D7819417B; Fri, 10 Jul 2009 16:14:59 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n6AEEs5K029232; Fri, 10 Jul 2009 16:14:54 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 16:14:55 +0200 Date: Fri, 10 Jul 2009 16:14:54 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <20090708192503.GS1064@Sun.COM> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Nicolas.Williams@sun.com, Brian.Utterback@sun.com Cc: William.Young@sun.com, PSARC-ext@sun.com Message-id: <4a574cde.dnzlTmXLWgCnLjqG%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 0.810sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A4B8281.3030601@sun.com> <20090708192503.GS1064@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 10 Jul 2009 14:14:55.0094 (UTC) FILETIME=[CC65F160:01CA0168] Status: RO Content-Length: 1104 Nicolas Williams wrote: > On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote: > > A future ARC case could also switch us from using the OpenSSL > > module to a new module with more direct access to the crypto framework. > > Such a module would first need to be integrated in the community > > project. > > What sort of module are we talking? Where would it plug in? There > already is a way to access the Solaris crypto framework more directly > than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly. In order to make Solaris useable out of the box for such use case, we first would need to get a working "libpcsclite". What's currently delivered may support some of the Sun made java cards but it does not allow to use the standard chipcards. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Darren.Moffat@sun.com Fri Jul 10 07:29:44 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 n6AEThJX001392 for ; Fri, 10 Jul 2009 07:29:43 -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 n6AETXTQ017384 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 10 Jul 2009 15:29:42 +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 <0KMK00A0DLLH7G00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Jul 2009 08:29:41 -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 <0KMK009A4LLBVH00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Jul 2009 08:29:41 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6AETZRC003900 for ; Fri, 10 Jul 2009 14:29:35 +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 <0KMK00500LFP2500@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Jul 2009 15:29:34 +0100 (BST) Received: from [129.156.173.199] ([unknown] [129.156.173.199]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMK0052FLKR9GF0@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Jul 2009 15:29:15 +0100 (BST) Date: Fri, 10 Jul 2009 15:29:15 +0100 From: Darren J Moffat Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <4a574cde.dnzlTmXLWgCnLjqG%Joerg.Schilling@fokus.fraunhofer.de> Sender: Darren.Moffat@sun.com To: Joerg Schilling Cc: Nicolas.Williams@sun.com, Brian.Utterback@sun.com, William.Young@sun.com, PSARC-ext@sun.com Message-id: <4A57503B.3030907@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: <4A4B8281.3030601@sun.com> <20090708192503.GS1064@Sun.COM> <4a574cde.dnzlTmXLWgCnLjqG%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.18 (X11/20090127) Status: RO Content-Length: 962 Joerg Schilling wrote: > Nicolas Williams wrote: > >> On Wed, Jul 01, 2009 at 11:36:33AM -0400, Brian Utterback wrote: >>> A future ARC case could also switch us from using the OpenSSL >>> module to a new module with more direct access to the crypto framework. >>> Such a module would first need to be integrated in the community >>> project. >> What sort of module are we talking? Where would it plug in? There >> already is a way to access the Solaris crypto framework more directly >> than via the OpenSSL PKCS#11 engine: just use libpkcs11 directly. > > In order to make Solaris useable out of the box for such use case, we first > would need to get a working "libpcsclite". What's currently delivered may > support some of the Sun made java cards but it does not allow to use the > standard chipcards. What is currently delivered is also EOF and I'm currently in prelim codereview to remove it. -- Darren J Moffat From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Fri Jul 10 07:33:08 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 n6AEX7Fc001427 for ; Fri, 10 Jul 2009 07:33:07 -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 n6AEWuvR025096 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 10 Jul 2009 08:33:06 -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 <0KMK00D17LR5S100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Jul 2009 07:33:05 -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 <0KMK00HMKLR5N960@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 10 Jul 2009 07:33:05 -0700 (PDT) Received: from relay15i.sun.com (ip125.net129179-4.block1.us.syntegra.com [129.179.4.125]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n6AETcb6026932 for ; Fri, 10 Jul 2009 14:33:04 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay15i.sun.com with ESMTP id BT-MMP-295387 for PSARC-ext@sun.com; Fri, 10 Jul 2009 14:32:55 +0000 (Z) Received: from relay15i.sun.com (relay15i.sun.com [129.179.4.125]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-2275899 for PSARC-ext@sun.com; Fri, 10 Jul 2009 14:32:53 +0000 (Z) Received: from relay01-haj2.antispameurope.com ([83.246.65.51] [83.246.65.51]) by relay1i.sun.com with ESMTP id BT-MMP-8574468 for PSARC-ext@sun.com; Fri, 10 Jul 2009 14:32:45 +0000 (Z) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 7CF3E94174; Fri, 10 Jul 2009 16:31:53 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id C837194164; Fri, 10 Jul 2009 16:31:52 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n6AEVr1x029630; Fri, 10 Jul 2009 16:31:53 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 16:31:53 +0200 Date: Fri, 10 Jul 2009 16:31:53 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: PSARC/2009/374 libxmlsec In-reply-to: <4A57503B.3030907@Sun.COM> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Darren.Moffat@sun.com Cc: William.Young@sun.com, PSARC-ext@sun.com, Nicolas.Williams@sun.com, Brian.Utterback@sun.com Message-id: <4a5750d9.QunZ9RFLvn3nALjV%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 2.014sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <4A4B8281.3030601@sun.com> <20090708192503.GS1064@Sun.COM> <4a574cde.dnzlTmXLWgCnLjqG%Joerg.Schilling@fokus.fraunhofer.de> <4A57503B.3030907@Sun.COM> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 10 Jul 2009 14:31:53.0549 (UTC) FILETIME=[2B71D7D0:01CA016B] Status: RO Content-Length: 869 Darren J Moffat wrote: > > In order to make Solaris useable out of the box for such use case, we first > > would need to get a working "libpcsclite". What's currently delivered may > > support some of the Sun made java cards but it does not allow to use the > > standard chipcards. > > What is currently delivered is also EOF and I'm currently in prelim > codereview to remove it. This sounds good! I am in hope that we will also get support for the springcard wireless reader so I can use it to talk to the planned new German eID card ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From William.Young@sun.com Mon Jul 13 14:55:16 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 n6DLtGA9008092 for ; Mon, 13 Jul 2009 14:55:16 -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.2) with ESMTP id n6DLtFFJ037015 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 13 Jul 2009 15:55:16 -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 <0KMQ00F03Q83N200@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 14:55:15 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMQ004YZQ83I8A0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 14:55:15 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6DLtEJO029462 for ; Mon, 13 Jul 2009 21:55:14 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMQ00700Q1UI600@mail-amer.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 15:55:14 -0600 (MDT) Received: from [192.168.3.200] (209-6-237-147.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.237.147]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMQ00EQNQ7LAQ30@mail-amer.sun.com>; Mon, 13 Jul 2009 15:55:14 -0600 (MDT) Date: Mon, 13 Jul 2009 17:54:55 -0400 From: Will Young Subject: PSARC/2009/374 libxmlsec contract for OpenSSL PSARC/2003/500 In-reply-to: <4A55AEBB.3030107@Sun.COM> Sender: William.Young@sun.com To: Anup Sekhar , Craig Payne Cc: Darren J Moffat , Will Young , Nicolas Williams , Kais.Belgaied@sun.com, Brian Utterback , PSARC-ext@sun.com Message-id: <4A5BAD2F.2040908@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: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> <4A55AEBB.3030107@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 7720 The following contract is based on the template from 2003/500. It requires an approval email from Anup (SUPPLIER) and Craig (CONSUMER). Thanks, Will @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 02/03/27] #ident "@(#)contract.txt 1.3 03/11/04 SMI" CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES 0. Number: PSARC/2003/500-38 1. This contract is between a SUPPLIER of INTERFACES and a CONSUMER of those INTERFACES, both of whom are entities within Sun Microsystems, Incorporated. 2. The SUPPLIER (definer and/or implementor) is identified by the following: Product or Bundle: Solaris WOS Consolidation: SFW Department or Group: Solaris Security Technology Group (SSTG) Bugtraq Category/SubCategory: solaris/solaris-crypto/openssl Responsible Manager: Anup Sekhar Contact: contract-2003-500@sun.com 3. The CONSUMER is identified by the following: Product or Bundle: Solaris WOS Consolidation: SFW Department or Group: Solaris Platform Security Bugtraq Category/SubCategory: solaris/library/libxmlsec Responsible Manager: Craig Payne Packages: SUNWlxmlsec SUNWlxmlsecr Contact: valex-core@sun.com 4. The INTERFACES are: The interfaces covered by this contract are limited to a subset of the C programming APIs that the OpenSSL communittee has choosen to document in man pages. It is the subset that the SUPPLIER beleives to be reasonably stable. That subset covers the following major subsystems: ASN1, BN, CRYPTO, EVP, HMAC, OpenSSL, PEM, PKCS7, PKCS12, RAND, SMIME, SSL, BIO, X509 In particular it does NOT cover "direct use" of encryption algorithm APIs outside of the EVP_ interfaces, eg do not call DES or AES except via EVP_Encrypt*() This contract does NOT cover the use of the openssl(1) command as an interface to be consumed. This contract does NOT cover any API or implementation artifact that does not have an OpenSSL delivered man page. OpenSSL Package names SUNWopenssl-include Unstable SUNWopenssl-libraries Unstable OpenSSL Library Location /lib/libcrypto.so Unstable /lib/libssl.so Unstable OpenSSL Headers Location /usr/include/openssl/*.h UnStable ASN1_ External BN_ External BIO_ External CRYPTO_ External EVP_ External HMAC External OpenSSL_ External OBJ_ External PEM_ External PKCS7 External PKCS12_ External RAND_ External SMIME_ External SSL_ External X509_ External 5. The ARC controlling these INTERFACES is: PSARC 6. The CASE describing these INTERFACES is: PSARC/2003/500 Note: this contract is not about a specific version of OpenSSL. It covers version 0.9.7d from PSARC/2003/500 and all subsequent versions. If a change in the OpenSSL interfaces requires an update of the contract then OpenSSL iteam will contact the consumer. 7. The following SPECIAL ARRANGEMENTS are made which modify the rules imposed by the stability levels listed in section 4 above: _NY 7a. Although the stability level doesn't normally restrict it, SUPPLIER promises to only modify INTERFACES in an incompatible way as follows: The SUPPLIER will modify the interfaces as needed by the evolution of OpenSSL releases shipped by on the www.openssl.org site. _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER will expose INTERFACES to a PARTNER, which is external to Sun, namely: Name of Company: Name of Department or Group within Company: Responsible Manager: _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER will import INTERFACES from a separate consolidation. This contract is only avaliable for CONSUMERS who deliver directly to the Solaris WOS. If a contract for a CONSUMER who is not part of the Solaris WOS is requested it will be dealt with by ARC and the SUPPLIER as a new contract. _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same consolidation, they will have simultaneous conversion to the new interfaces. The SUPPLIER will make a best effort to do most of the work, but the CONSUMER must be willing to supply resources to assist with modification/testing of their consuming code if necessary. Only a single version of the INTERFACES will be available at any one time. 8. If CONSUMER requires changes in INTERFACES, they must work with the OpenSSL communittee. The SUPPLIER is willing to assist with this process on a best effort to accommodate such changes. In general INTERFACE changes will not be made unless they come from the OpenSSL communittee. 9. N/A 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be handled as follows: The SUPPLIER will update the OpenSSL code base in the ON consolidation on an as needed basis. The trigger for these events is based on the externally defined schedule of the OpenSSL communittee. The SUPPLIER will inform the CONSUMER(S) of this change via the contract alias before filing the RTI for integration into ON. Note that it may be necessary to update INTERFACES (or more likely the implementations of them) with less than 5 working days notice. 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as follows: The SUPPLIER will NOT provide any assistance for use of the interfaces they are Externally defined and the SUPPLIER is not necessarily an expert in their use. 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as follows: The only documentation will be that provided by the OpenSSL communittee, it will be shipped in the SUNWopenssl-man package in the form of Solaris nroff man pages. 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be tested as follows: Before each intergration the OpenSSL test suites will be run. The standard for "PASS" is that the version in the ON gate should produce the same functionality as binaries built using the OpenSSL makefiles for the same processor architecture. 14. SUPPLIER and CONSUMER agree that this contract can be terminated as follows: The CONSUMER may choose to terminate this contract at any time by sending email to the contract-2003-500@sun.com alias. The SUPPLIER may terminate this contract only after giving suffient notice to the CONSUMER. Sufficient notice in the case of CONSUMERS that are external to the ON consolidation must take into account the Solaris WOS build schedule and its restrictions for change. The SUPPLIER will terminate this contract if the interfaces are ever reclassified to something other than External. 15. This contract is not valid until "signed" via agreement from the SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by this contract. E-mail agreement to the contract should be archived in the mail archive of CASE; verbal agreement to the contract should be noted in the meeting minutes. This contract remains valid until superseded or invalidated. For SUPPLIER: Date: For CONSUMER: Date: For ARC: Date: A copy of this contract shall be deposited in the CASE directory as "contract-" or in a "contracts" subdirectory. 16. (Not to be filled in until superseded or invalidated.) This contract was superseded or invalidated by CASE: For ARC: Date: From Craig.Payne@sun.com Mon Jul 13 18:32:03 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 n6E1W2QK019755 for ; Mon, 13 Jul 2009 18:32:03 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n6E1VtE6009381 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 14 Jul 2009 09:32:01 +0800 (SGT) 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 <0KMR0070309CD400@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 18:32:00 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMR0063509C8310@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 18:32:00 -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 n6E1VxrV001792 for ; Mon, 13 Jul 2009 18:31:59 -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 <0KMR009000546U00@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 13 Jul 2009 18:31:59 -0700 (PDT) Received: from [129.146.11.146] ([unknown] [129.146.11.146]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMR002TS09APF60@fe-sfbay-09.sun.com>; Mon, 13 Jul 2009 18:31:59 -0700 (PDT) Date: Mon, 13 Jul 2009 18:31:58 -0700 From: Craig Payne Subject: Re: PSARC/2009/374 libxmlsec contract for OpenSSL PSARC/2003/500 In-reply-to: <4A5BAD2F.2040908@sun.com> Sender: Craig.Payne@sun.com To: Will Young Cc: Anup Sekhar , Darren J Moffat , Will Young , Nicolas Williams , Kais.Belgaied@sun.com, Brian Utterback , PSARC-ext@sun.com Reply-to: Craig.Payne@sun.com Message-id: <4A5BE00E.6080808@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: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> <4A55AEBB.3030107@Sun.COM> <4A5BAD2F.2040908@sun.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090110) Status: RO Content-Length: 8657 Approved. cap On 07/13/09 14:54, Will Young wrote: > The following contract is based on the template from 2003/500. > It requires an approval email from Anup (SUPPLIER) and Craig (CONSUMER). > Thanks, > Will > > @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 > 02/03/27] > #ident "@(#)contract.txt 1.3 03/11/04 SMI" > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2003/500-38 > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the > following: > Product or Bundle: Solaris WOS > Consolidation: SFW > Department or Group: Solaris Security Technology Group (SSTG) > Bugtraq Category/SubCategory: solaris/solaris-crypto/openssl > Responsible Manager: Anup Sekhar > Contact: contract-2003-500@sun.com > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris WOS > Consolidation: SFW > Department or Group: Solaris Platform Security > Bugtraq Category/SubCategory: solaris/library/libxmlsec > Responsible Manager: Craig Payne > Packages: SUNWlxmlsec SUNWlxmlsecr > Contact: valex-core@sun.com > > 4. The INTERFACES are: > > The interfaces covered by this contract are limited to a subset > of the C programming APIs that the OpenSSL communittee has > choosen to document in man pages. It is the subset that the > SUPPLIER beleives to be reasonably stable. > > That subset covers the following major subsystems: > > ASN1, BN, CRYPTO, EVP, HMAC, OpenSSL, PEM, PKCS7, PKCS12, RAND, > SMIME, SSL, BIO, X509 > > In particular it does NOT cover "direct use" of encryption algorithm > APIs outside of the EVP_ interfaces, eg do not call DES or AES > except via EVP_Encrypt*() > > This contract does NOT cover the use of the openssl(1) command > as an interface to be consumed. > > This contract does NOT cover any API or implementation artifact > that does not have an OpenSSL delivered man page. > > OpenSSL Package names > > SUNWopenssl-include Unstable > SUNWopenssl-libraries Unstable > > OpenSSL Library Location > > /lib/libcrypto.so Unstable > /lib/libssl.so Unstable > > OpenSSL Headers Location > > /usr/include/openssl/*.h UnStable > > ASN1_ External > BN_ External > BIO_ External > CRYPTO_ External > EVP_ External > HMAC External > OpenSSL_ External > OBJ_ External > PEM_ External > PKCS7 External > PKCS12_ External > RAND_ External > SMIME_ External > SSL_ External > X509_ External > > > > 5. The ARC controlling these INTERFACES is: PSARC > > 6. The CASE describing these INTERFACES is: PSARC/2003/500 > > Note: this contract is not about a specific version of OpenSSL. It > covers > version 0.9.7d from PSARC/2003/500 and all subsequent versions. If a > change in the OpenSSL interfaces requires an update of the contract then > OpenSSL iteam will contact the consumer. > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > > _NY 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > The SUPPLIER will modify the interfaces as needed by the evolution > of OpenSSL releases shipped by on the www.openssl.org site. > > _N_ 7b. Although the stability level doesn't normally allow it, CONSUMER > will > expose INTERFACES to a PARTNER, which is external to Sun, namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _Y_ 7c. Although the stability level doesn't normally allow it, CONSUMER > will > import INTERFACES from a separate consolidation. > > This contract is only avaliable for CONSUMERS who deliver directly > to the Solaris WOS. > > If a contract for a CONSUMER who is not part of the Solaris WOS is > requested it will be dealt with by ARC and the SUPPLIER as a new > contract. > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) any > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > proposed new version, no later than the application for ARC > approval of the new version. > If SUPPLIER and CONSUMER are contained in the same > consolidation, they will have simultaneous conversion to the > new interfaces. > The SUPPLIER will make a best effort to do most of the work, but > the CONSUMER must be willing to supply resources to assist with > modification/testing of their consuming code if necessary. > > Only a single version of the INTERFACES will be available at any > one time. > > 8. If CONSUMER requires changes in INTERFACES, they must work with the > OpenSSL communittee. The SUPPLIER is willing to assist with this > process on a best effort to accommodate such changes. > In general INTERFACE changes will not be made unless they come from > the OpenSSL communittee. > > 9. N/A > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > The SUPPLIER will update the OpenSSL code base in the ON consolidation > on an as needed basis. The trigger for these events is based on the > externally defined schedule of the OpenSSL communittee. > > The SUPPLIER will inform the CONSUMER(S) of this change via the > contract alias before filing the RTI for integration into ON. > > Note that it may be necessary to update INTERFACES (or more likely > the implementations of them) with less than 5 working days notice. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > The SUPPLIER will NOT provide any assistance for use of the interfaces > they are Externally defined and the SUPPLIER is not necessarily an > expert in their use. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The only documentation will be that provided by the OpenSSL > communittee, it will be shipped in the SUNWopenssl-man package > in the form of Solaris nroff man pages. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > Before each intergration the OpenSSL test suites will be run. The > standard for "PASS" is that the version in the ON gate should produce > the same functionality as binaries built using the OpenSSL makefiles > for the same processor architecture. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated as > follows: > > The CONSUMER may choose to terminate this contract at any time by > sending email to the contract-2003-500@sun.com alias. > > The SUPPLIER may terminate this contract only after giving suffient > notice to the CONSUMER. Sufficient notice in the case of CONSUMERS > that are external to the ON consolidation must take into account the > Solaris WOS build schedule and its restrictions for change. > > The SUPPLIER will terminate this contract if the interfaces > are ever reclassified to something other than External. > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > For SUPPLIER: Date: > For CONSUMER: Date: > For ARC: Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: > -- Craig Payne Sr. Manager, Solaris Platform Security Direct: (510) 550-7413 Internal: x30176 From Anup.Sekhar@Sun.COM Tue Jul 14 13:12:18 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 n6EKCH4F010579 for ; Tue, 14 Jul 2009 13:12:17 -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 n6EKCGeO014191; Tue, 14 Jul 2009 21:12:16 +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 <0KMS00F01G4F3900@brm-avmta-1.central.sun.com>; Tue, 14 Jul 2009 14:12:15 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KMS007YOG4FAC70@brm-avmta-1.central.sun.com>; Tue, 14 Jul 2009 14:12:15 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n6EKCFcW008740; Tue, 14 Jul 2009 20:12:15 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KMS00G00FBY9I00@mail-amer.sun.com>; Tue, 14 Jul 2009 14:12:15 -0600 (MDT) Received: from dhcp-umpk17-107-175.SFBay.Sun.COM ([unknown] [129.146.107.175]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KMS00AXYG42U370@mail-amer.sun.com>; Tue, 14 Jul 2009 14:12:03 -0600 (MDT) Date: Tue, 14 Jul 2009 13:12:02 -0700 From: Anup Sekhar Subject: Re: PSARC/2009/374 libxmlsec contract for OpenSSL PSARC/2003/500 In-reply-to: <4A5BAD2F.2040908@sun.com> Sender: Anup.Sekhar@Sun.COM To: Will Young Cc: Craig Payne , Darren J Moffat , Will Young , Nicolas Williams , Kais.Belgaied@Sun.COM, Brian Utterback , PSARC-ext@Sun.COM, contract-2003-500@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.935.3) Content-type: text/plain; CHARSET=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A4B8281.3030601@sun.com> <4A54EF7A.7070007@Sun.COM> <1247083613.5231.0.camel@lumpy> <20090708201931.GT1064@Sun.COM> <1247084650.5231.18.camel@lumpy> <4A55AEBB.3030107@Sun.COM> <4A5BAD2F.2040908@sun.com> Status: RO Content-Length: 8193 I approve this contract as the SUPPLIER. Please have your case owner put the contract in the ARC materials directory for 2003/500. Anup On Jul 13, 2009, at 2:54 PM, Will Young wrote: > The following contract is based on the template from 2003/500. > It requires an approval email from Anup (SUPPLIER) and Craig > (CONSUMER). > Thanks, > Will > > @(#)contract 1.6 @(#) /shared/sac/arcARC-Templates/contract [1.6 > 02/03/27] > #ident "@(#)contract.txt 1.3 03/11/04 SMI" > > CONTRACT ALLOWING/REQUIRING SPECIAL ARRANGEMENTS FOR INTERFACES > > 0. Number: PSARC/2003/500-38 > > 1. This contract is between > a SUPPLIER of INTERFACES and > a CONSUMER of those INTERFACES, > both of whom are entities within Sun Microsystems, Incorporated. > > 2. The SUPPLIER (definer and/or implementor) is identified by the > following: > Product or Bundle: Solaris WOS > Consolidation: SFW > Department or Group: Solaris Security Technology Group (SSTG) > Bugtraq Category/SubCategory: solaris/solaris-crypto/openssl > Responsible Manager: Anup Sekhar > Contact: contract-2003-500@sun.com > > 3. The CONSUMER is identified by the following: > Product or Bundle: Solaris WOS > Consolidation: SFW > Department or Group: Solaris Platform Security > Bugtraq Category/SubCategory: solaris/library/libxmlsec > Responsible Manager: Craig Payne > Packages: SUNWlxmlsec SUNWlxmlsecr > Contact: valex-core@sun.com > > 4. The INTERFACES are: > > The interfaces covered by this contract are limited to a subset > of the C programming APIs that the OpenSSL communittee has > choosen to document in man pages. It is the subset that the > SUPPLIER beleives to be reasonably stable. > > That subset covers the following major subsystems: > > ASN1, BN, CRYPTO, EVP, HMAC, OpenSSL, PEM, PKCS7, PKCS12, RAND, > SMIME, SSL, BIO, X509 > > In particular it does NOT cover "direct use" of encryption algorithm > APIs outside of the EVP_ interfaces, eg do not call DES or AES > except via EVP_Encrypt*() > > This contract does NOT cover the use of the openssl(1) command > as an interface to be consumed. > > This contract does NOT cover any API or implementation artifact > that does not have an OpenSSL delivered man page. > > OpenSSL Package names > > SUNWopenssl-include Unstable > SUNWopenssl-libraries Unstable > > OpenSSL Library Location > > /lib/libcrypto.so Unstable > /lib/libssl.so Unstable > > OpenSSL Headers Location > > /usr/include/openssl/*.h UnStable > > ASN1_ External > BN_ External > BIO_ External > CRYPTO_ External > EVP_ External > HMAC External > OpenSSL_ External > OBJ_ External > PEM_ External > PKCS7 External > PKCS12_ External > RAND_ External > SMIME_ External > SSL_ External > X509_ External > > > > 5. The ARC controlling these INTERFACES is: PSARC > > 6. The CASE describing these INTERFACES is: PSARC/2003/500 > > Note: this contract is not about a specific version of OpenSSL. It > covers > version 0.9.7d from PSARC/2003/500 and all subsequent versions. If a > change in the OpenSSL interfaces requires an update of the > contract then > OpenSSL iteam will contact the consumer. > > 7. The following SPECIAL ARRANGEMENTS are made which modify the rules > imposed by the stability levels listed in section 4 above: > _NY 7a. Although the stability level doesn't normally restrict it, > SUPPLIER promises to only modify INTERFACES in an incompatible > way as follows: > > The SUPPLIER will modify the interfaces as needed by the > evolution > of OpenSSL releases shipped by on the www.openssl.org site. > > _N_ 7b. Although the stability level doesn't normally allow it, > CONSUMER will > expose INTERFACES to a PARTNER, which is external to Sun, > namely: > Name of Company: > Name of Department or Group within Company: > Responsible Manager: > > _Y_ 7c. Although the stability level doesn't normally allow it, > CONSUMER will > import INTERFACES from a separate consolidation. > > This contract is only avaliable for CONSUMERS who deliver > directly > to the Solaris WOS. > > If a contract for a CONSUMER who is not part of the Solaris > WOS is > requested it will be dealt with by ARC and the SUPPLIER as a new > contract. > > _Y_ 7d. If SUPPLIER decides to change (including replace or remove) > any > portion of the INTERFACES, SUPPLIER will notify CONSUMER of the > proposed new version, no later than the application for ARC > approval of the new version. > If SUPPLIER and CONSUMER are contained in the same > consolidation, they will have simultaneous conversion to the > new interfaces. > The SUPPLIER will make a best effort to do most of the work, but > the CONSUMER must be willing to supply resources to assist with > modification/testing of their consuming code if necessary. > > Only a single version of the INTERFACES will be available at any > one time. > > 8. If CONSUMER requires changes in INTERFACES, they must work with the > OpenSSL communittee. The SUPPLIER is willing to assist with this > process on a best effort to accommodate such changes. > In general INTERFACE changes will not be made unless they come from > the OpenSSL communittee. > > 9. N/A > > 10. SUPPLIER and CONSUMER agree that evolution of INTERFACES shall be > handled as follows: > > The SUPPLIER will update the OpenSSL code base in the ON > consolidation > on an as needed basis. The trigger for these events is based on the > externally defined schedule of the OpenSSL communittee. > > The SUPPLIER will inform the CONSUMER(S) of this change via the > contract alias before filing the RTI for integration into ON. > > Note that it may be necessary to update INTERFACES (or more likely > the implementations of them) with less than 5 working days notice. > > 11. SUPPLIER and CONSUMER agree that INTERFACES will be supported as > follows: > > The SUPPLIER will NOT provide any assistance for use of the > interfaces > they are Externally defined and the SUPPLIER is not necessarily an > expert in their use. > > 12. SUPPLIER and CONSUMER agree that INTERFACES will be documented as > follows: > > The only documentation will be that provided by the OpenSSL > communittee, it will be shipped in the SUNWopenssl-man package > in the form of Solaris nroff man pages. > > 13. SUPPLIER and CONSUMER agree that changes to the INTERFACES will be > tested as follows: > > Before each intergration the OpenSSL test suites will be run. The > standard for "PASS" is that the version in the ON gate should > produce > the same functionality as binaries built using the OpenSSL makefiles > for the same processor architecture. > > 14. SUPPLIER and CONSUMER agree that this contract can be terminated > as > follows: > > The CONSUMER may choose to terminate this contract at any time by > sending email to the contract-2003-500@sun.com alias. > > The SUPPLIER may terminate this contract only after giving suffient > notice to the CONSUMER. Sufficient notice in the case of CONSUMERS > that are external to the ON consolidation must take into account the > Solaris WOS build schedule and its restrictions for change. > > The SUPPLIER will terminate this contract if the interfaces > are ever reclassified to something other than External. > > 15. This contract is not valid until "signed" via agreement from the > SUPPLIER and CONSUMER, and approved by the ARC CASE referenced by > this contract. E-mail agreement to the contract should be archived > in the mail archive of CASE; verbal agreement to the contract > should be noted in the meeting minutes. This contract remains > valid until superseded or invalidated. > > For SUPPLIER: Date: > For CONSUMER: Date: > For ARC: Date: > > A copy of this contract shall be deposited in the CASE directory as > "contract-" or in a "contracts" subdirectory. > > 16. (Not to be filled in until superseded or invalidated.) > This contract was superseded or invalidated by CASE: > For ARC: Date: >