From wyllys@sac.sfbay.sun.com Wed Jul 14 07:40:17 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6EEeHh5002020 for ; Wed, 14 Jul 2010 07:40:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6EEeHRM020595; Wed, 14 Jul 2010 07:40:17 -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 <0L5J00507Y358400@brm-avmta-1.central.sun.com>; Wed, 14 Jul 2010 08:40:17 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L5J00BO4Y345CA0@brm-avmta-1.central.sun.com>; Wed, 14 Jul 2010 08:40:16 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [10.5.240.67]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o6EEeFmm022785; Wed, 14 Jul 2010 07:40:15 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6EEeFmY002014; Wed, 14 Jul 2010 07:40:15 -0700 (PDT) Received: (from wyllys@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o6EEeF9V002010; Wed, 14 Jul 2010 07:40:15 -0700 (PDT) Date: Wed, 14 Jul 2010 07:40:15 -0700 (PDT) From: Wyllys Ingersoll Subject: KMF Certificate Validation Enhancements [PSARC/2010/269 FastTrack timeout 07/21/2010] To: PSARC-ext@sun.com Cc: kmf-discuss@opensolaris.org Message-id: <201007141440.o6EEeF9V002010@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5049 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: KMF Certificate Validation Enhancements 1.2. Name of Document Author/Supplier: Author: Wyllys Ingersoll 1.3 Date of This Document: 14 July, 2010 4. Technical Description Project: KMF Certificate Validation Enhancements Submitter/Owner: Wyllys Ingersoll Release Binding: Micro/Patch Description: This project proposes some minor changes to the KMF policy engine when doing certificate validation. Currently, the KMF policy definition requires that a policy be configured which explicitly identifies a trust anchor(*) for doing certificate validation. The trust anchor certificate is uniquely identified by its Subject DN (distinguished name) and serial number. In practice, however, it is more correct (and easier to administer) to just have the KMF policy engine search for a certificate's parent by looking for a certificate with the SubjectName equal to the IssuerName of the certificate being validated. * The term "trust anchor" is not entirely accurate in this context. The KMF engine does not support following an entire chain of certificates to find the "root" (trust anchor), but rather just uses the direct parent of a certificate to perform the signature validation. Full PKIX (RFC 5280) path validation is a much more ambitious undertaking and is not in the budget at this time, nor have we had any customer requests for it. This project proposes allowing the "ta-name" value to be indicated as "SEARCH" to make the KMF policy engine search for a matching issuer certificate instead of explicitly naming one. This project also proposes modifying the default KMF policy defined in /etc/security/kmfpolicy.xml to use the new "SEARCH" value instead of ignoring the trust anchor check altogether. We are also removing the "ignore-date=TRUE" option from the default policy. NEW DEFAULT KMF POLICY: The only API affected by this change is the "kmf_validate_cert" function and currently there are no consumers of this API in the ON consolidation. There is a project in development (CR 6357779 SSHv2 x.509 support desired) that depends on this change in order for it to properly validate certificates. Documentation: The manpage for kmfcfg will be modified as follows: --- kmfcfg.1 Tue Jul 13 12:43:25 2010 +++ kmfcfg.1.new Tue Jul 13 12:56:30 2010 @@ -44,7 +44,7 @@ [ignore-unknown-eku=true|false] [ignore-trust-anchor=true|false] [validity-adjusttime=adjusttime] - [ta-name=trust anchor subject DN] + [ta-name=trust anchor subject DN | search] [ta-serial=trust anchor serial number] [ocsp-responder=URL] [ocsp-proxy=URL] @@ -333,8 +333,36 @@ User Commands kmfcfg(1) + ta-name= trust anchor subject DN | search + ta-name identifies the trust anchor to be used to + validate a certificate. The KMF policy engine does not + do full PKIX path validation, but rather just treats the + trust anchor as if it were the parent of the certificate + being validate. + If an explicit Subject DN is given, it must be combined + with a ta-serial value (see below) in order to uniquely + identify the certificate to use. Also, the certificate + identified must be available in the keystore that is selected. + + If the value "search" is used instead of an explicit + subject and serial number, then the KMF policy engine will + attempt to locate a certificate that matches the issuer name + of the certificate being validated and use that for the + validation. + + If "search" is used, the "ta-serial" value is ignored. + + ta-serial=trust anchor serial number + + If the "ta-name" is given as an explicit subject name, then + the serial number of that certificate must be indicated in + the "ta-serial" value. The serial number must be + represented in hexadecimal form. + Example: + ta-serial=0x01020a0b + validity-adjusttime=adjusttime Set the adjust time for both ends of validity period @@ -517,7 +545,7 @@ [ignore-unknown-eku=true|false] [ignore-trust-anchor=true|false] [validity-adjusttime=adjusttime] - [ta-name=trust anchor subject DN] + [ta-name=trust anchor subject DN | search] [ta-serial=trust anchor serial number] 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From Darren.Moffat@oracle.com Tue Jul 20 07:45:59 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o6KEjwGq017535 for ; Tue, 20 Jul 2010 07:45:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o6KEjvHE006829 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 20 Jul 2010 08:45:58 -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 <0L5V00J0R2CM5I00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Jul 2010 07:45:58 -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 <0L5V00FN62CL8I40@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 20 Jul 2010 07:45:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o6KEjve1004228 for ; Tue, 20 Jul 2010 14:45:57 +0000 (GMT) Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6KDMmbl023375 for ; Tue, 20 Jul 2010 14:45:56 +0000 (GMT) Received: from abhmt016.oracle.com by acsmt355.oracle.com with ESMTP id 442083581279637147; Tue, 20 Jul 2010 07:45:47 -0700 Received: from [10.7.251.221] (/10.7.251.221) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Jul 2010 07:45:46 -0700 Date: Tue, 20 Jul 2010 15:45:44 +0100 From: Darren J Moffat Subject: Re: KMF Certificate Validation Enhancements [PSARC/2010/269 FastTrack, timeout 07/21/2010] To: PSARC-ext@sun.com Message-id: <4C45B698.5050508@Oracle.COM> Organization: Oracle Solaris Security MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C45B6A4.0214:SCFMA4539814,ss=1,fgs=0 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.9) Gecko/20100607 Lightning/1.0b1 OracleBeehiveExtension/1.0.0.0pre3 Thunderbird/3.0.4 Status: RO Content-Length: 396 This case is a simple very straight forward extension of existing functionality and an obvious change in default behaviour. So it gets my +1 as specified. I believe the "correct thing" will happen with the default system KMF policy file on upgrades since if the administrator has changed their policy it will be preserved otherwise the new policy will be put in place. -- Darren J Moffat