From owner-ietf-pkix@mail.imc.org Mon May 2 16:33:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12634 for ; Mon, 2 May 2005 16:33:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42IQlCp073325; Mon, 2 May 2005 11:26:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j42IQlNe073324; Mon, 2 May 2005 11:26:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42IQjCw073296 for ; Mon, 2 May 2005 11:26:46 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com) Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id 53E0E5FDAD; Mon, 2 May 2005 13:26:16 -0500 (CDT) Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id ; Mon, 2 May 2005 13:26:15 -0500 Message-ID: <5.1.0.14.0.20050502141922.00b1c318@172.16.146.192> From: "Kazin, Joel" To: key_mgmt@nist.gov Cc: ietf-pkix@imc.org Subject: SP 800 57 Part II Date: Mon, 2 May 2005 13:27:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54F44.6CDCAB7E" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C54F44.6CDCAB7E Content-Type: text/plain; charset="iso-8859-1" The draft document beginning in section 3.2.1.1 makes several references to the RFC 2527 framework. While I agree with the general approach in the draft, RFC 2527 is obsolete having been superceded by RFC 3647 in November of 2003. While the content of the framework of RFC 2527 was not greatly changed by RFC 3647, the organization was. There is a useful set of cross-references between the two frameworks at the back of RFC 3647. Joel S. Kazin CPA, CISA, CISSP, CISM Senior Consultant Atos Origin 40 Old Sleepy Hollow Road Pleasantville, New York 10570-3802 USA Phone +1 914-769-8780 Mobile +1 914-564-1484 email joel.kazin@atosorigin.com www.atosorigin.com ------_=_NextPart_001_01C54F44.6CDCAB7E Content-Type: text/html; charset="iso-8859-1" SP 800 57 Part II

The draft document beginning in section 3.2.1.1 makes several references to
the RFC 2527 framework. While I agree with the general approach in the
draft, RFC 2527 is obsolete having been superceded by RFC 3647 in November
of 2003.  While the content of the framework of RFC 2527 was not greatly
changed by RFC 3647, the organization was. There is a useful set of
cross-references between the two frameworks at the back of RFC 3647.


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    joel.kazin@atosorigin.com
www.atosorigin.com

------_=_NextPart_001_01C54F44.6CDCAB7E-- From owner-ietf-pkix@mail.imc.org Wed May 4 11:48:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22978 for ; Wed, 4 May 2005 11:47:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44EmRLf067550; Wed, 4 May 2005 07:48:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44EmRoV067549; Wed, 4 May 2005 07:48:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44EmQwP067542 for ; Wed, 4 May 2005 07:48:27 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j44ElvaB009997 for ; Wed, 4 May 2005 10:47:58 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j44ElO9q006301 for ; Wed, 4 May 2005 10:47:24 -0400 (EDT) Message-ID: <4278E0BA.7020706@nist.gov> Date: Wed, 04 May 2005 10:48:26 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: Disposition of Comments for 3280bis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit All, Here is the disposition of comments for 3280bis (http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-00.txt). There is a Diff file on the NIST Web site at http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html that highlights the differences between RFC 3280 and draft -00 of 3280bis. If you submitted a comment and do not believe that it was addressed in the disposition of comments below, please let me know and I will look into it. Please note, however, that draft -00 of 3280bis was originally submitted on February 13 and that the disposition of comments is based on comments that were submitted in late 2004 (or earlier). A few comments have been sent to the PKIX list about 3280bis since mid-February. These comments are not addressed in 3280bis-00 or in the notes below, but will be considered before draft -01 of 3280bis is submitted. Thanks, Dave ----------------------------------------------------------------------------------------------------- 3280bis disposition of comments: 1) There is confusion about the use of the term "CRL issuer" in RFC 3280. In section 3, the explanation of the "CRL issuer" component of Figure 1 has been modified as has the description of "CRL issuer" in section 5. Both note that the CRL issuer is either the CA or an entity that has been delegated the responsibility for issuing CRLs by the CA. 2) There is confusion about whether a CA is identified by its name alone or by a combination of name and key pair. The confusion mainly focused on the scope of CRLs. Section 5 of 3280bis includes the following: A full and complete CRL lists all unexpired certificates issued by a CA that have been revoked for any reason. (Note that since CAs and CRL issuers are identified by name, the scope of a CRL is not affected by the key used to sign the CRL or the key(s) used to sign certificates.) 3) RFC 3280 states that all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString, with some exceptions. 3280bis states that either the PrintableString or UTF8String encoding of DirectoryString MUST be used, except for previously established names that use a different encoding. 4) 3280bis should incorporate the rules for encoding and comparing internationalized name forms. A new section 7 has been added which covers comparing directoryNames using the rules from LDAP StringPrep. Section 7 also covers the encoding and comparison of internationalized domain names and Internationalized Resource Identifiers. 5) There are problems with text in RFC 3280 regarding "name rollover" certificates to support an orderly migration to UTF8String The text about "name rollover" certificates has been deleted. 6) For validity dates, RFC 3280 imposes generation requirements for CAs but does not include requirements for relying parties 3280bis says: "Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime." This applies to the thisUpdate and nextUpdate fields of CRLs as well. 7) RFC 3280 states that applications should be capable of processing unique identifiers, but it is not clear what, if any, processing requirements there are. 3280bis explicitly states that there are no processing requirements associated with unique identifiers. 8) The meaning of critical vs. non-critical certificate extension should be clarified. 3280 bis states: "A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it can not process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized." 9) RFC 3280 states that conforming applications must be able to process the name constraints extension, but does not specify which name forms must be supported. 3280bis states that conforming applications MUST be able to process name constraints for directoryName and SHOULD be able to process name constraints for rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress. 3280bis further states that conforming CAs MUST NOT impose name constraints on the x400Address, ediPartyName, or registeredID name forms. 10) RFC 3280 states that conforming applications SHOULD support the policyMappings extension and MUST support the policyConstraints extension. It seems inappropriate to require support for the inhibitPolicyMapping field of policyConstraints without requiring support for the policyMappings extension. 3280bis states that conforming applications MUST support the requireExplicitPolicy field of policyConstraints and SHOULD support the inhibitPolicyMapping field of policyConstraints. 3280bis further states that applications that support the inhibitPolicyMapping field of policyConstraints MUST also support the policyMappings field. 3280bis also requires CAs to mark this policyConstraints as critical. 11) 3280bis should clearly explain that there is no requirement as part of path validation that authorityKeyIdentifiers and subjectKeyIdentifiers match. Section 4.2.1.2 (Subject Key Identifier) now says: "Applications are not required to verify that key identifiers match when performing certification path validation." The requirement for issuing CAs to place matching key identifiers in the certificates that they issue is still present. 12) RFC 3280 states that one common method for generating key identifiers is a monotonically increasing sequence number. Shouldn't key identifiers be globally unique (or at least shouldn't one try to avoid collisions). The phrase "One common method for generating unique values is a monotonically increasing sequence of integers." has be replaced with "Other methods of generating unique numbers are also acceptable." 13) The descriptions of the meanings of the digitalSignature and nonRepudiation bits of keyUsage may need to be adjusted based on the work in X.509 The new text in X.509 aligns with the text in RFC 3280. No changes are required to 3280bis. A comment has been added to the ASN.1 for KeyUsage stating that "recent editions of X.509 have renamed [the nonRepudiation] bit to contentCommitment" 14) 3280bis should note that there may be security issues associated with setting both the digitalSignature and nonRepudiation bits in a certificate. A sentence was added to section 4.2.1.3 (Key Usage) stating: "Combining the nonRepudiation bit in the keyUsage certificate extension with other keyUsage bits may have security implications depending on the context in which the certificate is to be used." 15) RFC 3280 states that the privateKeyUsagePeriod extension "SHOULD NOT be used within the Internet PKI." 3280bis should to changed to state that this may MAY be used. The contents of the section describing the privateKeyUsagePeriod extension were not changed but were moved to appendix D, a new appendix for listing extensions that are outside the scope of the profile. 16) 3280bis should state that a certificate policy OID may appear at most once in a certificatePolicies extension. A sentence was added to the first paragraph of section 4.2.1.4 (Certificate Policies) stating this. 17) RFC 3280 states "The application software SHOULD display all user notices in all certificates of the certification path used, except that if a notice is duplicated only one copy need be displayed." This is inconsistent with section 6, which specifies that only those user notices associated with policies that appear in every certificate in the path (either directly or through mapping) are returned to the application for display. Section 4.2.1.4 (Certificate Policies) states that only those user notices that are returned as a result of path validation are intended for display to the user. It is also noted that this applies to any other policy qualifiers. 18) The user notice qualifier makes use of DisplayText, which is a CHOICE of four different string encoding options. Unlike with DirectoryString in the issuer and subject fields, RFC 3280 provides no guidance on which encodings to use. 3280bis states: "Conforming CAs SHOULD use the UTF8String encoding for explicitText, but MAY use IA5String. Conforming CAs MUST NOT encode explicitText as VisibleString or BMPString." 19) For the policyMappings extension, RFC 3280 states that policies SHOULD NOT be mapped to or from anyPolicy, but section 6 states that relying parties MUST reject any certificate that includes a policyMappings extension that maps to or from anyPolicy. Section 4.2.1.5 (Policy Mappings) of 3280bis states that policies MUST not be mapped to or from anyPolicy. 20) RFC 3280 states that the policyMappings extension MUST be marked non-critical, however given the processing semantics for this extension it may be appropriate to mark the extension critical. X.509 allows for the extension to be marked either critical or non-critical. 3280bis states that the policyMappings extensions SHOULD be marked critical. 21) There is a need to be able to specify name constraints for URIs that limit schemes that may be specified. 3280bis includes an extended set of rules for specifying name constraints on URIs. 22) The rules for specifying name constraints on DNS names are unclear. Does "myexample.com" satisfy a constraint of "example.com"? 3280bis states that "DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding subdomains to the left hand side of the name satisfies the name constraint." 23) 3280bis should clearly state the rules for processing a name constraints extension that specifies constraints on name forms that an application is unable to process. 3280bis states that if a critical name constraints extension specifies a constraint for a name form and a name of that name form appears in a subsequent certificate, then the application must either process the constraint or reject the certificate. 24) 3280bis needs to provide more information about the use of URIs in the cRLDistributionPoints extension. 3280bis provides information about HTTP and LDAP URIs. It indicates that an HTTP URI MUST point to a file containing a DER encoded CRL. It also provides rules for the format of an LDAP URI. 25) RFC 3280 states that when a distribution point name in a cRLDistributionPoints extension is specified as a URI, the URI MUST include a fully qualified domain name or IP address as the host. 3280bis should allow for the use of LDAP URIs that do not specify a host name. 3280bis removes this requirement by no longer specifying that the encoding rules specified for URIs in the subjectAltName extension apply to the cRLDistributionPoints extension. 3280bis also explicitly states that the host name is optional in LDAP URIs in the cRLDistributionPoints extension. 26) RFC 3280 states that if the cRLIssuer field is present in cRLDistributionPoints, it MUST contain at least one X.500 DN. 3280bis should state that this DN must be the DN from the issuer field of the referenced CRL. 3280bis states that the cRLIssuer field MUST only contain the DN from the issuer field of the referenced CRL and that the DN MUST be encoded identically in both places. 27) 3280bis should deprecate segmented CRLs by reason code. 3280bis RECOMMENDS against segmenting CRLs by reason code and requires that certificates that include a cRLDistributionPoints extension MUST include at least one distribution point that points to a CRL that covers the certificate for all reasons. 28) RFC 3280 states that for the id-ad-caIssuers assess method of authorityInfoAccess and the id-ad-caRepository access method of subjectInfoAccess when the accessLocation is a directoryName the information is to be obtained using DAP. This is inconsistent with the cRLDistributionPoints extension where the protocol used to obtain the information is not defined by the standard but is instead considered to be a local matter. 3280bis states that for the authorityInfoAccess and subjectInfoAccess extensions that when accessLocation is a directoryName the protocol used to obtain the information from the directory is a local matter. 29) RFC 3280 states that for the id-ad-caIssuers assess method of authorityInfoAccess and the id-ad-caRepository access method of subjectInfoAccess the access location may be an http, ftp, or ldap URI or an rfc822Name but no information is provided on the format of the URIs or the format of the data that will be retrieved using these access methods. 3280bis specifies the format for LDAP URIs and specifies that FTP and HTTP URIs must point to files that contain either certificates or certs-only CMS messages. The use of rfc822Name as in accessLocation is not mentioned. 30) For the cRLDistributionPoints extension, RFC 3280 clearly states that if a single distribution point contains multiple distribution point names that each distribution point name describes a different mechanism for obtaining the same CRL, whereas distribution point names that appear in different distribution points may point to different CRLs. What is the rule for the authorityInfoAccess and subjectInfoAccess extensions? If an AIA extension includes more than one instance of the id-ad-caIssuers access method, does each instance provide a different mechanism for obtaining the same information or could different instances of the access method point to different information. 3280bis states that different instances of the access method may specify different methods for accessing the same information or may point to different information. 31) RFC 3280 states: "Although the [issuingDistributionPoint] extension is critical, conforming implementations are not required to support this extension." Some people have interpreted this to mean that implementations that are unable to process the extension may ignore it even though it is marked critical. The following sentence has bee added to 3280bis: "However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions." 32) In X.509, there is a proposal to revert to the original version of the issuingDistributionPoint extension, which did not include the onlyContainsAttributeCerts field, and a new extension has been proposed for attribute certificates. [Note: The design team was unable to verify whether this proposal has been approved in X.509] The design team decided to continue to use the ASN.1 from RFC 3280 for the issuingDistributionPoint extension. However, the text now explicitly states that the onlyContainsAttributeCerts field MUST be set to FALSE, since 3280bis only covers public key certificates. When onlyContainsAttributeCerts is set to FALSE, the DER encoding and semantics of the issuingDistributionPoint extension are the same as if the onlyContainsAttributeCerts were not present. 33) The certificateIssuer CRL entry extension contains a GeneralNames. While RFC 3280 does not state this, there seems to be general agreement that the certificateIssuer extension should only contain the DN from the issuer field of the certificate being revoked. 3280bis states: "Conforming CRL issuers MUST include in [the certificateIssuer] extension the distinguished name (DN) from the issuer field of the certificate that corresponds to this CRL entry. The encoding of the DN MUST be identical to the encoding used in the certificate." 34) X.509 states that a certificate may not appear in a certification path more than once. 3280bis should impose the same restriction. Section 6.1 of 3280bis states that a certificate MUST NOT appear more than once in a prospective certification path. 35) The path validation algorithm should indicate how to perform validations for times other than the current time. Adding information about how to perform validations for some time other than the current time was considered to be outside the scope of changes that could be made in 3280bis. 36) The criticality_indicator variable in the nodes of the valid_policy_tree seems to have no application in the algorithm and so it should be removed. The criticality_indicator variable has been removed from the nodes of the valid_policy_tree. 37) Section 6.1.2 of RFC 3280 specifies the initial values for the state variables. Can these variables be set to different initial values in order to impose additional constraints? Section 6.2 of RFC 3280 already states that this is permitted. Section 6.2 of 3280bis includes additional text referring to the possibility of using certificate extensions from self-signed certificates to set these initial values. 38) Section 6.1.4 of RFC 3280 states that one must verify that intermediate certificates are CA certificates using either the contents of the basicConstraints extension or out-of-band means. X.509 states that a version 3 certificate that does not include a basicConstraints extension must not be considered a CA certificate. 3280bis states that for a version 3 intermediate certificate the basicConstraints extension must be present with cA set to TRUE. Conforming applications may either reject all version 1 and version 2 intermediate certificates or may use out-of-band means to verify that they are CA certificates. 39) In section 6.1.5, RFC 3280 states that the explicit_policy variable is only decremented if the final certificate in the certification path is not self-issued. In X.509, the final certificate in a certification path is treated the same way whether it is self-issued or not. In order to make 3280bis consistent with X.509, 3280bis has been changed to state that the explicit_policy variable is always decremented as part of the wrap-up step, whether the final certificate is self-issued or not. 40) Section 6.3 of RFC 3280 states: "Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure." This should be clarified. For example, the CRL validation algorithm in RFC 3280 will only validate a delta-CRL if it was signed using the same key as the corresponding complete CRL. While RFC 3280 requires CRL issuers to sign delta-CRLs using the same key as the key used to sign the corresponding base CRL, this is not an X.509 requirement. Conforming implementations should be permitted to accept delta-CRLs that were signed using a different key even though they are not required to be able to do so. 3280bis has replaced the referenced sentence with: "Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure when processing CRLs that are issued in conformance with this profile." 41) Section 6.3.1 of RFC 3280 states: "Note that implementations supporting legacy PKIs, such as RFC 1422 and X.509 version 1, will need an additional input indicating whether the supplied certificate is associated with a CA or an end entity." What is the reason for this statement? The only reason that one might need to know whether a certificate is a CA certificate or end entity certificate when validating a CRL is if the CRL includes an issuingDistributionPoint extension with onlyContainsUserCerts or onlyContainsCACerts set to TRUE. But, when one of these is set, the algorithm in section 6.3.3 relies on the basicConstraints extension to determine the type of certificate. The sentence quoted above has been deleted. Section 5.2.5 (Issuing Distribution Point) of 3280bis now states: "If either onlyContainsUserCerts or onlyContainsCACerts is set to TRUE then the scope of the CRL MUST NOT include any version 1 or version 2 certificates." 42) There seems to be two problems with the algorithm in section 6.3.3 when CRLs are segmented by reason code. The algorithm defines a value all-reasons that is the set of reason codes from the CRLReason type. The algorithm continues until CRLs are located that cover all of the reasons in all-reasons. If a CRL cannot be located that covers one or more of the reasons in all-reasons, then the algorithm fails. But, the set of reasons covered by a CRL is specified using the ReasonFlags bit string. In ReasonFlags, however, "unspecified" is replaced by "unused". So, the algorithm will never complete successfully when CRLs are segmented by reason since no CRL can specify that it covers the "unspecified" reason code. It is also not clear on which CRL to include certificates that have been revoked with a reason code of unspecified. In 3280bis, "unspecified" has been removed from all-reasons. In addition, section 5.2.5 (Issuing Distribution Point) of 3280bis states that if a CRL includes an issuingDistributionPoint extension with onlySomeReasons present then every certificate in the scope of that CRL that is revoked must be assigned a revocation reason other than unspecified. 43) It should be noted in 3280bis that there is a risk that two different CAs (or a CA and a CRL issuer) may issue certificates and CRLs under the same name and that if this happens there is a risk that a relying party will validate a certificate issued by one of these entities using a CRL issued by the other. The security considerations section of 3280bis states that CAs and CRL issuers should be formed in a way that reduces the likelihood of name collisions. It also states that implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate terminate at the same trust anchor. 44) The text from RFC 2510 on root key update should be included in 3280bis. The security considerations section of 3280bis includes a pointer to RFC 2510. From owner-ietf-pkix@mail.imc.org Wed May 4 16:13:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00139 for ; Wed, 4 May 2005 16:13:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44JKIvW099743; Wed, 4 May 2005 12:20:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44JKIin099742; Wed, 4 May 2005 12:20:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44JKHnI099734 for ; Wed, 4 May 2005 12:20:17 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j44JK0DT016769; Wed, 4 May 2005 15:20:01 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j44JJF9q029602; Wed, 4 May 2005 15:19:19 -0400 (EDT) Message-ID: <42792071.1060704@nist.gov> Date: Wed, 04 May 2005 15:20:17 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Henson CC: pkix Subject: Re: RFC3280bis: policy processing. References: <419CA07A.7020806@drh-consultancy.demon.co.uk> <419D004F.2080205@nist.gov> <419D3BF2.7070100@drh-consultancy.demon.co.uk> <41A21934.507@drh-consultancy.demon.co.uk> In-Reply-To: <41A21934.507@drh-consultancy.demon.co.uk> Content-Type: multipart/mixed; boundary="------------010400010004030801000000" X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------010400010004030801000000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Steve, A few of the members of the design team spent some time reviewing the issue that you brought up below. We agree that X.509 and RFC 3280 differ as you describe and that in some circumstances the outputs of the algorithms could differ. However, we do not believe that the differences in the two algorithms will result in different outcomes in any realistic scenarios and so we do not believe that it is necessary to change 3280bis to align with X.509. An example of where X.509 and RFC 3280 could produce different results is shown in "X509vsRFC3280_policyMappings.pdf" (attached). Pages 1 and 2 describe Certification Path 1 and the steps that would result from processing this certification path under X.509. Under X.509 the output consists of a authorities-constrained-policy-set of {1, 2} whereas under RFC 3280 the authorities-constrained-policy-set would be {1}. Note however, that the first certificate in the path include a policyMappings extension that maps from policy 1 to policy 2. So, the outcome of path validation would effectively be the same in either case unless the user-initial-policy-set included the subjectDomainPolicy from the policy mapping (2), but not the issuerDomainPolicy (1). This seem unlikely. On page 3, Certification Path 2 demonstrates that RFC 3280 would get the same result as X.509 if the first certificate in the certification path explicitly asserted policy 2 in addition to asserting policy 1. As shown in "MorePolicyMappingOddities.pdf", it turns out that a number of unusual things can happen when the policyMappings extension is included in a certificate that also asserts anyPolicy. These oddities occur in both X.509 and RFC 3280. But, as before, they would only result in a different outcome for path validation if the user-initial-policy-set asserted a policy that appeared as a subjectDomainPolicy in the policyMappings extension but did not assert the corresponding issuerDomainPolicy. So, while the results are unusual, it does not seem that it is necessary to make any changes to the algorithm. Dave Stephen Henson wrote: > While I was checking the X509 policy processing against the RFC3280 > version I've noticed what I believe to be a discrepancy between the two. > > In RFC3280 the policy mapping processing is described in 6.1.4 b(1) as: > >> (1) If the policy_mapping variable is greater than 0, for each node >> in the valid_policy_tree of depth i where ID-P is the valid_policy, >> set expected_policy_set to the set of subjectDomainPolicy values that >> are specified as equivalent to ID-P by the policy mapping extension. >> >> If no node of depth i in the valid_policy_tree has a valid_policy of >> ID-P but there is a node of depth i with a valid_policy of anyPolicy, >> then generate a child node of the node of depth i-1 that has a >> valid_policy of anyPolicy as follows: > > Whereas the corresponding text in X509 is in 10.5.2 d): > >> process any policy mappings extension by, for each mapping identified >> in the extension, locate all rows in the >> authorities-constrained-policy-set table whose [path-depth] column >> entry is equal to the issuer domain policy value in the extension, >> and write the subject domain policy value from the extension in the >> [path-depth+1] column entry of the same row. If the extension maps an >> issuer domain policy to more than one subject domain policy, then the >> affected row must be copied and the new entry added to each row. If >> the value in authoritiesconstrained- policy-set[0, path-depth] is >> any-policy, then write each issuer domain policy identifier from the >> policy mappings extension in the [path-depth] column, making >> duplicate rows as necessary and retaining qualifiers if they are >> present, and write the subject domain policy value from the extension >> in the [pathdepth+ 1] column entry of the same row. > > > Translating this into RFC3280 terms it appears the processing of > anyPolicy is different. > > In RFC3280 a new node is added only if a node of depth i doesn't exist > with a valid policy of ID-P. > > In X509 it appears to be saying a new node is added unconditionally. > > I believe this difference could result in different outputs from the > algorithm. In particular the X509 processing will (significantly) > result in nodes whose parent is anyPolicy which will not appear in the > RFC3280 version. > > Steve. --------------010400010004030801000000 Content-Type: application/pdf; name="X509vsRFC3280_policyMappings.pdf" Content-Disposition: inline; filename="X509vsRFC3280_policyMappings.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1auZLUMBDN5ysULsEYXZYtQo6AgCqgJiSBPTgXdpejir9Hl2ek J8n2sMMx4NpgqqXuVl/qJ8l7TWjDCLV/4ff0cnW9uvtcktefV9eEuanh5/SS3N+YSU0YJ5uL lZdgRNOGS9JR3Zjhy9XJgzubd6u+YcrMbs5WJ+eWbhsqA31jadnQPtBfLC0ao9TTbz0tBvkL T/eyMn/q9fNB30ugp/R/8vzdQH8EmliaN/2g76mlVdPxmeu9mdDHnL5A3LPEow15ttKUm6Ca VXSriCY35+Riz5QoTY8iIecwPx2gNReWfc1czRWWRJU3YPIXMPktmHQBIam4uA3hvi6GGpID /Sl28cOEcegsGoeLffbOtIpSFkfRiuyGMOro0nZb7ES+x1bPcSkvqZ0y9MopXzPBTZpFI+Xh 45aY/8QSjJooVfy/gm18FUvjUh/jydcgGfLRx7lYS263rHWVFzWC0Dangf4aLzhV/Q99Q1Ay jmJk4KWl9W5tDMWot8UUpXXzIc/+Xrm6B8wEaOZLhzLrUlQ9o0F7FRPvJvYvmof9JEQ4CfCt opsG8JfstXSJGR2C+zB3feM26dCLjx1u+BjchEpa8OYfxxu+wM0CNzPhhi9w8zvgRvybcCMW uPkTcBOqiSvXBwVv5FFU09/2eIH6sBLRvqlKxp5ZSO40+G3fT2SnOWGiYz/3gCKVa+n2DeUx +JUsikmZShoGHVsoAsy3eLGXUJG4nUahGdOXbEysVcd89zljIThGrtM6qdTiosUaqhVs2FA1 NJoK5YxmsPYitQpMQpCktaALzbnJWZK4jNYq2n6Ww+Ia2s1VznIgMN7SIVy90FrXA4G2Y2BC 7eikdKBABEYt0vcqd7RwjEMrPHwy1bmTGOc2cHacuq7Od20lvBBI7YG2tw1syxiVvJSNLOU1 yWMtghKTdgg0dIuJrtG8alfh0jSe3+RucZB62mXenGJas/fshaNLLlVd7fCAEIJtqdhBovlw 4K1GdPSyhA3yvqUx2iN4NXWSQv1/+3ljCkBQX9LrK9cYGpXe+0LDFTUcfHGS127ycYDGRAOm tmOTiZoXd/J1RpEzbLu2Zvjc83u0XqFHzjzFV1c9/HeYwhHb7HfV2J6qDtN81+Yk5sKy9OD/ tQf/tjvGIYzFhluohsLWntEQtiGtSxUOkIViGS4Q483mPOc6XFcbq+Vf3dUKh1nMoceZyAaW B3ZPqMHnwlRZFXAiscLDZqG2pvD5VsiTpSkVnNGYbl97lCZf+eDhTKpG2zfY1naHGHxEItVT /IrFubbt3KKRUVBFo1q7/6MwJH/eLgSg6avl3q/owr2wJenPanhfM7PHhNs/9kdoydvwkr89 mbDjqIWdD4pOlHsrXLkf6YlguZWl88utrLSH/o9bWeHfFZh23yALd7AFBhcYXGBwKHf3nYhJ yYlkBisEYb3y34n8oJDGU9VSIv0o58YQxyqBVYieOXkZD7ZKenkRyTtWCaxcGWyx8m082Blz uWSCACtLRp1Wp0DuFAjai2zQy0uWuOrF7WDklBeHQSfOlNBZpFhvatvZJFJWlVvqFOBSOOjl pWndUVC8uB1ER3FwyGkafsPa19LX6ZwVMyX6llVjmvrvWTGodrDiqdRJpDwrePXM/P0AQyFA EmVuZHN0cmVhbQplbmRvYmoKNyAwIG9iagoxMjI5CmVuZG9iagoxNSAwIG9iago8PC9MZW5n dGggMTYgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWEtPGzEQvu+v8BGk rvF77Uq9ULXngnLkggIBWgIlTQ+o6n/v2l7v2mM7aUOQiFRxQB6Pv/nmZU/2CRFMEbF/w//5 snlqnhB1svBvvkSns+bk3CDK0GzReFWKDMFMoI4Y3IuXzdGX49nXRuGO9buzq+bo2q4lZnpY r+yaYy2G9QKsH71+pyr6S7s2mIf9O79Pg70HZ39Y3AAwZNcM60AGkoXGIJk5cAY698OuBZaq sn4R2eHw6PlD0CeEDqJ1UJlEtfhzYwwMaf3UVW7rLrd16bVIhF1nFGshEJdtcS44sQYQBXoL nw2iK9mAVi/BGpqoZn8yCXN4cQQ40DywJC4KDABkthkRYjnYxXEeKhjtx/xYobagK7vniG+u okV+sKBVSdYLao+QJI4hyO/tomVCYaNQS6W9HcY0aYY5i1OpCRYxSiemiHGHxImwZ1qqLeCI dHJO6XC1CjFiXMZMktviGfjfgqvrO7hNHuPD9+Aq2dYJzhjvsNidVxTxkdqUlzK7rEy2EFRV dqm1IseoKV+NIPnb8BExQQd2nTH7IDiVeeAYAT/7UgyPfMuZ6msxqlV6GLU6uaBCzEN7Ktif oyDrz34uGBXfvs9vvj+npEg9zUS1NDDt0iBYSMNBTZanzitsWJyQDZMiHO7m4R6o4H901Yyp SoMx6q/AlVYdjyrBqvDZeTbaNj3cxsGFh0Mwohr9FusPwRxfYjjg+KkrLXIaA/zjyBVtJjDV YSs6kHTS8DbJGvG9zlgj6mvPwdBlHrvsxylquL2sWqosjTEFLxunhnviQMap/TxRh/Us/3+i 9vJE0eS+iDrtM7Bf/WRQ6ex7ECN4Hw3+iZo/SQ7gE7bjx5Iq+ZvsWokaoO05tf3wqkRebD8B 0BoYut1U96syyzFEEAx6AR9q6DVsQlimpfejq4UQkhnJg282G0eetM2KX4YgedipSSRTvF07 dcPPt8J3mMLv/nXa7709akxXaawPoLHg/q/csWQyeFdqrOh88sXht118mqGzhgrBkFKGIo6o Vmh1jRaDUPdJ55TLfieSqh7RSYWXMtbn3gGICYATzXOhFl3FlOyL1QplKqQFS1ZVTKreEhQ6 S0VQTr1Qx5hWKCahx4RChwmOO0wpuXHCOE6yYyn7oKpynxyAmACc/Uxo7ZdNcWEyn5wQ+pQJ HSY4LmQnsjR5YSWiLCkTrwoC5YQ19l1+HpI66//+AORrMvtlbmRzdHJlYW0KZW5kb2JqCjE2 IDAgb2JqCjkxNAplbmRvYmoKMTkgMCBvYmoKPDwvTGVuZ3RoIDIwIDAgUi9GaWx0ZXIgL0Zs YXRlRGVjb2RlPj4Kc3RyZWFtCnic7Vldj1y3DX2fXzGPadCdSNR3gL40LfpUoHYWyHOy8SYO Zh1766Iwiv738pDU/dDMeGfsrNMECwPee+6VKJLiISnNm63b+a3DP/t7c7d5s3mz9fKu/7m5 2/75evPF87b1tL2+3ehQv21uR3FbXNvx67vNZ1/94fqnTd35zF+vv9989gI47Vw0fA8cd64a fgscdixU8UvFoc+/VVzjie83Kp+6vG8H/JD8n3V86fjVgLfAtKtd3j+A867Qmev9+IA8EnkG vgT46/X22aY5YqfyKi3lbdvev9jeXrglubnfxIa8GL6PDvIHDrqigOFXXmLuyJKjyPtB5beD yi8HlW4Hl5wwcXLhpSZaDMWOf16auH9AudHYUblxsX+qMSk755dexJT51ej10aSJFvOUd0ut zzHpMKRmYaNV7w7X++Mg5SiTrnwMINuVD7sYf3lvr4z+O4B37NsTXns9kP/1cva41Kvlxx+G mbaLdbmDV5FAdJhKRyUOk6ZIMPyv5YIPceYvmkZyXHpxoeAdcJvXHl3xXmuPbtF696eNml9d tFdfHoueBfYaPc4P0fNep323BD89wPpRvTELmYdXDv4o764d+AkYekZeMZKWugu0yOC/9SJ1 WMUXRcoi6alK/T6rFCcLWiThp3LzVG4eLjf0VG4+RbkJv89yE57Kza9RbsTtXzz33g7cV56y pETKBMpOZh9l79GbgVPXEPdDHhgNeigiTxps+ErHnwrQlfNXuXMUNCoyKr7yx3uz8qjy94NL roaAfX3gv49PLxPui4XW2umYGVV+qwHSL2Tec1j9k0Z7OVUf/nOY7vzhq7OOxN0r/wWQy6Vn mzcbXBXd8f+lkdvuN9nT+hkPP26+2b6ya6Xnf7OH+x/44eWGWigoz8FlYkEMiaMpuER4S43z UQOOkpeoeQ9jgwvoHm42VFvF1gZHxDWIai1gUnA+y/xaCszoGBNyU4l9RMqQzAIkkVMNVXFy SCKYwWXV4U0Vl1BpRSSg6mZA2jUCTPjLE0rVRb0LyGNUSoCo4JrbYX7yWIktrrZCCRkDeU1J jFTYaoyPWVQqrIAYrRgTeK3FgIwF5+k5NR2fmzop54DCxRaAqpRLxF5P+uUWQLTg2QUUVT73 TLAgorJ3fXzOgthDYnD1u6QG827AIl+lbLDCXgSS9HjTesSGB9E/x4hdJvZowADSTeRNgEdm zF2q6DO9IA2LHJ1sUuDgKbAoR3FgSFI5ZA/UJqIElfbYxsLCWIkC7vM+q5OIN6Vh33m/2Rpe QpwooZV3eXqxn1949XpzIjBo88WhqoFD1WH3WUBjL6rdEX7l+YFB0E2qVcOGyEMficwM9wRy XSMvseyxa3WOTF8cNMcMi10fu8wGjTyvC7ik1s3m9hfiK+8phPIk4SsihVHVjalN2YWQp6p8 hJdL7nzlWMBOlqR8xXtIi52NQahjGBNiUol9BCcI2FyS8dVHxbXztbAXwNfqja9Fc0gNytes 4VvDxNesi9ZgfI1N+FpJ+UpForu0ia8sGeFWqhGOrYYKpdNRQ8sw4pepshyQhU/TdNZExrfO V45N8BWZB8M5ND3N+mXmNWK7ps7XzJLA11qEr6YP4lXYGMVg5E7jq2tiUdM2T/IHBLaofLX1 Wp34yp7I2+i88dXJJkYXjK8dx87X/sLSePYSqNFl4ysPZEuiqxNfk9rUUudr4awUoYTx1YuT oiNjB/dMCThNfC0kSqaJr/bCsmStEMhKG19dVJ1852ut0ew2vubGIBu3koZNSxNf+SALvrbQ NdLaIwypc2Q2N/HVYhckEJk5wUQQW/i6oNblfAWf/q0cTSwgJi8EJR4kz3t7xi9B/Mx2rZ9t zDR3v/naZpSAbb2zcYrw9dwfkojjmx0SKw71+C3Jenq36IrOvHKZGh1rdFPHpw/a48Fisei7 D2xlzjacY5TtznLhAcOPtGOPchd17iXEkVb2wD+rXxwXTeKH9oFznHK7EKR4EALjbuOTlAJB e0VRew7ELnMlH+B59EoWolOltehEdh+v+JLo9TVr4kngPXaRHjlsfJGUx3kBYbCKm3Ma9PHj hzfsnEqQTXkbuEaqGx1yLmdKdXpr8tXLIN4UHGQxmlBpgb3OJv2K9g7IttCxipFC0LFOalck 2yByWWVxCTEMoZFrh+GlZvvN7ecWWcT9FgZa/nOFuygskzWjJelEzAT+nlIQsU2UyLSOsgxz gzcVchQD+PSxk1yZJRVOc70aYM7hIqgG1Djl1f7MG4w1q62y0klNSXlpRBdltn6NniVKCyHH Hh4RGs143/FkSPAhH8Hz+JU8WcEkdgL1GZcTCDvY8pJA/3c57jFrAPfm0ssdkvmpCHCGCVmu U0MJ+MNxRtx95473HUdfNe5YMyH0gOfxK3mI0y4RraWsYDMUXxLJgZtUaVtL30v/yNETcAvB wRNRgs4MnkcrBgGNHPKU140izVrwBhwfclltDFnmlezISPNs1dIw4dwMZyQ/TvfJtj1LMQiG LNkH34Miymjq0mbNlqWgaKwkU7iXgmo5zje5YKCWSNoP+SBo31EImtz5VL967qMWErTp0Fk4 o0telnmKLms65HQbqFrL/Pg9R9Nrr3zQq56IpPAYYbY4xBRo1PeGuwLEifnZEO+H9g7BJ2H0 gPvohSSpbDbbZ61rOhfosqoW5bDGO4Qr+4861XxY3v41DzYx6a1rfqpoiwTJrEU+ConkOFMl t4UUNKV5zLMc4pukhMW3jKwpM4FiVeSszw5RRnvNXCopeZWEu67pix2DppkLjRaJUQVM5y4V 53Jv/YrX5aQZvsN9ES2VpSI9+UQ3znFI04vvXQnpg0tXwRr7InXC1Jfb5DgjORssxi41UQNs 8anzNTyrz3oUWTDqCNGDkRWaJOeMEL3m5JBJfd2/W/+gs4GdqitCMV/74hT0UNDlJbsWCSnH 5de0mrvUTMzp06f2p4uj0NsXXKbhdkjOPyhjItvwvuMQ7VQSmpwSRjyPX8nTBkkleDmW3E0S FF/WIIl91HAx8ynKVmCi6E8dOGKcmYvOrlzPNv8DhdGmI2VuZHN0cmVhbQplbmRvYmoKMjAg MCBvYmoKMjI4MwplbmRvYmoKNSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2 MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMTIgMCBSCi9Gb250IDEzIDAgUgo+PgovQ29udGVudHMg NiAwIFIKPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYx MiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0ZvbnQgMTcgMCBSCj4+Ci9Db250ZW50cyAxNSAwIFIKPj4KZW5kb2JqCjE4 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMjEg MCBSCj4+Ci9Db250ZW50cyAxOSAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1Bh Z2VzIC9LaWRzIFsKNSAwIFIKMTQgMCBSCjE4IDAgUgpdIC9Db3VudCAzCj4+CmVuZG9iagox IDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iago0IDAgb2Jq Cjw8L1R5cGUvRXh0R1N0YXRlL05hbWUvUjQvVFIvSWRlbnRpdHk+PgplbmRvYmoKMTIgMCBv YmoKPDwvUjQKNCAwIFI+PgplbmRvYmoKMTMgMCBvYmoKPDwvUjkKOSAwIFIvUjExCjExIDAg Uj4+CmVuZG9iagoxNyAwIG9iago8PC9SOQo5IDAgUi9SMTEKMTEgMCBSPj4KZW5kb2JqCjIx IDAgb2JqCjw8L1I5CjkgMCBSL1IxMQoxMSAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9UeXBl L0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVzLVJvbWFuPj4KZW5kb2JqCjkgMCBvYmoK PDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9UaW1lcy1Sb21hbi9UeXBlL0ZvbnQvTmFtZS9S OT4+CmVuZG9iagoxMCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1Rp bWVzLUl0YWxpYz4+CmVuZG9iagoxMSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250 L1RpbWVzLUl0YWxpYy9UeXBlL0ZvbnQvTmFtZS9SMTE+PgplbmRvYmoKMiAwIG9iago8PC9Q cm9kdWNlcihFU1AgR2hvc3RzY3JpcHQgNy4wNyk+PmVuZG9iagp4cmVmCjAgMjIKMDAwMDAw MDAwMCA2NTUzNSBmIAowMDAwMDA1MjM3IDAwMDAwIG4gCjAwMDAwMDU3NjYgMDAwMDAgbiAK MDAwMDAwNTE2NCAwMDAwMCBuIAowMDAwMDA1Mjg1IDAwMDAwIG4gCjAwMDAwMDQ3MTYgMDAw MDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAxMzE0IDAwMDAwIG4gCjAwMDAwMDU0 OTMgMDAwMDAgbiAKMDAwMDAwNTU1NCAwMDAwMCBuIAowMDAwMDA1NjI3IDAwMDAwIG4gCjAw MDAwMDU2OTAgMDAwMDAgbiAKMDAwMDAwNTM0MCAwMDAwMCBuIAowMDAwMDA1MzcwIDAwMDAw IG4gCjAwMDAwMDQ4NzYgMDAwMDAgbiAKMDAwMDAwMTMzNCAwMDAwMCBuIAowMDAwMDAyMzIw IDAwMDAwIG4gCjAwMDAwMDU0MTEgMDAwMDAgbiAKMDAwMDAwNTAyMCAwMDAwMCBuIAowMDAw MDAyMzQwIDAwMDAwIG4gCjAwMDAwMDQ2OTUgMDAwMDAgbiAKMDAwMDAwNTQ1MiAwMDAwMCBu IAp0cmFpbGVyCjw8IC9TaXplIDIyIC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCj4+CnN0YXJ0 eHJlZgo1ODE2CiUlRU9GCg== --------------010400010004030801000000 Content-Type: application/pdf; name="MorePolicyMappingOddities.pdf" Content-Disposition: inline; filename="MorePolicyMappingOddities.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1aS2/cNhC+76/g0TmswpcoMUAvSRsghwJNsMdcEsd283Bib9IC RdH/Xr60Ij+S0q6tpF504cNiKM5wHh9nhqRvCW0YofYv/J5fr25Xj19JcvV1dUuY+zT8nF+T pxvzURPGyeZy5TkY0bThknRUN2b4enX27NHmw6pvmDJfN+9WZxeWbhsqA721tGxoH+hvlhaN Eerp954WA/+lp3tZ+X7u5fNB3hug5+R/8fO7gf4MNLE0b/pB3m+WVk3H91zv9xl5zMkLxBNL /LIhL1eacuNUs4puFdFke0EuDwyJ0vQoAnIB3+cdtObCTl8zh7nCkihyCyp/A5Xfg0qX4JKK iTsXHmpiwJAc6C+xiZ9mlENjUTlc7Ks3plWUstiLlmUcQq+jSbttMbL8FWu9j0k5pEZhaJUT vmaCmzCLRsrl/Zao/6slGDVeqth/A9v4JubGpT7HH6+AM8Sjj2OxltxuWWsqL0oEpl1MA/1H vOAc+n/2CUHJ2IuRgteW1uPa6IpJa4shSnHzKY/+QbF6ApMJ0MxDhzJrUoSeSae9jYkPM/sX 1cN8EjycOPhe3k0d+F32WrrEHhmCezd3feM26ZCLj73c8KlyE5B0qjeL15uAJq5cHhS8kUeB pofWTaI8RCLqN4dkzJmF4M4Xv11D27ZdR5joGOnv0tG20v3YpvYF2JUsikGZCxo6HVMoFpg/ 48XeACJxO02WZgxfsjERq27y41eMBecYvk7rBKnFRYsYqgE2bKhaNZpz5R7JYO1ZaghMXJCE tSAL1dnmUxK/TGIVdX+Xl8U1pJubfMpCxXhHB3f1QmtddwTqjo4J2NEJdAAgAr0WyXubG1po 41ALXz6Z6lwnxrl1nB2nLqvzMa2Elk1qX2h7m8B2EyPIS9nIUlyTONY8KDFoS1RDt5joGs2r ehVOTdPxTc4Wi+BpjLzpYlqz9+yBI/gYS8ZcM4NpqZhBou+h4a16dPKwhAnyqaXR2xP1aq6T QvkPvd+YKyAoL8n1lWMMjaD3sZBwRa0Ovj7LsZvc1tCYaEDVdupjIub1o3ydycoZtl1bU3zf /j1ar5Aj9+ziq6sufzFWaLHNfleNzalqmeS7Ni2Yc8spBy+Rg2V/fDn4h50xllAWE24BDYWt vUdC2Lm0zlVoIAtgGQ4Q08nmIp+1XFabwvL3zmqFZhZj6OtMpAPLHXtgqYkU4rmwasGJ2AoX mwVszdXne1WeLEwp4x6J6f7YozS5doWLM6karUrFRyRcPcWLIM61Tee2GhkB1WpUS/f/aRmS d9cLC9D80fLgW3ThbtiS8GcYPlTN7DLh/pf9UbXkbbjJ33Um7DiwMNqg6AzcW+HgfjqVFeWf TmXR/NOp7EGfygrvR0y7N8j/Uxk8gtSX3o1GEXwO61ePEBXEzD0f4Gtc8fxUS413PDxVlb/K 4BqBa210WnMV3uLyF4ZIDj5x4kNVYtS2rCS+MiDk8JVh5xQ0GvE9/8aQ/39GW7PsTm8MaVNU PCii8j+gycKUEKXJ+htDdlgY97pZj2ndVfbVT7Cv8PvfuWFJwfnHEu4tkUnJidSSEUFYr/xb ohtsGVeEqZaaL26UcxM4N1XCVMmUcvwiHhRmWzp+GfPbqRKmCmE0x/VF2wnCJRMD/zBV+dFY Kycg0kpQIx8HPT+niame3Q5m7DDo2Lk0Hb9lb+NBZWIda+qEuqlynOqE4mBwv9CJp83Uvupp WZgKThV9yyrmG1Al7vNTK6ayxCo3FQ14af7+BQ5rPEtlbmRzdHJlYW0KZW5kb2JqCjcgMCBv YmoKMTMxNAplbmRvYmoKMTUgMCBvYmoKPDwvTGVuZ3RoIDE2IDAgUi9GaWx0ZXIgL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCnic7VpLbxs3EL7rV/DoHHbD13KXBnpJH0APBZpAx1wSx06Txomt JgX678vXrsiP5K5kyalVCD4Iw+UMZ7558eF7QltGqP0Lv1e3q/vVPWFubPy5uiUv1qvnrzRh nKxvVn4qI5q2XJKe6tYM364ufny2/rgaWqbM1/W71cW1pbuWykBvLC1bOgT6q6VFa4R6+oOn xch/4+lBVr5fefl8lPcG6CX5X/z8fqQ/A00szdthlPe7pVXb8x3X+2NBHnfyAnFpiZ/X5OVK U25ANavoThFNNtfkZk+XKE1PwiHX8B0BYhlADRd2esNczBWWRJEbUPkrqPwBVLoBSComThDu a2KIITnSX2ITPy0oh8aicrjYX96YTlHKYhQty3YIUUeTprTYsvwTa72LSXlIbYWhVU54wwQ3 bhatlMfHLVH/N0swalCq2H8HaXwXc+NSn+OP74Ez+GOIfdFIblPWmsqLEoFp8mmgv8ULLkX/ T74gKBmjGCl4a2m9XRuhmLW26KI0bj7l3t/LV5cwmQDNfOhQZk2KomcWtLcx8XEhf1E9rCcB 4QTgg9BNAXyUXEuX2KFCcA9zP7QuScdafOrtJu/HUbsJkXTuN//XfqP6tjPRLHgrTyKan9pu FuVhJqB+S5mENbsQXMvNd9pQd13fEyZ6RoaH7Kg76X7spvpXsCtZFJ2y5DQEHcMXG9zf8WJv ICIxnWe3Bui+JIswVt3k568YC+AYvl7rJFKLixZjqBawIaFq3XAJyh2KUeNZahGYQJC4tSAL 1dnkUxJcZmMVdX+Xl8AGys1dPuVIm4GJDnANQmtdBwJ1R2BC7OgkdCBABKIWyXubG1rYRqIW l1NRtztBzi1wdpy6qs63ZSVsGaX2jX6wBWyaGIW8lK0s+TXxYw1BiU47Rjd2i4m+1byqV6GL zvs3OdscJZ62nje7qM7knj3wBIyxZSxtprAsFStI9D1suKuIzh7WsEC+sDSiPdOvlnZyKP+p 7zeWGgjKS2p95RhFo9D7s1BwRa0Pvr7IYze5LaIx0YKq3dzHRMzrZ/k6s50zpF1XU3zX80O0 XqFG7niKqK56/Iu5whbf5LtqbU1Vxym+jdmCOVjONfgYNVgOp1eDv9sZ4xjKYsEtREMhtXco CBOkda7CBrIQLOMBYr7YXOezjlfV5mL5sataYTOLPvR9JtKB5cDu2WoihXgurNpwIrbCxWoh tpb680GdJ3NTyrhDYTo89ihNrn3h4k6qVqtS8xEJ10DxWpNzbcu57UZGQLUb1cr9f9qG5MP1 wga0fLTc+xZfKHuHkrg/i+F91cwuEw5/bIi6Je/CS8K0M2GnEQtbGxRdCPdOuHA/n8qK8s+n smj++VT2pE9lhfcrpt0b6LkNntvgvmo2nPYW+qj5PSU3n0CHS6/Ao0T9BdavnhQrhWHplQhf SIvH5FoHfOAZuar8+6wqRTWkMTo1XNn/SMkC7BsIwqd0fJBMrNqUtcTXJIw5fE2aUEGrMcCX 35Ly/wPqapY96C0pzfrihQAq/x2qCNaEqB3W35KyQ+E22c16TOu+klg/QGLhu2Wk7eGt4RHQ cs/VTEpOpJaMCMIG5Z+r3WDHuCJMddR8caOcm5hxUyVMlUwpxy/iQWFKguOXMb+dKmGqEAZU XF90vSBcMjHyj1OVH421cgIirQQ18nHQ83OamOrZ7WDGDoOOnUvTTS17Fw8qE2aZpmYqS0bd Uk6A3ApwS+Gg53eagaYeQ9AUB4NPhU7cZ6YOVffJwlTwlBg6VsHUJEniEz8VQbWDNUtlzo9W vTR//wJGcvG6ZW5kc3RyZWFtCmVuZG9iagoxNiAwIG9iagoxMzQzCmVuZG9iagoxOSAwIG9i ago8PC9MZW5ndGggMjAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWktv 3DYQvu+v4NEBugpfosQAvSRpgR4KNMEec3EcO4/Wib1NCgRF/3v52hX5kZS03q1hoYYPxgw5 w3nPUNxbQhtGqP0L/y+uV7erW8Icbvfv4po836yevtaEcbK5WvmtjGjacEk6qhuDvl6dvXiy +bTqG6bM6ubd6uzSwm1DZYC3FpYN7QP81cKiMUw9/NHDYkd/5eFeVtYvPH++43cO8BT/L35/ t4M/A0wszJt+x+83C6um4zPP+zDBTzh+AXhmgZ825NVKU26Mak7RrSKabC/J1YEuUZouwiGX sI4GYpmB1lzY7WvmYq5wJLLcgshfQeSPINIVmKSi4t6Eh6oYYkju4C+xin9MCIfKonB42J9e mVZRymIrWpIBhVZHlfZpMZB8j6Weo1IeUgMz1Op7ft4PwAVF5i42mBQ22dZMNFKe3tqJ0r9a gFFj24rVbiD5b2JqPOpzvPgeKIMX+9iDa8ltoltVeZEjEO0jIcDf4gOncualLyNKxlaMBLy2 sB7ORlOMalt0Uer9vaMG1EG+elaKnghmPnoog+gZNdrbGPg0kfUoHlahYOHEwEdZNzXgPWTo jLoSkrTrG8GjCr70JsXHmlSIpMcudfIuFaKJK1cHBW/kIqLpoc2gyA8jEeWbimSsmQXnTje/ /Rjctl1HmOgY6e8yB7fS/bOj8C+gV3IoOmXKaWh0LKHYYP6KDzuHiMR0Gm3N6L4kMTFW3ean rxkLxjF0ndZJpBYPLcZQLWBDQtW60ZQpZxSDtSepRWBigsStBV4ozjbfkthlNFZR9nd5W1xD ubnJt5yoGe/hYK5eaK3rhkDZ0TAhdnQSOhAgAq0W8XubK1oY41AK3z6Z6twkxrk1nMVTV9X5 UFbCyCa1b7S9LWD7jVHIS9nIkl8TP9YsKNFpp+iG7jDRNZpX5Srctcb9m9wtThJPg+fNFNOa 3LMXjmBjbBlTwwyWpWIFidbDwFu16OhlCQvkcwujtUf61dQkhfwf+rwx1UCQX1LrK9cYGoXe 74WCK2p98M1ZHrvJNx4aAw2I2o4tJmzePMnPGe2cIe3amuBz5/fovEKNnDnFV089/ee0woht 8l01tqaq0xTftRnBnFkea/ARNbhjtgYPpmbL6HODCspN4n5p9yHA35IX2lju7eJ0CmGxixRC vFCvZlS5vUnrVIWpuJABu1vReAW9zHedrlSPJeh/XaoLEzr60DfPSAaWG/bA/hkJxHNm1S4a kRW+1hZia2roOKqdZm5KCWdU2+Njj9LkWzJ8DZSq0arUUUVC1VP8usW5tj1qkfcbeXe5sKtO 35cPfhoQamhH55UYPlTM7AvJ8S8Y0QjA2/A80dtgWugMEEf3nHDni1WxltGtcCoudOh5vE2n 64+36VIO/T9u04V3P6bd2/FxnT5U94V0+mOq+3Ib2EOr7tUfxvwM51cvgpWkmHrZwofi4i24 Vv3veAWuCv8+y8gouNZGpjVX9lcsWYB9A0b4/I6PqIlW27KU+AKGMYcvYHuroNYY4NPvX/lv h9qaZnd6/0pn2+J9H4W/h1kZa0LUCurvX9mdb0h2cx7Tuqsk1o+QWLj+d65Y0lRn/aJtt/kf C7hHcSYlJ1JLRgRhvfKP4g7ZMq4IUy01Kw7LufGy2yphq2RKOXoRI4VJYkcv062ywNUykMBA 6M5z1dFOh5QD0u/k1MsfnySEAblkgiRMjQsSrOdqGciBgaBGEkR6emosbI/qEyQNTGXM1G6V w1bPFJCOnvfm7hjZ35E7ZGRpR45IT05ll7nP8OC5+marzCV1DLKjAOnoDUTdUW1E7pByQDpy RIZAEzrxvtnaZzHlkZWQkDk9xoToW5a71CEr1k8t5bZm5nfIsk3aLrGp24r6vzJ//wLkFBuP ZW5kc3RyZWFtCmVuZG9iagoyMCAwIG9iagoxNDEwCmVuZG9iagoyMyAwIG9iago8PC9MZW5n dGggMjQgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWklv3DYUvs+v4NEB KoWbKDFAL+kC5BCgCeaYS+LYadI6sadJgKDofy+3GZEfSUm21cCDDnwwHpfH9763UpwbQltG qP0L/8+vNjebG8Lc2P7f+RV5ut08fqkJ42R7ufFLGdG05ZL0VLdm+Gpz9tOj7YfN0DJlZrdv N2cXlu5aKgO9s7Rs6RDoz5YWrWHq6feeFvv9l54eZGX+3PPne36vgZ7j/8mv7/f0R6CJpXk7 7Pn9ZmnV9nzheb/P8JOOXyCeWOKXLXmx0ZQbUM0pulNEk90FubylSZSmR2GQC5hHgFgGUMOF Xd4w53OFI5HlDkT+DCK/B5EuAZKKigcIb6ti8CG5pz/FKv45Ixwqi8LhYX95ZTpFKYtRtFvG oUnUf4BJAiJxZxVGuQ2LholWyvX1/BZvfm4JRo1WFRNcQ9hdx7vxqI/x5DvYGfAbYuwayW2I WVV5kSNsOtgg0F/iA+e89WcfwErGKEYCXllaj2cjFJPaFk1kmY+ucTDUOHQrWz2Bxeg9LHgP sypF3jMJ2puY+DATbygexn9AOAH4XuimAC4JgzzdjvuL6KZHLIjoEKT90Aoe5c5jLw98qjwE TzrVh9XrQ/AmrlweFLyVR+FND637Q37oiSjfnCdjziwYd774HRrQrut7wkTPyHCXDrST7p9t Qp+BXsmhaJQ5oyHomEKxwHyND3sNHonhNFma0XxJYKKvusWPXzIWwDH7eq0TTy0eWvShmsOG gKpVozkoFySDxm+peWACQWLWAi8UZ5cvSXCZ9FWU/W1eFhtIN9f5kpWK8YEOcA1Ca10HAmVH YILv6MR1wEEEohbxe5MrWmjjUApfPpnqXSfGuQXOjlOX1fmYVkLLJrUvtINNYIeFkctL2cqS XRM71hCUaLQ1qqE7TPSt5lW5UtgW2De5W6ziT6PlTRfTmdizF46AMZaMuWYG01Ixg0TzoeGt Ijp5WcIE+dTSiPZEvZrrpJD/Q+835goI8ktyfeUaQyPX+6OQcEWtDr46y303uefTmGhB1G5q MmHz6lF+zmTlDGHX1QRf2r9H5xVy5MIuvnrq+h+yCi22iXfV2pyq1km+jWnBHCwPLQePKU65 LnFaN3YchaWs1P7m7a+lR5rJv9tNZQ1hMW0X6nohQSxIKwdI67sKbWih7O+vIdMp6yJftV5u nOpK/uvcWGiJ0Ya+WkUysBzYWxYs/GSdMquWrWhb4fNowbfmqvy96ldmpnTjghbz/r5HafLx Fj6/SdVqVSphItk1UPycxLm2reLxXSjivL9YRYPRkZa2WKOCip1wKh5poTtdWdL505WlFEP/ jytL4XGFafdAd8rup+z+fbN7+m00ctJf4fxq818JirnnA3yNK958atn/jteeqvDvsoiMnKsx MjVc2Z8KZA72BRjhGye+VCVa7cpS4jMD+hw+MxxQQa3RwecfGfIfaHQ1ze70yJA29MU7Hgo/ +UV4nZ9UYE6ISkH9kSHr88dgN+cxrftKYP0IgYXzf+eK5T8bwsCqVZd/LOFeHpmUnEgtGRGE Dcq/PLrBjnFFmOqomXGjnBsru6USlkqmlNsv4kFhgtjtl+lSWeBqGUhgIHTvuepopRuU46Bf yamXPz5JCENyyQRJmBoTJKOeq2UgRwaCGklw0O+nBmF71BBvt4NyHPTbYdBt98sBPi458zLJ dKnMJfVwjQzcUTjo91PZZ5K6QZQUB4NPCJ0YyiwdMvP7wYr1ZL4fzSeGjtWApjoBxS9FpO1g TX2Z70dVX5i/fwEqUlbgZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iagoxMzI2CmVuZG9iago1 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAxMiAwIFIKL0ZvbnQgMTMgMCBSCj4+Ci9Db250ZW50cyA2IDAgUgo+PgplbmRvYmoKMTQg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAxNyAw IFIKPj4KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoKMTggMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAyMSAwIFIKPj4KL0NvbnRlbnRzIDE5 IDAgUgo+PgplbmRvYmoKMjIgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRm9udCAyNSAwIFIKPj4KL0NvbnRlbnRzIDIzIDAgUgo+PgplbmRvYmoKMyAw IG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo1IDAgUgoxNCAwIFIKMTggMCBSCjIyIDAg UgpdIC9Db3VudCA0Cj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2Vz IDMgMCBSCj4+CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRlL05hbWUvUjQvVFIv SWRlbnRpdHk+PgplbmRvYmoKMTIgMCBvYmoKPDwvUjQKNCAwIFI+PgplbmRvYmoKMTMgMCBv YmoKPDwvUjkKOSAwIFIvUjExCjExIDAgUj4+CmVuZG9iagoxNyAwIG9iago8PC9SOQo5IDAg Ui9SMTEKMTEgMCBSPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1I5CjkgMCBSL1IxMQoxMSAwIFI+ PgplbmRvYmoKMjUgMCBvYmoKPDwvUjkKOSAwIFIvUjExCjExIDAgUj4+CmVuZG9iago4IDAg b2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvVGltZXMtUm9tYW4+PgplbmRv YmoKOSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L1RpbWVzLVJvbWFuL1R5cGUv Rm9udC9OYW1lL1I5Pj4KZW5kb2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3Iv Rm9udE5hbWUvVGltZXMtSXRhbGljPj4KZW5kb2JqCjExIDAgb2JqCjw8L1N1YnR5cGUvVHlw ZTEvQmFzZUZvbnQvVGltZXMtSXRhbGljL1R5cGUvRm9udC9OYW1lL1IxMT4+CmVuZG9iagoy IDAgb2JqCjw8L1Byb2R1Y2VyKEVTUCBHaG9zdHNjcmlwdCA3LjA3KT4+ZW5kb2JqCnhyZWYK MCAyNgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDY0NDkgMDAwMDAgbiAKMDAwMDAwNzAx OSAwMDAwMCBuIAowMDAwMDA2MzY5IDAwMDAwIG4gCjAwMDAwMDY0OTcgMDAwMDAgbiAKMDAw MDAwNTc3NyAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDEzOTkgMDAwMDAg biAKMDAwMDAwNjc0NiAwMDAwMCBuIAowMDAwMDA2ODA3IDAwMDAwIG4gCjAwMDAwMDY4ODAg MDAwMDAgbiAKMDAwMDAwNjk0MyAwMDAwMCBuIAowMDAwMDA2NTUyIDAwMDAwIG4gCjAwMDAw MDY1ODIgMDAwMDAgbiAKMDAwMDAwNTkzNyAwMDAwMCBuIAowMDAwMDAxNDE5IDAwMDAwIG4g CjAwMDAwMDI4MzQgMDAwMDAgbiAKMDAwMDAwNjYyMyAwMDAwMCBuIAowMDAwMDA2MDgxIDAw MDAwIG4gCjAwMDAwMDI4NTUgMDAwMDAgbiAKMDAwMDAwNDMzNyAwMDAwMCBuIAowMDAwMDA2 NjY0IDAwMDAwIG4gCjAwMDAwMDYyMjUgMDAwMDAgbiAKMDAwMDAwNDM1OCAwMDAwMCBuIAow MDAwMDA1NzU2IDAwMDAwIG4gCjAwMDAwMDY3MDUgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6 ZSAyNiAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgo+PgpzdGFydHhyZWYKNzA2OQolJUVPRgo= --------------010400010004030801000000-- From owner-ietf-pkix@mail.imc.org Wed May 4 17:46:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14138 for ; Wed, 4 May 2005 17:46:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44KutR2008858; Wed, 4 May 2005 13:56:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44Kutej008857; Wed, 4 May 2005 13:56:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Kus9d008848 for ; Wed, 4 May 2005 13:56:55 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j44Ku1a9003486 for ; Wed, 4 May 2005 16:56:01 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j44Kto9q009747 for ; Wed, 4 May 2005 16:55:50 -0400 (EDT) Message-ID: <42793714.90503@nist.gov> Date: Wed, 04 May 2005 16:56:52 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: name constraints on uniformResourceIdentifiers in 3280bis References: <4278E0BA.7020706@nist.gov> In-Reply-To: <4278E0BA.7020706@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit All, The new text in section 4.2.1.10 (Name Constraints) of 3280bis for imposing name constraints on URIs was added based on comments from some of the members of the design team. After further consideration, most of the members of the design team decided that the additional flexibility provided by the proposed new rules were not absolutely necessary and that adding this additional flexibility could cause problems for existing clients. So, unless there are objections from the working group, the -01 draft of 3280bis will revert to the RFC 3280 rules for name constraints on URIs. (The -01 draft will still require that internationalized domain names be compared as specified in section 7 of 3280bis). Dave David A. Cooper wrote: > 3280bis disposition of comments: > > 21) There is a need to be able to specify name constraints for URIs > that limit schemes that may be specified. > > 3280bis includes an extended set of rules for specifying name > constraints on URIs. From owner-ietf-pkix@mail.imc.org Thu May 5 04:19:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01621 for ; Thu, 5 May 2005 04:19:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j457Soja053458; Thu, 5 May 2005 00:28:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j457SoiR053456; Thu, 5 May 2005 00:28:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth03.mail.atl.earthlink.net (smtpauth03.mail.atl.earthlink.net [209.86.89.63]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j457SoZJ053445 for ; Thu, 5 May 2005 00:28:50 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.4]) by smtpauth03.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DTamn-0001Zc-6O; Thu, 05 May 2005 03:28:49 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:Date:To:From:Subject:Content-Type; b=MKVMfi8oLTbBdw1uGdivP9dFxPwGH0X9AS4JTUiRrfjgqgWHCHB9ivhi2gSsnKAk; Mime-Version: 1.0 Message-Id: Date: Thu, 5 May 2005 00:10:26 -0700 To: "X.509":; From: "Hoyt L. Kesterson II" Subject: Defect reports against X.509 Content-Type: text/html; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47874241ab66785ff6de41cf0f164e7efc3a7069264c324fa7c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Defect reports against X.509
Hello

I have posted two defect reports on the server

DR 310 - Unrecognized CRL and CRL entry extensions
DR 311 - Differences between crl and crl entry extensions

The DRs can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_310.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_311.pdf

I plan to submit these solutions in DTCs, within the next four weeks, for formal voting in ISO. If there are any concerns about the proposed solutions, please let me know as soon as possible so any necessary modifications can be made before submitting for ballot.

   hoyt

From owner-ietf-pkix@mail.imc.org Fri May 6 05:30:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19494 for ; Fri, 6 May 2005 05:30:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j468cBWq059189; Fri, 6 May 2005 01:38:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j468cBUS059188; Fri, 6 May 2005 01:38:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j468c9OZ059141 for ; Fri, 6 May 2005 01:38:09 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 May 2005 09:38:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC3280bis: policy processing. Date: Fri, 6 May 2005 09:38:06 +0100 Message-ID: Thread-Topic: RFC3280bis: policy processing. Thread-Index: AcVQ5joX8lJSC3shRF6u2SbO1EJWVABLvLiw From: "Stefan Santesson" To: "David A. Cooper" , "Stephen Henson" Cc: "pkix" X-OriginalArrivalTime: 06 May 2005 08:38:03.0779 (UTC) FILETIME=[EB258530:01C55216] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j468cAOZ059179 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit David, Another aspect of this strikes me. That is what happens when a policy mapping extension maps from one issuer domain policy to several subject domain policies. The text in X.509 has noticed the need to duplicate the row (node in RFC 3280) for the issuer domain policy to accommodate both mappings. Reading this corresponding text from RFC 3280 it seems that the corresponding creation of a new node is not specified in RFC 3280 which would result in the same node being overwritten twice with a new subject domain policy, resulting in a loss of the first mapping. Unless I misread this, this seems to be a bug that we do need to fix. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of David A. Cooper > Sent: den 4 maj 2005 21:20 > To: Stephen Henson > Cc: pkix > Subject: Re: RFC3280bis: policy processing. > > Steve, > > A few of the members of the design team spent some time reviewing the > issue that you brought up below. We agree that X.509 and RFC 3280 > differ as you describe and that in some circumstances the outputs of the > algorithms could differ. However, we do not believe that the > differences in the two algorithms will result in different outcomes in > any realistic scenarios and so we do not believe that it is necessary to > change 3280bis to align with X.509. > > An example of where X.509 and RFC 3280 could produce different results > is shown in "X509vsRFC3280_policyMappings.pdf" (attached). Pages 1 and > 2 describe Certification Path 1 and the steps that would result from > processing this certification path under X.509. Under X.509 the output > consists of a authorities-constrained-policy-set of {1, 2} whereas under > RFC 3280 the authorities-constrained-policy-set would be {1}. Note > however, that the first certificate in the path include a policyMappings > extension that maps from policy 1 to policy 2. So, the outcome of path > validation would effectively be the same in either case unless the > user-initial-policy-set included the subjectDomainPolicy from the policy > mapping (2), but not the issuerDomainPolicy (1). This seem unlikely. > On page 3, Certification Path 2 demonstrates that RFC 3280 would get the > same result as X.509 if the first certificate in the certification path > explicitly asserted policy 2 in addition to asserting policy 1. > > As shown in "MorePolicyMappingOddities.pdf", it turns out that a number > of unusual things can happen when the policyMappings extension is > included in a certificate that also asserts anyPolicy. These oddities > occur in both X.509 and RFC 3280. But, as before, they would only > result in a different outcome for path validation if the > user-initial-policy-set asserted a policy that appeared as a > subjectDomainPolicy in the policyMappings extension but did not assert > the corresponding issuerDomainPolicy. So, while the results are > unusual, it does not seem that it is necessary to make any changes to > the algorithm. > > Dave > > Stephen Henson wrote: > > > While I was checking the X509 policy processing against the RFC3280 > > version I've noticed what I believe to be a discrepancy between the two. > > > > In RFC3280 the policy mapping processing is described in 6.1.4 b(1) as: > > > >> (1) If the policy_mapping variable is greater than 0, for each node > >> in the valid_policy_tree of depth i where ID-P is the valid_policy, > >> set expected_policy_set to the set of subjectDomainPolicy values that > >> are specified as equivalent to ID-P by the policy mapping extension. > >> > >> If no node of depth i in the valid_policy_tree has a valid_policy of > >> ID-P but there is a node of depth i with a valid_policy of anyPolicy, > >> then generate a child node of the node of depth i-1 that has a > >> valid_policy of anyPolicy as follows: > > > > Whereas the corresponding text in X509 is in 10.5.2 d): > > > >> process any policy mappings extension by, for each mapping identified > >> in the extension, locate all rows in the > >> authorities-constrained-policy-set table whose [path-depth] column > >> entry is equal to the issuer domain policy value in the extension, > >> and write the subject domain policy value from the extension in the > >> [path-depth+1] column entry of the same row. If the extension maps an > >> issuer domain policy to more than one subject domain policy, then the > >> affected row must be copied and the new entry added to each row. If > >> the value in authoritiesconstrained- policy-set[0, path-depth] is > >> any-policy, then write each issuer domain policy identifier from the > >> policy mappings extension in the [path-depth] column, making > >> duplicate rows as necessary and retaining qualifiers if they are > >> present, and write the subject domain policy value from the extension > >> in the [pathdepth+ 1] column entry of the same row. > > > > > > Translating this into RFC3280 terms it appears the processing of > > anyPolicy is different. > > > > In RFC3280 a new node is added only if a node of depth i doesn't exist > > with a valid policy of ID-P. > > > > In X509 it appears to be saying a new node is added unconditionally. > > > > I believe this difference could result in different outputs from the > > algorithm. In particular the X509 processing will (significantly) > > result in nodes whose parent is anyPolicy which will not appear in the > > RFC3280 version. > > > > Steve. > From owner-ietf-pkix@mail.imc.org Fri May 6 09:49:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16190 for ; Fri, 6 May 2005 09:49:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46CuT63067316; Fri, 6 May 2005 05:56:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j46CuThN067315; Fri, 6 May 2005 05:56:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46CuS12067292 for ; Fri, 6 May 2005 05:56:28 -0700 (PDT) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from future-is.orange.co.uk ([193.35.129.169] helo=[10.40.179.196]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.46) id 1DU2NV-000BDC-GF; Fri, 06 May 2005 13:56:26 +0100 Message-ID: <427B6965.60901@drh-consultancy.demon.co.uk> Date: Fri, 06 May 2005 13:56:05 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Santesson CC: "David A. Cooper" , pkix Subject: Re: RFC3280bis: policy processing. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan Santesson wrote: > David, > > Another aspect of this strikes me. > > That is what happens when a policy mapping extension maps from one > issuer domain policy to several subject domain policies. > > The text in X.509 has noticed the need to duplicate the row (node in RFC > 3280) for the issuer domain policy to accommodate both mappings. > > Reading this corresponding text from RFC 3280 it seems that the > corresponding creation of a new node is not specified in RFC 3280 which > would result in the same node being overwritten twice with a new subject > domain policy, resulting in a loss of the first mapping. > > Unless I misread this, this seems to be a bug that we do need to fix. > I believe this is the same issue (albeit from a different direction) I queried before in this thread on 22 November last year. Steve. From owner-ietf-pkix@mail.imc.org Fri May 6 10:53:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22797 for ; Fri, 6 May 2005 10:53:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46Csj0b066483; Fri, 6 May 2005 05:54:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j46Csj3i066481; Fri, 6 May 2005 05:54:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46CsgOu066456 for ; Fri, 6 May 2005 05:54:44 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j46CqQa9004027; Fri, 6 May 2005 08:52:26 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j46Cpn9q023053; Fri, 6 May 2005 08:51:50 -0400 (EDT) Message-ID: <427B68A8.1040205@nist.gov> Date: Fri, 06 May 2005 08:52:56 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: RFC3280bis: policy processing. References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030500040500090801030508" X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------030500040500090801030508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stefan Santesson wrote: >David, > >Another aspect of this strikes me. > >That is what happens when a policy mapping extension maps from one >issuer domain policy to several subject domain policies. > >The text in X.509 has noticed the need to duplicate the row (node in RFC >3280) for the issuer domain policy to accommodate both mappings. > >Reading this corresponding text from RFC 3280 it seems that the >corresponding creation of a new node is not specified in RFC 3280 which >would result in the same node being overwritten twice with a new subject >domain policy, resulting in a loss of the first mapping. > >Unless I misread this, this seems to be a bug that we do need to fix. > > Stefan, In RFC 3280, this is addressed by maintaining, within a single node, the set of policies that appear as subject domain policies for a given issuerDomainPolicy (the expected_policy_set): 6.1.4 Preparation for Certificate i+1 To prepare for processing of certificate i+1, perform the following steps for certificate i: (b) If a policy mappings extension is present, then for each issuerDomainPolicy ID-P in the policy mappings extension: (1) If the policy_mapping variable is greater than 0, for each node in the valid_policy_tree of depth i where ID-P is the valid_policy, set expected_policy_set to the set of subjectDomainPolicy values that are specified as equivalent to ID-P by the policy mappings extension. Take, for example figure 6 from RFC 3280: +-----------------+ | Red | +-----------------+ | {} | +-----------------+ node of depth i-1 | {Gold, Silver} | +-----------------+ / \ / \ / \ / \ +-----------------+ +-----------------+ | Gold | | Silver | +-----------------+ +-----------------+ | {} | | {} | +-----------------+ nodes of +-----------------+ | {Gold} | depth i | {Silver} | +-----------------+ +-----------------+ Figure 6. Processing unmatched policies when the certificate policies extension specifies anyPolicy This subtree would be created as a result of: _certificate i-1_: certificatePolicies: Red policyMappings: issuerDomainPolicy: Red subjectDomainPolicy: Gold issuerDomainPolicy: Red subjectDomainPolicy: Silver _ certificate i_: certificatePolicies: Gold, Silver Dave --------------030500040500090801030508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stefan Santesson wrote: 
David,

Another aspect of this strikes me.

That is what happens when a policy mapping extension maps from one
issuer domain policy to several subject domain policies.

The text in X.509 has noticed the need to duplicate the row (node in RFC
3280) for the issuer domain policy to accommodate both mappings.

Reading this corresponding text from RFC 3280 it seems that the
corresponding creation of a new node is not specified in RFC 3280 which
would result in the same node being overwritten twice with a new subject
domain policy, resulting in a loss of the first mapping.

Unless I misread this, this seems to be a bug that we do need to fix.

Stefan,

In RFC 3280, this is addressed by maintaining, within a single node, the set of policies that appear as subject domain policies for a given issuerDomainPolicy (the expected_policy_set):
6.1.4  Preparation for Certificate i+1

   To prepare for processing of certificate i+1, perform the following
   steps for certificate i:

      (b)  If a policy mappings extension is present, then for each
      issuerDomainPolicy ID-P in the policy mappings extension:

         (1)  If the policy_mapping variable is greater than 0, for each
         node in the valid_policy_tree of depth i where ID-P is the
         valid_policy, set expected_policy_set to the set of
         subjectDomainPolicy values that are specified as equivalent to
         ID-P by the policy mappings extension.
Take, for example figure 6 from RFC 3280:
                          +-----------------+
                          |      Red        |
                          +-----------------+
                          |       {}        |
                          +-----------------+ node of depth i-1
                          |  {Gold, Silver} |
                          +-----------------+
                             /           \
                            /             \
                           /               \
                          /                 \
            +-----------------+          +-----------------+
            |      Gold       |          |     Silver      |
            +-----------------+          +-----------------+
            |       {}        |          |       {}        |
            +-----------------+ nodes of +-----------------+
            |     {Gold}      | depth i  |    {Silver}     |
            +-----------------+          +-----------------+

         Figure 6.  Processing unmatched policies when the certificate
         policies extension specifies anyPolicy
This subtree would be created as a result of:

certificate i-1:
certificatePolicies:  Red
policyMappings:
    issuerDomainPolicy: Red
    subjectDomainPolicy: Gold

    issuerDomainPolicy: Red
    subjectDomainPolicy: Silver

certificate i:
certificatePolicies: Gold, Silver



Dave
--------------030500040500090801030508-- From owner-ietf-pkix@mail.imc.org Fri May 6 12:00:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04418 for ; Fri, 6 May 2005 12:00:30 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46F1jok094276; Fri, 6 May 2005 08:01:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j46F1jQF094275; Fri, 6 May 2005 08:01:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46F1h6q094240 for ; Fri, 6 May 2005 08:01:44 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 16:01:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC3280bis: policy processing. Date: Fri, 6 May 2005 16:01:41 +0100 Message-ID: Thread-Topic: RFC3280bis: policy processing. Thread-Index: AcVSOvZ7kjZdkgoCRm+Z4EYVCYta0QAEKasw From: "Stefan Santesson" To: "David A. Cooper" Cc: "pkix" X-OriginalArrivalTime: 06 May 2005 15:01:37.0786 (UTC) FILETIME=[80904DA0:01C5524C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46F1i6q094261 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks David, you are absolutely right. This property just slipped my mind for a moment. Stefan Santesson Program Manager, Standards Liaison Windows Security   ________________________________________ From: David A. Cooper [mailto:david.cooper@nist.gov] Sent: den 6 maj 2005 14:53 To: Stefan Santesson Cc: pkix Subject: Re: RFC3280bis: policy processing. Stefan Santesson wrote: David, Another aspect of this strikes me. That is what happens when a policy mapping extension maps from one issuer domain policy to several subject domain policies. The text in X.509 has noticed the need to duplicate the row (node in RFC 3280) for the issuer domain policy to accommodate both mappings. Reading this corresponding text from RFC 3280 it seems that the corresponding creation of a new node is not specified in RFC 3280 which would result in the same node being overwritten twice with a new subject domain policy, resulting in a loss of the first mapping. Unless I misread this, this seems to be a bug that we do need to fix. Stefan, In RFC 3280, this is addressed by maintaining, within a single node, the set of policies that appear as subject domain policies for a given issuerDomainPolicy (the expected_policy_set): 6.1.4  Preparation for Certificate i+1    To prepare for processing of certificate i+1, perform the following    steps for certificate i:       (b)  If a policy mappings extension is present, then for each       issuerDomainPolicy ID-P in the policy mappings extension:          (1)  If the policy_mapping variable is greater than 0, for each          node in the valid_policy_tree of depth i where ID-P is the          valid_policy, set expected_policy_set to the set of          subjectDomainPolicy values that are specified as equivalent to          ID-P by the policy mappings extension. Take, for example figure 6 from RFC 3280:                           +-----------------+                           |      Red        |                           +-----------------+                           |       {}        |                           +-----------------+ node of depth i-1                           |  {Gold, Silver} |                           +-----------------+                              /           \                             /             \                            /               \                           /                 \             +-----------------+          +-----------------+             |      Gold       |          |     Silver      |             +-----------------+          +-----------------+             |       {}        |          |       {}        |             +-----------------+ nodes of +-----------------+             |     {Gold}      | depth i  |    {Silver}     |             +-----------------+          +-----------------+          Figure 6.  Processing unmatched policies when the certificate          policies extension specifies anyPolicy This subtree would be created as a result of: certificate i-1: certificatePolicies:  Red policyMappings:     issuerDomainPolicy: Red     subjectDomainPolicy: Gold     issuerDomainPolicy: Red     subjectDomainPolicy: Silver certificate i: certificatePolicies: Gold, Silver Dave From owner-ietf-pkix@mail.imc.org Fri May 6 22:17:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04216 for ; Fri, 6 May 2005 22:17:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j470K0Fe086605; Fri, 6 May 2005 17:20:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j470K0UZ086604; Fri, 6 May 2005 17:20:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j470JxRL086577 for ; Fri, 6 May 2005 17:19:59 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j470Ig626566; Fri, 6 May 2005 17:18:42 -0700 (PDT) Message-Id: <200505070018.j470Ig626566@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4059 on Internet X.509 Public Key Infrastructure Warranty Certificate Extension Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 May 2005 17:18:42 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4059 Title: Internet X.509 Public Key Infrastructure Warranty Certificate Extension Author(s): D. Linsenbardt, S. Pontius, A. Sturgeon Status: Informational Date: May 2005 Mailbox: dlinsenbardt@spyrus.com, spontius@spyrus.com, asturgeon@spyrus.com Pages: 9 Characters: 17904 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-warranty-extn-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4059.txt This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050506171655.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4059 --OtherAccess Content-Type: Message/External-body; name="rfc4059.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050506171655.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Mon May 9 10:21:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18001 for ; Mon, 9 May 2005 10:21:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49D6wap060393; Mon, 9 May 2005 06:06:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49D6wfW060392; Mon, 9 May 2005 06:06:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49D6v6o060347 for ; Mon, 9 May 2005 06:06:57 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA10012; Mon, 9 May 2005 15:21:39 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005050915064398:376 ; Mon, 9 May 2005 15:06:43 +0200 Message-ID: <427F609E.6020309@bull.net> Date: Mon, 09 May 2005 15:07:42 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: Stefan Santesson , pkix Subject: Re: Comments on References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/05/2005 15:06:44, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/05/2005 15:06:45, Serialize complete at 09/05/2005 15:06:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, > Here is a quote from RFC 3280. To me, it is clear that a CRL issuer has > a certificate. True, a CRL issuer (that is different from the CA that has issued the target certificate) has a certificate. So we both strongly agree on this this. :-) > Obviously, all certificates need to be validated, which > includes certification path construction and certification path validation. When a sentence starts with "Obviously", it means that it is not so obvious. :-| The real question is whether the CRL issuer certificate has to be verified using rules (i.e. a validation policy) which are independent from the certification path construction of the target certificate. RFC 3280 does not provide a crystal clear answer to that question. If the rules are different, then you MAY end up with a security issue (see my previous explanations). The current "recommendations" that are in the security considerations section do NOT solve this issue in the general case. If the rules are the same, i.e. the path used to validate the certification path from the certificate are also used, then there is no security issue. I do not think it would be good to hide this issue in the proposed draft. Anyway, the current "recommendations" do NOT solve the issue and are thus not acceptable and so this section cannot stand as it is. Denis > 5.1.1.3 signatureValue > > The signatureValue field contains a digital signature computed upon > the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList > is used as the input to the signature function. This signature value > is encoded as a BIT STRING and included in the CRL signatureValue > field. The details of this process are specified for each of the > supported algorithms in [PKIXALGS]. > > CAs that are also CRL issuers MAY use one private key to digitally > sign certificates and CRLs, or MAY use separate private keys to > digitally sign certificates and CRLs. When separate private keys are > employed, each of the public keys associated with these private keys > is placed in a separate certificate, one with the keyCertSign bit set > in the key usage extension, and one with the cRLSign bit set in the > key usage extension (section 4.2.1.3). When separate private keys > are employed, certificates issued by the CA contain one authority key > identifier, and the corresponding CRLs contain a different authority > key identifier. The use of separate CA certificates for validation > of certificate signatures and CRL signatures can offer improved > security characteristics; however, it imposes a burden on > applications, and it might limit interoperability. Many applications > construct a certification path, and then validate the certification > path (section 6). CRL checking in turn requires a separate > certification path to be constructed and validated for the CA's CRL > signature validation certificate. Applications that perform CRL > checking MUST support certification path validation when certificates > and CRLs are digitally signed with the same CA private key. These > applications SHOULD support certification path validation when > certificates and CRLs are digitally signed with different CA private > keys. > > Russ > > At 01:12 PM 4/28/2005, Denis Pinkas wrote: > >> Stefan and Russ, >> >>> Denis, >> >> >>> Russ and I have taken a thorough look at your text proposal and we have >>> edited a counter proposal where we try to meet your needs as much as >>> possible without compromising what we think is the core purpose of the >>> draft (to enable certificate discovery bottom-up). >> >> >>> The conclusion is that we suggest changes to the introduction section >>> but we keep the old security considerations intact. >> >> >> I would suggest that a merge would need to be done between the "old" >> security considerations section and the "new" one. >> >> The "old" security considerations section is mentionning a solution >> which does NOT suppress the problem, but minimize the risk only in >> case the CAs are really "honest". >> >> The old" security considerations section does not provide a solution >> in case the name collsion between two CRL issuer name is deliberate, >> whereas the "new" security considerations section provides a secure >> solution in one case and clearly mentions that all other cases are >> dependant about "zillions" of *local* trust conditions which cannot >> all be standardized. >> >> The main purpose of a security considerations section is to provide >> the adequate warnings and solutions when they exist and not to hide >> the problems. >> >>> That is not because >>> we necessarily disagree with all of the statements in your proposal, but >>> in the cases we don't, we still think it is out of scope for this work. >> >> >> This is clearly within the scope of a security considerations section. >> >>> The new introduction proposal based on your input is: >>> -------------------------------------------------------------- >>> RFC 3280 [PKIX1] specifies the validation of certification paths. One >>> aspect involves the determination that a certificate has not been >>> revoked, and one revocation checking mechanism is the Certificate >>> Revocation List (CRL). CRL validation is also specified in RFC 3280, >> >> >> I would love this last sentence to be true but the reality is that: >> "CRL validation is NOT specified in RFC 3280". :-( >> >>> which involves the constructions of a valid certification path for the >>> CRL issuer. >> >> >> There is no such a statement in RFC 3280. >> >>> Building a CRL issuer certification path from the signer of >> >> >> There is no notion of "CRL issuer certification path" in RFC 3280. >> The primary requirement is to make sure that the CRL issuer designated >> by the CA is indeed the right one. In some (but not all) cases, I mean >> among the zillion of cases, there MAY be a need to construct a CRL >> issuer certification path. >> >>> the CRL to a trust anchor is straightforward when the certificate of the >>> CRL issuer is present in the certification path associated with the >>> target certificate, but it can be complex in other situations. >> >> >> From the comments above, you can see that I cannot agree with the >> above revised text. The remaining of the text is acceptable in >> general, but could possibly be slightly revised to be more in >> continuation with the changes there are needed above (i.e. it is not >> cast in concrete). >> >> Denis >> >>> There are several legitimate scenarios where the certificate of the CRL >>> issuer is not present, or easily discovered, from the target >>> certification path. This can be the case when indirect CRLs are used, >>> when the certification Authority (CA) that issued the target certificate >>> changes its certificate signing key, or when the CA employs separate >>> keys for certificate signing and CRL signing. >>> Methods of finding the certificate of the CRL issuer are currently >>> available, such as though an accessible directory location or through >>> use of the Subject Information Access extension in intermediary CA >>> certificates. >>> Directory lookup requires existence and access to a directory that has >>> been populated with all of the necessary certificates. The Subject >>> Information Access extension, which supports building the CRL issuer >>> certification path top-down (in the direction from the trust anchor to >>> the CRL issuer), requires that some certificates in the CRL issuer >>> certification path includes an appropriate Subject Information Access >>> extension. >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths >>> through the Authority Information Access extension, where the >>> id-ad-caIssuers access method may specify one or more accessLocation >>> fields that reference CA certificates associated with the certificate >>> containing this extension. >>> This document enables the use of the Authority Information Access >>> extension in CRLs, enabling a CRL checking application to use the access >>> method (id-ad-caIssuers) to locate certificates that may be useful in >>> the construction of a valid CRL issuer certification path to an >>> appropriate trust anchor. >>> >>> Stefan Santesson >>> Program Manager, Standards Liaison >>> Windows Security >>> >>> >>>> -----Original Message----- >>>> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>>> Sent: den 18 april 2005 13:41 >>>> To: Stefan Santesson >>>> Cc: Russ Housley; pkix >>>> Subject: Re: Comments on >>>> >>>> Stefan, >>>> >>>> >>>>> Denis, >>>> >>>> >>>>> I will come back and comment on your text proposals, but before >>>> >>> that, >>> >>>> > a few questions/comments: >>>> >>>> >>>>> >>>> >>>> >>>>>>> You point out some well known issues related to the lack of >>>>>> >>> absolute >>> >>>>>>> cryptographic binding between CRL and certificates where the >>>>>>> certificate and CRL is not signed by the same key. >>>>>> >>>>>> >>>>>> Not really. It is indeed possible to have an absolute cryptographic >>>>>> binding between CRL and certificates where the certificate and CRL >>>>> >>> is >>> >>>> not >>>> >>>>>> signed by the same key, but the key point is that proposed >>>>> >>> extension >>> >>>> >> is *not* the means to provide such a binding (and you agree with >>> >>> this >>> >>>> >> further down in this e-mail). >>>> >>>> >>>>> We agree that this extension does not add to the concept of >>>>> cryptographic binding. But how do you mean it can be done? >>>> >>>> >>>> Would this mean that you believed this could not be done ? :-) >>>> >>>> I already provided the information, but since at that time you were >>>> focussing on another issue, you probably missed the point. >>>> >>>> I would encourage you to read again that thread, but I will provide a >>>> short >>>> reply here to your question. >>>> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains >>> >>> the >>> >>>> DN >>>> of the CRL Issuer and we all know that CAs are free to assign the DNs >>> >>> they >>> >>>> wish. The next point is for a verifier to make sure that the DN which >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was >>> >>> meant >>> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same >>> >>> DN. >>> >>>> The >>>> CRL Issuer will have a certificate issued by a CA. >>>> >>>> Case a): the CA that has issued that certificate is the same as the CA >>>> that >>>> has issued the target certificate (which contains the hereabove >>> >>> mentionned >>> >>>> CRL DP). This is easy to check for a verifier since the verifier must >>>> first >>>> build the certification path and then test the revocation status of >>> >>> every >>> >>>> element of the path. So the verifier knows the validated sequence of >>> >>> DNs >>> >>>> starting from a self-signed certificate. It must then use the same >>>> sequence >>>> of DNs to validate the CRL Issuer certificate. >>>> >>>> This is a general rule which does not require any extra local trust >>>> information. >>>> >>>> Case b) : the CA that has issued that certificate is NOT the same as >>> >>> the >>> >>>> CA >>>> that has issued the target certificate. This case requires extra >>> >>> *0local* >>> >>>> trust information. There are many such trust conditions possible and >>> >>> thus >>> >>>> this cannot be defined in general. Cases a) and b) are thus not >>> >>> equivalent >>> >>>> and have to be distinguished. >>>> >>>> >>>>> >>>> >>>> >>>>>>> This draft only introduces a new way to locate certificates >>>>>>> that can be helpful in building this path. >>>>>> >>>>>> >>>>>> At least one sentence of which we both agree ! >>>>>> It should be copied and pasted in the abstract. >>>>> >>>>> >>>>> Good, then I suggest that we leave unrelated topics out of this >>>> >>> draft >>> >>>>> and focus on the issues that are related to this limited scope. >>>> >>>> >>>> This is what I did in my proposal, except that we need to have a >>> >>> security >>> >>>> considerations section and the goal of that section is not to hide >>>> problems >>>> but to correctly warn users. Thus why an informatiove annex on the >>> >>> topics >>> >>>> mentionned in the security considerations section would be quite >>> >>> useful. >>> >>>> In fact, its content would be along the lines of the explanations >>> >>> which >>> >>>> are >>>> just above. >>>> >>>> I hope this e-mail will help us to progress. >>>> >>>> Denis >>>> >>>> >>>>> Stefan Santesson >>>>> Program Manager - Standards Liaison >>>>> Windows Security >>>> >> >> > > From owner-ietf-pkix@mail.imc.org Mon May 9 11:06:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23866 for ; Mon, 9 May 2005 11:06:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49D4wGj059644; Mon, 9 May 2005 06:04:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49D4w27059643; Mon, 9 May 2005 06:04:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49D4uQN059593 for ; Mon, 9 May 2005 06:04:57 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA06584; Mon, 9 May 2005 15:19:22 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005050915042621:374 ; Mon, 9 May 2005 15:04:26 +0200 Message-ID: <427F6014.1030001@bull.net> Date: Mon, 09 May 2005 15:05:24 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: Russ Housley , pkix Subject: Re: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/05/2005 15:04:26, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/05/2005 15:04:31, Serialize complete at 09/05/2005 15:04:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan, I made the e-mail shorter. Your main arguments are the following: ========================================================================== [Stefan] But it has to provide a warning to something that is introduced by the standard. This standard does not introduce the concept of CRL signature checking or CRL issuer certificate validation, so that is clearly out of scope. More about that below; [Denis] See below the last answer and also my arguments in the soon-to-be-posted answer to Russ. ========================================================================== > > RFC 3280 [PKIX1] specifies the validation of certification paths. > > One aspect involves the determination that a certificate has not been > > revoked, and one revocation checking mechanism is the Certificate > > Revocation List (CRL). CRL validation is also specified in RFC 3280, > I would love this last sentence to be true but the reality is that: > "CRL validation is NOT specified in RFC 3280". :-( [Stefan] In fact it is. RFC 3280, Section 6.3.3 CRL processing - on page 85: (f) Obtain and validate the certification path for the complete CRL issuer. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set. (g) Validate the signature on the complete CRL using the public key validated in step (f). [Denis] The text does not say how to obtain and validate the certification path for the complete (???) CRL issuer. The text is not clear enough so that two implementors only looking at this sentence will provide interoperable implementations. ========================================================================== [Stefan] It is my hope that the provided responses here can help convince you to change your mind about that. If it doesn't I still argue that the place to specify requirements and security considerations for CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. [Denis] I can agree with your last sentence, ... which means that it should not be in the main body of the document. In the security considerations section, text is free and we shall at the very minimum warn implementers and we should provide some guidance. When the same certification path (i.e. the path used to validate the target certificate) is used, then there is no security issue: this should be said. For all other cases, there MAY be problems: this should also be said. It is as simple as that. Denis From owner-ietf-pkix@mail.imc.org Mon May 9 12:26:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02439 for ; Mon, 9 May 2005 12:26:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49FWiU8072697; Mon, 9 May 2005 08:32:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49FWiSB072696; Mon, 9 May 2005 08:32:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j49FWf22072683 for ; Mon, 9 May 2005 08:32:43 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 31827 invoked by uid 0); 9 May 2005 15:31:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.5.34) by woodstock.binhost.com with SMTP; 9 May 2005 15:31:05 -0000 Message-Id: <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 09 May 2005 11:24:15 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: pkix In-Reply-To: <427F6014.1030001@bull.net> References: <427F6014.1030001@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: RFC 3280 does not tell an implementor how for locate certificates for any certification path construction. There are several extensions that provide pointers that may help an implementation, but other approaches to obtaining the same certificates are always permitted. I would fully expect an implementation to check any local cache before accessing a repository. The CRL AIA extension fits this pattern. A method for locating a certificate is provided, but any other mechanism for locating the same certificate is acceptable. Russ >Stefan, > >I made the e-mail shorter. Your main arguments are the following: > >========================================================================== > >[Stefan] But it has to provide a warning to something that is introduced >by the standard. This standard does not introduce the concept of CRL >signature checking or CRL issuer certificate validation, so that is >clearly out of scope. More about that below; > >[Denis] See below the last answer and also my arguments in the >soon-to-be-posted answer to Russ. > >========================================================================== > > > > > RFC 3280 [PKIX1] specifies the validation of certification paths. > > > One aspect involves the determination that a certificate has not been > > > revoked, and one revocation checking mechanism is the Certificate > > > Revocation List (CRL). CRL validation is also specified in RFC 3280, > > > I would love this last sentence to be true but the reality is that: > > "CRL validation is NOT specified in RFC 3280". :-( > >[Stefan] In fact it is. > >RFC 3280, Section 6.3.3 CRL processing - on page 85: > > (f) Obtain and validate the certification path for the complete CRL > issuer. If a key usage extension is present in the CRL issuer's > certificate, verify that the cRLSign bit is set. > > (g) Validate the signature on the complete CRL using the public key > validated in step (f). > >[Denis] The text does not say how to obtain and validate the certification >path for the complete (???) CRL issuer. The text is not clear enough so >that two implementors only looking at this sentence will provide >interoperable implementations. > >========================================================================== > >[Stefan] It is my hope that the provided responses here can help >convince you to change your mind about that. If it doesn't I still argue >that the place to specify requirements and security considerations for >CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. > >[Denis] I can agree with your last sentence, ... which means that it >should not be in the main body of the document. In the security >considerations section, text is free and we shall at the very minimum warn >implementers and we should provide some guidance. When the same >certification path (i.e. the path used to validate the target certificate) >is used, then there is no security issue: this should be said. For all >other cases, there MAY be problems: this should also be said. It is as >simple as that. > >Denis > From owner-ietf-pkix@mail.imc.org Mon May 9 12:27:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02624 for ; Mon, 9 May 2005 12:27:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49FWoZD072717; Mon, 9 May 2005 08:32:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49FWoD0072716; Mon, 9 May 2005 08:32:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j49FWnZf072710 for ; Mon, 9 May 2005 08:32:49 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 31850 invoked by uid 0); 9 May 2005 15:31:06 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.5.34) by woodstock.binhost.com with SMTP; 9 May 2005 15:31:06 -0000 Message-Id: <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 09 May 2005 11:30:44 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: ietf-pkix@imc.org In-Reply-To: <427F609E.6020309@bull.net> References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated. You say that it is not clear what validation policy needs to be used, but this is completely irrelevant to the discussion of the CRL AIA extension. This extension aid in certification path construction, not the validation of the path once it is constructed. There are many factors which need to be considered in the validation of the CRL issue certificate. The values of the key usage extension and the certificate policies extension are two that jump to mind. There are probably more if I spend the time to consider each possible scenario. In my opinion, this document is ready for WG Last Call. Russ At 09:07 AM 5/9/2005, Denis Pinkas wrote: >Russ, > > > Here is a quote from RFC 3280. To me, it is clear that a CRL issuer has > > a certificate. > >True, a CRL issuer (that is different from the CA that has issued the target >certificate) has a certificate. So we both strongly agree on this this. :-) > > > Obviously, all certificates need to be validated, which > > includes certification path construction and certification path validation. > >When a sentence starts with "Obviously", it means that it is not so obvious. >:-| > >The real question is whether the CRL issuer certificate has to be verified >using rules (i.e. a validation policy) which are independent from the >certification path construction of the target certificate. RFC 3280 does not >provide a crystal clear answer to that question. > >If the rules are different, then you MAY end up with a security issue (see >my previous explanations). The current "recommendations" that are in the >security considerations section do NOT solve this issue in the general case. > >If the rules are the same, i.e. the path used to validate the certification >path from the certificate are also used, then there is no security issue. > >I do not think it would be good to hide this issue in the proposed draft. >Anyway, the current "recommendations" do NOT solve the issue and are thus >not acceptable and so this section cannot stand as it is. > >Denis > > > 5.1.1.3 signatureValue > > > > The signatureValue field contains a digital signature computed upon > > the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList > > is used as the input to the signature function. This signature value > > is encoded as a BIT STRING and included in the CRL signatureValue > > field. The details of this process are specified for each of the > > supported algorithms in [PKIXALGS]. > > > > CAs that are also CRL issuers MAY use one private key to digitally > > sign certificates and CRLs, or MAY use separate private keys to > > digitally sign certificates and CRLs. When separate private keys are > > employed, each of the public keys associated with these private keys > > is placed in a separate certificate, one with the keyCertSign bit set > > in the key usage extension, and one with the cRLSign bit set in the > > key usage extension (section 4.2.1.3). When separate private keys > > are employed, certificates issued by the CA contain one authority key > > identifier, and the corresponding CRLs contain a different authority > > key identifier. The use of separate CA certificates for validation > > of certificate signatures and CRL signatures can offer improved > > security characteristics; however, it imposes a burden on > > applications, and it might limit interoperability. Many applications > > construct a certification path, and then validate the certification > > path (section 6). CRL checking in turn requires a separate > > certification path to be constructed and validated for the CA's CRL > > signature validation certificate. Applications that perform CRL > > checking MUST support certification path validation when certificates > > and CRLs are digitally signed with the same CA private key. These > > applications SHOULD support certification path validation when > > certificates and CRLs are digitally signed with different CA private > > keys. > > > > Russ > > > > At 01:12 PM 4/28/2005, Denis Pinkas wrote: > > > >> Stefan and Russ, > >> > >>> Denis, > >> > >> > >>> Russ and I have taken a thorough look at your text proposal and we have > >>> edited a counter proposal where we try to meet your needs as much as > >>> possible without compromising what we think is the core purpose of the > >>> draft (to enable certificate discovery bottom-up). > >> > >> > >>> The conclusion is that we suggest changes to the introduction section > >>> but we keep the old security considerations intact. > >> > >> > >> I would suggest that a merge would need to be done between the "old" > >> security considerations section and the "new" one. > >> > >> The "old" security considerations section is mentionning a solution > >> which does NOT suppress the problem, but minimize the risk only in > >> case the CAs are really "honest". > >> > >> The old" security considerations section does not provide a solution > >> in case the name collsion between two CRL issuer name is deliberate, > >> whereas the "new" security considerations section provides a secure > >> solution in one case and clearly mentions that all other cases are > >> dependant about "zillions" of *local* trust conditions which cannot > >> all be standardized. > >> > >> The main purpose of a security considerations section is to provide > >> the adequate warnings and solutions when they exist and not to hide > >> the problems. > >> > >>> That is not because > >>> we necessarily disagree with all of the statements in your proposal, but > >>> in the cases we don't, we still think it is out of scope for this work. > >> > >> > >> This is clearly within the scope of a security considerations section. > >> > >>> The new introduction proposal based on your input is: > >>> -------------------------------------------------------------- > >>> RFC 3280 [PKIX1] specifies the validation of certification paths. One > >>> aspect involves the determination that a certificate has not been > >>> revoked, and one revocation checking mechanism is the Certificate > >>> Revocation List (CRL). CRL validation is also specified in RFC 3280, > >> > >> > >> I would love this last sentence to be true but the reality is that: > >> "CRL validation is NOT specified in RFC 3280". :-( > >> > >>> which involves the constructions of a valid certification path for the > >>> CRL issuer. > >> > >> > >> There is no such a statement in RFC 3280. > >> > >>> Building a CRL issuer certification path from the signer of > >> > >> > >> There is no notion of "CRL issuer certification path" in RFC 3280. > >> The primary requirement is to make sure that the CRL issuer designated > >> by the CA is indeed the right one. In some (but not all) cases, I mean > >> among the zillion of cases, there MAY be a need to construct a CRL > >> issuer certification path. > >> > >>> the CRL to a trust anchor is straightforward when the certificate of the > >>> CRL issuer is present in the certification path associated with the > >>> target certificate, but it can be complex in other situations. > >> > >> > >> From the comments above, you can see that I cannot agree with the > >> above revised text. The remaining of the text is acceptable in > >> general, but could possibly be slightly revised to be more in > >> continuation with the changes there are needed above (i.e. it is not > >> cast in concrete). > >> > >> Denis > >> > >>> There are several legitimate scenarios where the certificate of the CRL > >>> issuer is not present, or easily discovered, from the target > >>> certification path. This can be the case when indirect CRLs are used, > >>> when the certification Authority (CA) that issued the target certificate > >>> changes its certificate signing key, or when the CA employs separate > >>> keys for certificate signing and CRL signing. > >>> Methods of finding the certificate of the CRL issuer are currently > >>> available, such as though an accessible directory location or through > >>> use of the Subject Information Access extension in intermediary CA > >>> certificates. > >>> Directory lookup requires existence and access to a directory that has > >>> been populated with all of the necessary certificates. The Subject > >>> Information Access extension, which supports building the CRL issuer > >>> certification path top-down (in the direction from the trust anchor to > >>> the CRL issuer), requires that some certificates in the CRL issuer > >>> certification path includes an appropriate Subject Information Access > >>> extension. > >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths > >>> through the Authority Information Access extension, where the > >>> id-ad-caIssuers access method may specify one or more accessLocation > >>> fields that reference CA certificates associated with the certificate > >>> containing this extension. > >>> This document enables the use of the Authority Information Access > >>> extension in CRLs, enabling a CRL checking application to use the access > >>> method (id-ad-caIssuers) to locate certificates that may be useful in > >>> the construction of a valid CRL issuer certification path to an > >>> appropriate trust anchor. > >>> > >>> Stefan Santesson > >>> Program Manager, Standards Liaison > >>> Windows Security > >>> > >>> > >>>> -----Original Message----- > >>>> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >>>> Sent: den 18 april 2005 13:41 > >>>> To: Stefan Santesson > >>>> Cc: Russ Housley; pkix > >>>> Subject: Re: Comments on > >>>> > >>>> Stefan, > >>>> > >>>> > >>>>> Denis, > >>>> > >>>> > >>>>> I will come back and comment on your text proposals, but before > >>>> > >>> that, > >>> > >>>> > a few questions/comments: > >>>> > >>>> > >>>>> > >>>> > >>>> > >>>>>>> You point out some well known issues related to the lack of > >>>>>> > >>> absolute > >>> > >>>>>>> cryptographic binding between CRL and certificates where the > >>>>>>> certificate and CRL is not signed by the same key. > >>>>>> > >>>>>> > >>>>>> Not really. It is indeed possible to have an absolute cryptographic > >>>>>> binding between CRL and certificates where the certificate and CRL > >>>>> > >>> is > >>> > >>>> not > >>>> > >>>>>> signed by the same key, but the key point is that proposed > >>>>> > >>> extension > >>> > >>>> >> is *not* the means to provide such a binding (and you agree with > >>> > >>> this > >>> > >>>> >> further down in this e-mail). > >>>> > >>>> > >>>>> We agree that this extension does not add to the concept of > >>>>> cryptographic binding. But how do you mean it can be done? > >>>> > >>>> > >>>> Would this mean that you believed this could not be done ? :-) > >>>> > >>>> I already provided the information, but since at that time you were > >>>> focussing on another issue, you probably missed the point. > >>>> > >>>> I would encourage you to read again that thread, but I will provide a > >>>> short > >>>> reply here to your question. > >>>> > >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains > >>> > >>> the > >>> > >>>> DN > >>>> of the CRL Issuer and we all know that CAs are free to assign the DNs > >>> > >>> they > >>> > >>>> wish. The next point is for a verifier to make sure that the DN which > >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was > >>> > >>> meant > >>> > >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same > >>> > >>> DN. > >>> > >>>> The > >>>> CRL Issuer will have a certificate issued by a CA. > >>>> > >>>> Case a): the CA that has issued that certificate is the same as the CA > >>>> that > >>>> has issued the target certificate (which contains the hereabove > >>> > >>> mentionned > >>> > >>>> CRL DP). This is easy to check for a verifier since the verifier must > >>>> first > >>>> build the certification path and then test the revocation status of > >>> > >>> every > >>> > >>>> element of the path. So the verifier knows the validated sequence of > >>> > >>> DNs > >>> > >>>> starting from a self-signed certificate. It must then use the same > >>>> sequence > >>>> of DNs to validate the CRL Issuer certificate. > >>>> > >>>> This is a general rule which does not require any extra local trust > >>>> information. > >>>> > >>>> Case b) : the CA that has issued that certificate is NOT the same as > >>> > >>> the > >>> > >>>> CA > >>>> that has issued the target certificate. This case requires extra > >>> > >>> *0local* > >>> > >>>> trust information. There are many such trust conditions possible and > >>> > >>> thus > >>> > >>>> this cannot be defined in general. Cases a) and b) are thus not > >>> > >>> equivalent > >>> > >>>> and have to be distinguished. > >>>> > >>>> > >>>>> > >>>> > >>>> > >>>>>>> This draft only introduces a new way to locate certificates > >>>>>>> that can be helpful in building this path. > >>>>>> > >>>>>> > >>>>>> At least one sentence of which we both agree ! > >>>>>> It should be copied and pasted in the abstract. > >>>>> > >>>>> > >>>>> Good, then I suggest that we leave unrelated topics out of this > >>>> > >>> draft > >>> > >>>>> and focus on the issues that are related to this limited scope. > >>>> > >>>> > >>>> This is what I did in my proposal, except that we need to have a > >>> > >>> security > >>> > >>>> considerations section and the goal of that section is not to hide > >>>> problems > >>>> but to correctly warn users. Thus why an informatiove annex on the > >>> > >>> topics > >>> > >>>> mentionned in the security considerations section would be quite > >>> > >>> useful. > >>> > >>>> In fact, its content would be along the lines of the explanations > >>> > >>> which > >>> > >>>> are > >>>> just above. > >>>> > >>>> I hope this e-mail will help us to progress. > >>>> > >>>> Denis > >>>> > >>>> > >>>>> Stefan Santesson > >>>>> Program Manager - Standards Liaison > >>>>> Windows Security > >>>> > >> > >> > > > > > > > From owner-ietf-pkix@mail.imc.org Mon May 9 20:17:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00815 for ; Mon, 9 May 2005 20:17:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49NOnoi011377; Mon, 9 May 2005 16:24:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49NOnYH011376; Mon, 9 May 2005 16:24:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49NOif0011366 for ; Mon, 9 May 2005 16:24:45 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 00:24:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on Date: Tue, 10 May 2005 00:24:34 +0100 Message-ID: Thread-Topic: Comments on Thread-Index: AcVUl9MJMVgI74HMQmuqqLZ8fHOU/wAVNaWg From: "Stefan Santesson" To: "Denis Pinkas" Cc: "Russ Housley" , "pkix" X-OriginalArrivalTime: 09 May 2005 23:24:39.0162 (UTC) FILETIME=[454E0DA0:01C554EE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49NOjf0011370 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, I think all arguments have been spoken about this by now. The bottom line is not whether your arguments are right or wrong. It is that your discussion is out of scope for this draft. In the end of the day that is the reason why we are reluctant to add your proposed text in this document. Unless you can find others to support you, you are in clear minority and as such I will not agree to do any changes. I second WG last call for this draft. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 9 maj 2005 15:05 > To: Stefan Santesson > Cc: Russ Housley; pkix > Subject: Re: Comments on > > Stefan, > > I made the e-mail shorter. Your main arguments are the following: > > ======================================================================== == > > [Stefan] But it has to provide a warning to something that is introduced > by the standard. This standard does not introduce the concept of CRL > signature checking or CRL issuer certificate validation, so that is > clearly out of scope. More about that below; > > [Denis] See below the last answer and also my arguments in the > soon-to-be-posted answer to Russ. > > ======================================================================== == > > > > > RFC 3280 [PKIX1] specifies the validation of certification paths. > > > One aspect involves the determination that a certificate has not been > > > revoked, and one revocation checking mechanism is the Certificate > > > Revocation List (CRL). CRL validation is also specified in RFC 3280, > > > I would love this last sentence to be true but the reality is that: > > "CRL validation is NOT specified in RFC 3280". :-( > > [Stefan] In fact it is. > > RFC 3280, Section 6.3.3 CRL processing - on page 85: > > (f) Obtain and validate the certification path for the complete CRL > issuer. If a key usage extension is present in the CRL issuer's > certificate, verify that the cRLSign bit is set. > > (g) Validate the signature on the complete CRL using the public key > validated in step (f). > > [Denis] The text does not say how to obtain and validate the certification > path for the complete (???) CRL issuer. The text is not clear enough so > that > two implementors only looking at this sentence will provide interoperable > implementations. > > ======================================================================== == > > [Stefan] It is my hope that the provided responses here can help > convince you to change your mind about that. If it doesn't I still argue > that the place to specify requirements and security considerations for > CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. > > [Denis] I can agree with your last sentence, ... which means that it > should > not be in the main body of the document. In the security considerations > section, text is free and we shall at the very minimum warn implementers > and > we should provide some guidance. When the same certification path (i.e. > the > path used to validate the target certificate) is used, then there is no > security issue: this should be said. For all other cases, there MAY be > problems: this should also be said. It is as simple as that. > > Denis From owner-ietf-pkix@mail.imc.org Tue May 10 03:51:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25521 for ; Tue, 10 May 2005 03:51:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A709DK089112; Tue, 10 May 2005 00:00:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4A709hl089111; Tue, 10 May 2005 00:00:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin.bull.net (odin.bull.net [192.90.70.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A707WS089059 for ; Tue, 10 May 2005 00:00:07 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id JAA16410; Tue, 10 May 2005 09:09:47 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051008595610:22 ; Tue, 10 May 2005 08:59:56 +0200 Message-ID: <42805C27.8090209@bull.net> Date: Tue, 10 May 2005 09:00:55 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org Subject: Re: Comments on References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:59:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:59:58, Serialize complete at 10/05/2005 08:59:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, > Denis: > > Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated. > > You say that it is not clear what validation policy needs to be used, > but this is completely irrelevant to the discussion of the CRL AIA > extension. This extension aid in certification path construction, not > the validation of the path once it is constructed. Not exactly, it could "help" finding a wrong path ! > There are many factors which need to be considered in the validation of > the CRL issue certificate. The values of the key usage extension and > the certificate policies extension are two that jump to mind. There are > probably more if I spend the time to consider each possible scenario. One simple rule would allow no security problem at all and I wonder why you have so much resistance to mention it. > In my opinion, this document is ready for WG Last Call. As an editor of the draft, I may understand your position; but it is up the the PKIX chairs to decide whether or not the document is ready for WG last call. Once again the current Security Considerations section is not acceptable. In particular it contains a "MUST" statement that cannot be placed in such a section and which is in addition fully wrong. Hereabove is the last one from draft 01: 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. As means of reducing problems and security issues related to issuer name collisions, CA names SHOULD be formed in a way that reduce the likelihood of name collisions. Implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at the same trust anchor. Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Hereafter is a "minimalist" rewriting of this section, if we take the choice to mention the issue, but not to provide any secure solution (mentioning insecure or insufficient solutions is not appropriate). Two sentences have thus been deleted. 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Denis > Russ > > > At 09:07 AM 5/9/2005, Denis Pinkas wrote: > >> Russ, >> >> > Here is a quote from RFC 3280. To me, it is clear that a CRL issuer >> has >> > a certificate. >> >> True, a CRL issuer (that is different from the CA that has issued the >> target >> certificate) has a certificate. So we both strongly agree on this >> this. :-) >> >> > Obviously, all certificates need to be validated, which >> > includes certification path construction and certification path >> validation. >> >> When a sentence starts with "Obviously", it means that it is not so >> obvious. >> :-| >> >> The real question is whether the CRL issuer certificate has to be >> verified >> using rules (i.e. a validation policy) which are independent from the >> certification path construction of the target certificate. RFC 3280 >> does not >> provide a crystal clear answer to that question. >> >> If the rules are different, then you MAY end up with a security issue >> (see >> my previous explanations). The current "recommendations" that are in the >> security considerations section do NOT solve this issue in the general >> case. >> >> If the rules are the same, i.e. the path used to validate the >> certification >> path from the certificate are also used, then there is no security issue. >> >> I do not think it would be good to hide this issue in the proposed draft. >> Anyway, the current "recommendations" do NOT solve the issue and are >> thus not acceptable and so this section cannot stand as it is. >> >> Denis >> >> > 5.1.1.3 signatureValue >> > >> > The signatureValue field contains a digital signature computed upon >> > the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded >> tbsCertList >> > is used as the input to the signature function. This signature >> value >> > is encoded as a BIT STRING and included in the CRL signatureValue >> > field. The details of this process are specified for each of the >> > supported algorithms in [PKIXALGS]. >> > >> > CAs that are also CRL issuers MAY use one private key to digitally >> > sign certificates and CRLs, or MAY use separate private keys to >> > digitally sign certificates and CRLs. When separate private keys >> are >> > employed, each of the public keys associated with these private keys >> > is placed in a separate certificate, one with the keyCertSign bit >> set >> > in the key usage extension, and one with the cRLSign bit set in the >> > key usage extension (section 4.2.1.3). When separate private keys >> > are employed, certificates issued by the CA contain one authority >> key >> > identifier, and the corresponding CRLs contain a different authority >> > key identifier. The use of separate CA certificates for validation >> > of certificate signatures and CRL signatures can offer improved >> > security characteristics; however, it imposes a burden on >> > applications, and it might limit interoperability. Many >> applications >> > construct a certification path, and then validate the certification >> > path (section 6). CRL checking in turn requires a separate >> > certification path to be constructed and validated for the CA's CRL >> > signature validation certificate. Applications that perform CRL >> > checking MUST support certification path validation when >> certificates >> > and CRLs are digitally signed with the same CA private key. These >> > applications SHOULD support certification path validation when >> > certificates and CRLs are digitally signed with different CA private >> > keys. >> > >> > Russ >> > >> > At 01:12 PM 4/28/2005, Denis Pinkas wrote: >> > >> >> Stefan and Russ, >> >> >> >>> Denis, >> >> >> >> >> >>> Russ and I have taken a thorough look at your text proposal and we >> have >> >>> edited a counter proposal where we try to meet your needs as much as >> >>> possible without compromising what we think is the core purpose of >> the >> >>> draft (to enable certificate discovery bottom-up). >> >> >> >> >> >>> The conclusion is that we suggest changes to the introduction section >> >>> but we keep the old security considerations intact. >> >> >> >> >> >> I would suggest that a merge would need to be done between the "old" >> >> security considerations section and the "new" one. >> >> >> >> The "old" security considerations section is mentionning a solution >> >> which does NOT suppress the problem, but minimize the risk only in >> >> case the CAs are really "honest". >> >> >> >> The old" security considerations section does not provide a solution >> >> in case the name collsion between two CRL issuer name is deliberate, >> >> whereas the "new" security considerations section provides a secure >> >> solution in one case and clearly mentions that all other cases are >> >> dependant about "zillions" of *local* trust conditions which cannot >> >> all be standardized. >> >> >> >> The main purpose of a security considerations section is to provide >> >> the adequate warnings and solutions when they exist and not to hide >> >> the problems. >> >> >> >>> That is not because >> >>> we necessarily disagree with all of the statements in your >> proposal, but >> >>> in the cases we don't, we still think it is out of scope for this >> work. >> >> >> >> >> >> This is clearly within the scope of a security considerations section. >> >> >> >>> The new introduction proposal based on your input is: >> >>> -------------------------------------------------------------- >> >>> RFC 3280 [PKIX1] specifies the validation of certification paths. >> One >> >>> aspect involves the determination that a certificate has not been >> >>> revoked, and one revocation checking mechanism is the Certificate >> >>> Revocation List (CRL). CRL validation is also specified in RFC 3280, >> >> >> >> >> >> I would love this last sentence to be true but the reality is that: >> >> "CRL validation is NOT specified in RFC 3280". :-( >> >> >> >>> which involves the constructions of a valid certification path for >> the >> >>> CRL issuer. >> >> >> >> >> >> There is no such a statement in RFC 3280. >> >> >> >>> Building a CRL issuer certification path from the signer of >> >> >> >> >> >> There is no notion of "CRL issuer certification path" in RFC 3280. >> >> The primary requirement is to make sure that the CRL issuer designated >> >> by the CA is indeed the right one. In some (but not all) cases, I mean >> >> among the zillion of cases, there MAY be a need to construct a CRL >> >> issuer certification path. >> >> >> >>> the CRL to a trust anchor is straightforward when the certificate >> of the >> >>> CRL issuer is present in the certification path associated with the >> >>> target certificate, but it can be complex in other situations. >> >> >> >> >> >> From the comments above, you can see that I cannot agree with the >> >> above revised text. The remaining of the text is acceptable in >> >> general, but could possibly be slightly revised to be more in >> >> continuation with the changes there are needed above (i.e. it is not >> >> cast in concrete). >> >> >> >> Denis >> >> >> >>> There are several legitimate scenarios where the certificate of >> the CRL >> >>> issuer is not present, or easily discovered, from the target >> >>> certification path. This can be the case when indirect CRLs are >> used, >> >>> when the certification Authority (CA) that issued the target >> certificate >> >>> changes its certificate signing key, or when the CA employs separate >> >>> keys for certificate signing and CRL signing. >> >>> Methods of finding the certificate of the CRL issuer are currently >> >>> available, such as though an accessible directory location or through >> >>> use of the Subject Information Access extension in intermediary CA >> >>> certificates. >> >>> Directory lookup requires existence and access to a directory that >> has >> >>> been populated with all of the necessary certificates. The Subject >> >>> Information Access extension, which supports building the CRL issuer >> >>> certification path top-down (in the direction from the trust >> anchor to >> >>> the CRL issuer), requires that some certificates in the CRL issuer >> >>> certification path includes an appropriate Subject Information Access >> >>> extension. >> >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification >> paths >> >>> through the Authority Information Access extension, where the >> >>> id-ad-caIssuers access method may specify one or more accessLocation >> >>> fields that reference CA certificates associated with the certificate >> >>> containing this extension. >> >>> This document enables the use of the Authority Information Access >> >>> extension in CRLs, enabling a CRL checking application to use the >> access >> >>> method (id-ad-caIssuers) to locate certificates that may be useful in >> >>> the construction of a valid CRL issuer certification path to an >> >>> appropriate trust anchor. >> >>> >> >>> Stefan Santesson >> >>> Program Manager, Standards Liaison >> >>> Windows Security >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >> >>>> Sent: den 18 april 2005 13:41 >> >>>> To: Stefan Santesson >> >>>> Cc: Russ Housley; pkix >> >>>> Subject: Re: Comments on >> >>>> >> >>>> Stefan, >> >>>> >> >>>> >> >>>>> Denis, >> >>>> >> >>>> >> >>>>> I will come back and comment on your text proposals, but before >> >>>> >> >>> that, >> >>> >> >>>> > a few questions/comments: >> >>>> >> >>>> >> >>>>> >> >>>> >> >>>> >> >>>>>>> You point out some well known issues related to the lack of >> >>>>>> >> >>> absolute >> >>> >> >>>>>>> cryptographic binding between CRL and certificates where the >> >>>>>>> certificate and CRL is not signed by the same key. >> >>>>>> >> >>>>>> >> >>>>>> Not really. It is indeed possible to have an absolute >> cryptographic >> >>>>>> binding between CRL and certificates where the certificate and CRL >> >>>>> >> >>> is >> >>> >> >>>> not >> >>>> >> >>>>>> signed by the same key, but the key point is that proposed >> >>>>> >> >>> extension >> >>> >> >>>> >> is *not* the means to provide such a binding (and you agree with >> >>> >> >>> this >> >>> >> >>>> >> further down in this e-mail). >> >>>> >> >>>> >> >>>>> We agree that this extension does not add to the concept of >> >>>>> cryptographic binding. But how do you mean it can be done? >> >>>> >> >>>> >> >>>> Would this mean that you believed this could not be done ? :-) >> >>>> >> >>>> I already provided the information, but since at that time you were >> >>>> focussing on another issue, you probably missed the point. >> >>>> >> >>>> I would encourage you to read again that thread, but I will >> provide a >> >>>> short >> >>>> reply here to your question. >> >>>> >> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains >> >>> >> >>> the >> >>> >> >>>> DN >> >>>> of the CRL Issuer and we all know that CAs are free to assign the >> DNs >> >>> >> >>> they >> >>> >> >>>> wish. The next point is for a verifier to make sure that the DN >> which >> >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was >> >>> >> >>> meant >> >>> >> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same >> >>> >> >>> DN. >> >>> >> >>>> The >> >>>> CRL Issuer will have a certificate issued by a CA. >> >>>> >> >>>> Case a): the CA that has issued that certificate is the same as >> the CA >> >>>> that >> >>>> has issued the target certificate (which contains the hereabove >> >>> >> >>> mentionned >> >>> >> >>>> CRL DP). This is easy to check for a verifier since the verifier >> must >> >>>> first >> >>>> build the certification path and then test the revocation status of >> >>> >> >>> every >> >>> >> >>>> element of the path. So the verifier knows the validated sequence of >> >>> >> >>> DNs >> >>> >> >>>> starting from a self-signed certificate. It must then use the same >> >>>> sequence >> >>>> of DNs to validate the CRL Issuer certificate. >> >>>> >> >>>> This is a general rule which does not require any extra local trust >> >>>> information. >> >>>> >> >>>> Case b) : the CA that has issued that certificate is NOT the same as >> >>> >> >>> the >> >>> >> >>>> CA >> >>>> that has issued the target certificate. This case requires extra >> >>> >> >>> *0local* >> >>> >> >>>> trust information. There are many such trust conditions possible and >> >>> >> >>> thus >> >>> >> >>>> this cannot be defined in general. Cases a) and b) are thus not >> >>> >> >>> equivalent >> >>> >> >>>> and have to be distinguished. >> >>>> >> >>>> >> >>>>> >> >>>> >> >>>> >> >>>>>>> This draft only introduces a new way to locate certificates >> >>>>>>> that can be helpful in building this path. >> >>>>>> >> >>>>>> >> >>>>>> At least one sentence of which we both agree ! >> >>>>>> It should be copied and pasted in the abstract. >> >>>>> >> >>>>> >> >>>>> Good, then I suggest that we leave unrelated topics out of this >> >>>> >> >>> draft >> >>> >> >>>>> and focus on the issues that are related to this limited scope. >> >>>> >> >>>> >> >>>> This is what I did in my proposal, except that we need to have a >> >>> >> >>> security >> >>> >> >>>> considerations section and the goal of that section is not to hide >> >>>> problems >> >>>> but to correctly warn users. Thus why an informatiove annex on the >> >>> >> >>> topics >> >>> >> >>>> mentionned in the security considerations section would be quite >> >>> >> >>> useful. >> >>> >> >>>> In fact, its content would be along the lines of the explanations >> >>> >> >>> which >> >>> >> >>>> are >> >>>> just above. >> >>>> >> >>>> I hope this e-mail will help us to progress. >> >>>> >> >>>> Denis >> >>>> >> >>>> >> >>>>> Stefan Santesson >> >>>>> Program Manager - Standards Liaison >> >>>>> Windows Security >> >>>> >> >> >> >> >> > >> > >> >> >> > > From owner-ietf-pkix@mail.imc.org Tue May 10 04:52:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29506 for ; Tue, 10 May 2005 04:52:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6wqv6088629; Mon, 9 May 2005 23:58:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4A6wqOH088628; Mon, 9 May 2005 23:58:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin.bull.net (odin.bull.net [192.90.70.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6wmMb088568 for ; Mon, 9 May 2005 23:58:49 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id JAA18358; Tue, 10 May 2005 09:08:28 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051008583774:19 ; Tue, 10 May 2005 08:58:37 +0200 Message-ID: <42805BD8.4050608@bull.net> Date: Tue, 10 May 2005 08:59:36 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: pkix Subject: Re: Comments on References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:58:37, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:58:39, Serialize complete at 10/05/2005 08:58:39 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, Your statement below is correct, but does not answer to any of my questions/issues. In particular, the last one. I am still awaiting your responses. Denis > Denis: > > RFC 3280 does not tell an implementor how for locate certificates for > any certification path construction. There are several extensions that > provide pointers that may help an implementation, but other approaches > to obtaining the same certificates are always permitted. I would fully > expect an implementation to check any local cache before accessing a > repository. > > The CRL AIA extension fits this pattern. A method for locating a > certificate is provided, but any other mechanism for locating the same > certificate is acceptable. > > Russ > >> Stefan, >> >> I made the e-mail shorter. Your main arguments are the following: >> >> ========================================================================== >> >> >> [Stefan] But it has to provide a warning to something that is introduced >> by the standard. This standard does not introduce the concept of CRL >> signature checking or CRL issuer certificate validation, so that is >> clearly out of scope. More about that below; >> >> [Denis] See below the last answer and also my arguments in the >> soon-to-be-posted answer to Russ. >> >> ========================================================================== >> >> >> >> > > RFC 3280 [PKIX1] specifies the validation of certification paths. >> > > One aspect involves the determination that a certificate has not been >> > > revoked, and one revocation checking mechanism is the Certificate >> > > Revocation List (CRL). CRL validation is also specified in RFC 3280, >> >> > I would love this last sentence to be true but the reality is that: >> > "CRL validation is NOT specified in RFC 3280". :-( >> >> [Stefan] In fact it is. >> >> RFC 3280, Section 6.3.3 CRL processing - on page 85: >> >> (f) Obtain and validate the certification path for the complete CRL >> issuer. If a key usage extension is present in the CRL issuer's >> certificate, verify that the cRLSign bit is set. >> >> (g) Validate the signature on the complete CRL using the public key >> validated in step (f). >> >> [Denis] The text does not say how to obtain and validate the >> certification path for the complete (???) CRL issuer. The text is not >> clear enough so that two implementors only looking at this sentence >> will provide interoperable implementations. >> >> ========================================================================== >> >> >> [Stefan] It is my hope that the provided responses here can help >> convince you to change your mind about that. If it doesn't I still argue >> that the place to specify requirements and security considerations for >> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. >> >> [Denis] I can agree with your last sentence, ... which means that it >> should not be in the main body of the document. In the security >> considerations section, text is free and we shall at the very minimum >> warn implementers and we should provide some guidance. When the same >> certification path (i.e. the path used to validate the target >> certificate) is used, then there is no security issue: this should be >> said. For all other cases, there MAY be problems: this should also be >> said. It is as simple as that. >> >> Denis >> > > From owner-ietf-pkix@mail.imc.org Tue May 10 04:59:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29979 for ; Tue, 10 May 2005 04:59:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6xhTt088921; Mon, 9 May 2005 23:59:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4A6xh0I088920; Mon, 9 May 2005 23:59:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin.bull.net (odin.bull.net [192.90.70.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6xfiF088874 for ; Mon, 9 May 2005 23:59:42 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id JAA42264; Tue, 10 May 2005 09:09:20 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051008593076:20 ; Tue, 10 May 2005 08:59:30 +0200 Message-ID: <42805C0D.3030207@bull.net> Date: Tue, 10 May 2005 09:00:29 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: Russ Housley , pkix Subject: Re: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:59:30, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:59:31, Serialize complete at 10/05/2005 08:59:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan, > Denis, > I think all arguments have been spoken about this by now. ... but not all replied. > The bottom line is not whether your arguments are right or wrong. It is > that your discussion is out of scope for this draft. > In the end of the day that is the reason why we are reluctant to add > your proposed text in this document. More important, I am requesting the *deletion* of two sentences in the security considerations section. See my response posted to Russ. Denis > Unless you can find others to > support you, you are in clear minority and as such I will not agree to > do any changes. > > I second WG last call for this draft. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: den 9 maj 2005 15:05 >>To: Stefan Santesson >>Cc: Russ Housley; pkix >>Subject: Re: Comments on >> >>Stefan, >> >>I made the e-mail shorter. Your main arguments are the following: >> >> > > ======================================================================== > == > >>[Stefan] But it has to provide a warning to something that is > > introduced > >>by the standard. This standard does not introduce the concept of CRL >>signature checking or CRL issuer certificate validation, so that is >>clearly out of scope. More about that below; >> >>[Denis] See below the last answer and also my arguments in the >>soon-to-be-posted answer to Russ. >> >> > > ======================================================================== > == > >> >> > > RFC 3280 [PKIX1] specifies the validation of certification paths. >> > > One aspect involves the determination that a certificate has not > > been > >> > > revoked, and one revocation checking mechanism is the Certificate >> > > Revocation List (CRL). CRL validation is also specified in RFC > > 3280, > >> > I would love this last sentence to be true but the reality is that: >> > "CRL validation is NOT specified in RFC 3280". :-( >> >>[Stefan] In fact it is. >> >>RFC 3280, Section 6.3.3 CRL processing - on page 85: >> >> (f) Obtain and validate the certification path for the complete > > CRL > >> issuer. If a key usage extension is present in the CRL issuer's >> certificate, verify that the cRLSign bit is set. >> >> (g) Validate the signature on the complete CRL using the public > > key > >> validated in step (f). >> >>[Denis] The text does not say how to obtain and validate the > > certification > >>path for the complete (???) CRL issuer. The text is not clear enough > > so > >>that >>two implementors only looking at this sentence will provide > > interoperable > >>implementations. >> >> > > ======================================================================== > == > >>[Stefan] It is my hope that the provided responses here can help >>convince you to change your mind about that. If it doesn't I still > > argue > >>that the place to specify requirements and security considerations for >>CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. >> >>[Denis] I can agree with your last sentence, ... which means that it >>should >>not be in the main body of the document. In the security > > considerations > >>section, text is free and we shall at the very minimum warn > > implementers > >>and >>we should provide some guidance. When the same certification path > > (i.e. > >>the >>path used to validate the target certificate) is used, then there is > > no > >>security issue: this should be said. For all other cases, there MAY be >>problems: this should also be said. It is as simple as that. >> >>Denis > > > From owner-ietf-pkix@mail.imc.org Tue May 10 11:52:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07589 for ; Tue, 10 May 2005 11:52:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AEn4Fm026318; Tue, 10 May 2005 07:49:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AEn4gB026317; Tue, 10 May 2005 07:49:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AEn1CL026307 for ; Tue, 10 May 2005 07:49:01 -0700 (PDT) (envelope-from dcross@microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 07:48:56 -0700 Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 07:48:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on Date: Tue, 10 May 2005 07:49:03 -0700 Message-ID: <3C69AE30038D9A4590F5EC20DCD41F680665BB8F@RED-MSG-41.redmond.corp.microsoft.com> Thread-Topic: Comments on Thread-Index: AcVVNbs3zSlsD+3rRaWiQ+PF2lgiPAAOMTdA From: "David Cross" To: "Denis Pinkas" , X-OriginalArrivalTime: 10 May 2005 14:48:55.0762 (UTC) FILETIME=[6403AB20:01C5556F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AEn1CL026311 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis: I have to disagree on removal of the text. I have not seen any objections from the list or working group to this inclusion. I have to disagree with your assertion that removing the text is a more secure recommendation. The below text (slightly edited to my taste) is an excellent recommendation from an implementation standoint and a security consideration. I would personally concede that using MUST *may* be incorrect here and a SHOULD *may* be more appropriate. As a means of mitigating implementation challenges and security issues related to issuer name collisions, CA names SHOULD be formed in such a way that reduce the likelihood of name collisions. Implementations validating CRLs SHOULD ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at a common trust anchor. David B. Cross -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, May 10, 2005 12:01 AM To: Russ Housley Cc: ietf-pkix@imc.org Subject: Re: Comments on Russ, > Denis: > > Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated. > > You say that it is not clear what validation policy needs to be used, > but this is completely irrelevant to the discussion of the CRL AIA > extension. This extension aid in certification path construction, not > the validation of the path once it is constructed. Not exactly, it could "help" finding a wrong path ! > There are many factors which need to be considered in the validation > of the CRL issue certificate. The values of the key usage extension > and the certificate policies extension are two that jump to mind. > There are probably more if I spend the time to consider each possible scenario. One simple rule would allow no security problem at all and I wonder why you have so much resistance to mention it. > In my opinion, this document is ready for WG Last Call. As an editor of the draft, I may understand your position; but it is up the the PKIX chairs to decide whether or not the document is ready for WG last call. Once again the current Security Considerations section is not acceptable. In particular it contains a "MUST" statement that cannot be placed in such a section and which is in addition fully wrong. Hereabove is the last one from draft 01: 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. As means of reducing problems and security issues related to issuer name collisions, CA names SHOULD be formed in a way that reduce the likelihood of name collisions. Implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at the same trust anchor. Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Hereafter is a "minimalist" rewriting of this section, if we take the choice to mention the issue, but not to provide any secure solution (mentioning insecure or insufficient solutions is not appropriate). Two sentences have thus been deleted. 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Denis > Russ > > > At 09:07 AM 5/9/2005, Denis Pinkas wrote: > >> Russ, >> >> > Here is a quote from RFC 3280. To me, it is clear that a CRL >> > issuer >> has >> > a certificate. >> >> True, a CRL issuer (that is different from the CA that has issued the >> target >> certificate) has a certificate. So we both strongly agree on this >> this. :-) >> >> > Obviously, all certificates need to be validated, which includes >> > certification path construction and certification path >> validation. >> >> When a sentence starts with "Obviously", it means that it is not so >> obvious. >> :-| >> >> The real question is whether the CRL issuer certificate has to be >> verified using rules (i.e. a validation policy) which are independent >> from the certification path construction of the target certificate. >> RFC 3280 does not provide a crystal clear answer to that question. >> >> If the rules are different, then you MAY end up with a security issue >> (see my previous explanations). The current "recommendations" that >> are in the security considerations section do NOT solve this issue in >> the general case. >> >> If the rules are the same, i.e. the path used to validate the >> certification path from the certificate are also used, then there is >> no security issue. >> >> I do not think it would be good to hide this issue in the proposed draft. >> Anyway, the current "recommendations" do NOT solve the issue and are >> thus not acceptable and so this section cannot stand as it is. >> >> Denis >> >> > 5.1.1.3 signatureValue >> > >> > The signatureValue field contains a digital signature computed upon >> > the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded >> tbsCertList >> > is used as the input to the signature function. This signature >> value >> > is encoded as a BIT STRING and included in the CRL signatureValue >> > field. The details of this process are specified for each of the >> > supported algorithms in [PKIXALGS]. >> > >> > CAs that are also CRL issuers MAY use one private key to digitally >> > sign certificates and CRLs, or MAY use separate private keys to >> > digitally sign certificates and CRLs. When separate private >> > keys >> are >> > employed, each of the public keys associated with these private keys >> > is placed in a separate certificate, one with the keyCertSign >> > bit >> set >> > in the key usage extension, and one with the cRLSign bit set in the >> > key usage extension (section 4.2.1.3). When separate private keys >> > are employed, certificates issued by the CA contain one >> > authority >> key >> > identifier, and the corresponding CRLs contain a different authority >> > key identifier. The use of separate CA certificates for validation >> > of certificate signatures and CRL signatures can offer improved >> > security characteristics; however, it imposes a burden on >> > applications, and it might limit interoperability. Many >> applications >> > construct a certification path, and then validate the certification >> > path (section 6). CRL checking in turn requires a separate >> > certification path to be constructed and validated for the CA's CRL >> > signature validation certificate. Applications that perform CRL >> > checking MUST support certification path validation when >> certificates >> > and CRLs are digitally signed with the same CA private key. These >> > applications SHOULD support certification path validation when >> > certificates and CRLs are digitally signed with different CA private >> > keys. >> > >> > Russ >> > >> > At 01:12 PM 4/28/2005, Denis Pinkas wrote: >> > >> >> Stefan and Russ, >> >> >> >>> Denis, >> >> >> >> >> >>> Russ and I have taken a thorough look at your text proposal and >> >>> we >> have >> >>> edited a counter proposal where we try to meet your needs as much >> >>> as possible without compromising what we think is the core >> >>> purpose of >> the >> >>> draft (to enable certificate discovery bottom-up). >> >> >> >> >> >>> The conclusion is that we suggest changes to the introduction >> >>> section but we keep the old security considerations intact. >> >> >> >> >> >> I would suggest that a merge would need to be done between the "old" >> >> security considerations section and the "new" one. >> >> >> >> The "old" security considerations section is mentionning a >> >> solution which does NOT suppress the problem, but minimize the >> >> risk only in case the CAs are really "honest". >> >> >> >> The old" security considerations section does not provide a >> >> solution in case the name collsion between two CRL issuer name is >> >> deliberate, whereas the "new" security considerations section >> >> provides a secure solution in one case and clearly mentions that >> >> all other cases are dependant about "zillions" of *local* trust >> >> conditions which cannot all be standardized. >> >> >> >> The main purpose of a security considerations section is to >> >> provide the adequate warnings and solutions when they exist and >> >> not to hide the problems. >> >> >> >>> That is not because >> >>> we necessarily disagree with all of the statements in your >> proposal, but >> >>> in the cases we don't, we still think it is out of scope for this >> work. >> >> >> >> >> >> This is clearly within the scope of a security considerations section. >> >> >> >>> The new introduction proposal based on your input is: >> >>> -------------------------------------------------------------- >> >>> RFC 3280 [PKIX1] specifies the validation of certification paths. >> One >> >>> aspect involves the determination that a certificate has not been >> >>> revoked, and one revocation checking mechanism is the Certificate >> >>> Revocation List (CRL). CRL validation is also specified in RFC >> >>> 3280, >> >> >> >> >> >> I would love this last sentence to be true but the reality is that: >> >> "CRL validation is NOT specified in RFC 3280". :-( >> >> >> >>> which involves the constructions of a valid certification path >> >>> for >> the >> >>> CRL issuer. >> >> >> >> >> >> There is no such a statement in RFC 3280. >> >> >> >>> Building a CRL issuer certification path from the signer of >> >> >> >> >> >> There is no notion of "CRL issuer certification path" in RFC 3280. >> >> The primary requirement is to make sure that the CRL issuer >> >> designated by the CA is indeed the right one. In some (but not >> >> all) cases, I mean among the zillion of cases, there MAY be a need >> >> to construct a CRL issuer certification path. >> >> >> >>> the CRL to a trust anchor is straightforward when the certificate >> of the >> >>> CRL issuer is present in the certification path associated with >> >>> the target certificate, but it can be complex in other situations. >> >> >> >> >> >> From the comments above, you can see that I cannot agree with the >> >> above revised text. The remaining of the text is acceptable in >> >> general, but could possibly be slightly revised to be more in >> >> continuation with the changes there are needed above (i.e. it is >> >> not cast in concrete). >> >> >> >> Denis >> >> >> >>> There are several legitimate scenarios where the certificate of >> the CRL >> >>> issuer is not present, or easily discovered, from the target >> >>> certification path. This can be the case when indirect CRLs are >> used, >> >>> when the certification Authority (CA) that issued the target >> certificate >> >>> changes its certificate signing key, or when the CA employs >> >>> separate keys for certificate signing and CRL signing. >> >>> Methods of finding the certificate of the CRL issuer are >> >>> currently available, such as though an accessible directory >> >>> location or through use of the Subject Information Access >> >>> extension in intermediary CA certificates. >> >>> Directory lookup requires existence and access to a directory >> >>> that >> has >> >>> been populated with all of the necessary certificates. The >> >>> Subject Information Access extension, which supports building the >> >>> CRL issuer certification path top-down (in the direction from the >> >>> trust >> anchor to >> >>> the CRL issuer), requires that some certificates in the CRL >> >>> issuer certification path includes an appropriate Subject >> >>> Information Access extension. >> >>> RFC 3280 [PKIX1] provides for bottom-up discovery of >> >>> certification >> paths >> >>> through the Authority Information Access extension, where the >> >>> id-ad-caIssuers access method may specify one or more >> >>> accessLocation fields that reference CA certificates associated >> >>> with the certificate containing this extension. >> >>> This document enables the use of the Authority Information Access >> >>> extension in CRLs, enabling a CRL checking application to use the >> access >> >>> method (id-ad-caIssuers) to locate certificates that may be >> >>> useful in the construction of a valid CRL issuer certification >> >>> path to an appropriate trust anchor. >> >>> >> >>> Stefan Santesson >> >>> Program Manager, Standards Liaison Windows Security >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >> >>>> Sent: den 18 april 2005 13:41 >> >>>> To: Stefan Santesson >> >>>> Cc: Russ Housley; pkix >> >>>> Subject: Re: Comments on >> >>>> >> >>>> Stefan, >> >>>> >> >>>> >> >>>>> Denis, >> >>>> >> >>>> >> >>>>> I will come back and comment on your text proposals, but before >> >>>> >> >>> that, >> >>> >> >>>> > a few questions/comments: >> >>>> >> >>>> >> >>>>> >> >>>> >> >>>> >> >>>>>>> You point out some well known issues related to the lack of >> >>>>>> >> >>> absolute >> >>> >> >>>>>>> cryptographic binding between CRL and certificates where the >> >>>>>>> certificate and CRL is not signed by the same key. >> >>>>>> >> >>>>>> >> >>>>>> Not really. It is indeed possible to have an absolute >> cryptographic >> >>>>>> binding between CRL and certificates where the certificate and CRL >> >>>>> >> >>> is >> >>> >> >>>> not >> >>>> >> >>>>>> signed by the same key, but the key point is that proposed >> >>>>> >> >>> extension >> >>> >> >>>> >> is *not* the means to provide such a binding (and you agree with >> >>> >> >>> this >> >>> >> >>>> >> further down in this e-mail). >> >>>> >> >>>> >> >>>>> We agree that this extension does not add to the concept of >> >>>>> cryptographic binding. But how do you mean it can be done? >> >>>> >> >>>> >> >>>> Would this mean that you believed this could not be done ? :-) >> >>>> >> >>>> I already provided the information, but since at that time you were >> >>>> focussing on another issue, you probably missed the point. >> >>>> >> >>>> I would encourage you to read again that thread, but I will >> provide a >> >>>> short >> >>>> reply here to your question. >> >>>> >> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains >> >>> >> >>> the >> >>> >> >>>> DN >> >>>> of the CRL Issuer and we all know that CAs are free to assign the >> DNs >> >>> >> >>> they >> >>> >> >>>> wish. The next point is for a verifier to make sure that the DN >> which >> >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was >> >>> >> >>> meant >> >>> >> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same >> >>> >> >>> DN. >> >>> >> >>>> The >> >>>> CRL Issuer will have a certificate issued by a CA. >> >>>> >> >>>> Case a): the CA that has issued that certificate is the same as >> the CA >> >>>> that >> >>>> has issued the target certificate (which contains the hereabove >> >>> >> >>> mentionned >> >>> >> >>>> CRL DP). This is easy to check for a verifier since the verifier >> must >> >>>> first >> >>>> build the certification path and then test the revocation status of >> >>> >> >>> every >> >>> >> >>>> element of the path. So the verifier knows the validated sequence of >> >>> >> >>> DNs >> >>> >> >>>> starting from a self-signed certificate. It must then use the same >> >>>> sequence >> >>>> of DNs to validate the CRL Issuer certificate. >> >>>> >> >>>> This is a general rule which does not require any extra local trust >> >>>> information. >> >>>> >> >>>> Case b) : the CA that has issued that certificate is NOT the same as >> >>> >> >>> the >> >>> >> >>>> CA >> >>>> that has issued the target certificate. This case requires extra >> >>> >> >>> *0local* >> >>> >> >>>> trust information. There are many such trust conditions possible and >> >>> >> >>> thus >> >>> >> >>>> this cannot be defined in general. Cases a) and b) are thus not >> >>> >> >>> equivalent >> >>> >> >>>> and have to be distinguished. >> >>>> >> >>>> >> >>>>> >> >>>> >> >>>> >> >>>>>>> This draft only introduces a new way to locate certificates >> >>>>>>> that can be helpful in building this path. >> >>>>>> >> >>>>>> >> >>>>>> At least one sentence of which we both agree ! >> >>>>>> It should be copied and pasted in the abstract. >> >>>>> >> >>>>> >> >>>>> Good, then I suggest that we leave unrelated topics out of this >> >>>> >> >>> draft >> >>> >> >>>>> and focus on the issues that are related to this limited scope. >> >>>> >> >>>> >> >>>> This is what I did in my proposal, except that we need to have a >> >>> >> >>> security >> >>> >> >>>> considerations section and the goal of that section is not to hide >> >>>> problems >> >>>> but to correctly warn users. Thus why an informatiove annex on the >> >>> >> >>> topics >> >>> >> >>>> mentionned in the security considerations section would be quite >> >>> >> >>> useful. >> >>> >> >>>> In fact, its content would be along the lines of the explanations >> >>> >> >>> which >> >>> >> >>>> are >> >>>> just above. >> >>>> >> >>>> I hope this e-mail will help us to progress. >> >>>> >> >>>> Denis >> >>>> >> >>>> >> >>>>> Stefan Santesson >> >>>>> Program Manager - Standards Liaison >> >>>>> Windows Security >> >>>> >> >> >> >> >> > >> > >> >> >> > > From owner-ietf-pkix@mail.imc.org Tue May 10 15:55:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07610 for ; Tue, 10 May 2005 15:55:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AIxWEp050072; Tue, 10 May 2005 11:59:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AIxWOi050071; Tue, 10 May 2005 11:59:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4AIxVtl050062 for ; Tue, 10 May 2005 11:59:31 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 26065 invoked by uid 0); 10 May 2005 18:57:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.43.168) by woodstock.binhost.com with SMTP; 10 May 2005 18:57:35 -0000 Message-Id: <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 14:57:33 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: pkix In-Reply-To: <42805BD8.4050608@bull.net> References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The document already says that the CA and the CRL issuer need to terminate at the same trust anchor. This is the important point. I disagree that there is anything else that ought to be said in the security considerations. Russ At 02:59 AM 5/10/2005, Denis Pinkas wrote: >Russ, > >Your statement below is correct, but does not answer to any of my >questions/issues. In particular, the last one. I am still awaiting your >responses. > >Denis > >>Denis: >>RFC 3280 does not tell an implementor how for locate certificates for any >>certification path construction. There are several extensions that >>provide pointers that may help an implementation, but other approaches to >>obtaining the same certificates are always permitted. I would fully >>expect an implementation to check any local cache before accessing a >>repository. >>The CRL AIA extension fits this pattern. A method for locating a >>certificate is provided, but any other mechanism for locating the same >>certificate is acceptable. >>Russ >> >>>Stefan, >>> >>>I made the e-mail shorter. Your main arguments are the following: >>> >>>========================================================================== >>> >>>[Stefan] But it has to provide a warning to something that is introduced >>>by the standard. This standard does not introduce the concept of CRL >>>signature checking or CRL issuer certificate validation, so that is >>>clearly out of scope. More about that below; >>> >>>[Denis] See below the last answer and also my arguments in the >>>soon-to-be-posted answer to Russ. >>> >>>========================================================================== >>> >>> >>> > > RFC 3280 [PKIX1] specifies the validation of certification paths. >>> > > One aspect involves the determination that a certificate has not been >>> > > revoked, and one revocation checking mechanism is the Certificate >>> > > Revocation List (CRL). CRL validation is also specified in RFC 3280, >>> >>> > I would love this last sentence to be true but the reality is that: >>> > "CRL validation is NOT specified in RFC 3280". :-( >>> >>>[Stefan] In fact it is. >>> >>>RFC 3280, Section 6.3.3 CRL processing - on page 85: >>> >>> (f) Obtain and validate the certification path for the complete CRL >>> issuer. If a key usage extension is present in the CRL issuer's >>> certificate, verify that the cRLSign bit is set. >>> >>> (g) Validate the signature on the complete CRL using the public key >>> validated in step (f). >>> >>>[Denis] The text does not say how to obtain and validate the >>>certification path for the complete (???) CRL issuer. The text is not >>>clear enough so that two implementors only looking at this sentence will >>>provide interoperable implementations. >>> >>>========================================================================== >>> >>>[Stefan] It is my hope that the provided responses here can help >>>convince you to change your mind about that. If it doesn't I still argue >>>that the place to specify requirements and security considerations for >>>CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. >>> >>>[Denis] I can agree with your last sentence, ... which means that it >>>should not be in the main body of the document. In the security >>>considerations section, text is free and we shall at the very minimum >>>warn implementers and we should provide some guidance. When the same >>>certification path (i.e. the path used to validate the target >>>certificate) is used, then there is no security issue: this should be >>>said. For all other cases, there MAY be problems: this should also be >>>said. It is as simple as that. >>> >>>Denis > > From owner-ietf-pkix@mail.imc.org Tue May 10 16:09:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11455 for ; Tue, 10 May 2005 16:09:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJSsCu052654; Tue, 10 May 2005 12:28:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AJSscV052653; Tue, 10 May 2005 12:28:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4AJSrxI052645 for ; Tue, 10 May 2005 12:28:53 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 4329 invoked by uid 0); 10 May 2005 19:26:52 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.157.117) by woodstock.binhost.com with SMTP; 10 May 2005 19:26:52 -0000 Message-Id: <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 15:26:38 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: ietf-pkix@imc.org In-Reply-To: <42805C27.8090209@bull.net> References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: >>Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated. >>You say that it is not clear what validation policy needs to be used, but >>this is completely irrelevant to the discussion of the CRL AIA >>extension. This extension aid in certification path construction, not >>the validation of the path once it is constructed. > >Not exactly, it could "help" finding a wrong path ! Not likely. The signer of the CRL is providing a pointer to their own certificate. Path construction to locate a parent of that certificate through a complex PKI might include paths that are acceptable and paths that are unacceptable, but the certificate that contains the public key needed to validate the signature on the CRL is clearly needed. >>There are many factors which need to be considered in the validation of >>the CRL issue certificate. The values of the key usage extension and the >>certificate policies extension are two that jump to mind. There are >>probably more if I spend the time to consider each possible scenario. > >One simple rule would allow no security problem at all and I wonder why >you have so much resistance to mention it. We have that rule: The CA certificate and the CRL Issuer certificate must validate back to the same trust anchor. >>In my opinion, this document is ready for WG Last Call. > >As an editor of the draft, I may understand your position; but it is up >the the PKIX chairs to decide whether or not the document is ready for WG >last call. Correct. I included this sentence for the WG chairs. I hope they will agree with me, and that they will issue WG Last Call for this document. >Once again the current Security Considerations section is not acceptable. To you... No one else is advocating this change. I continue to believe that requiring the CA certificate and the CRL Issuer certificate to validate back to the same trust anchor resolves your concern. I am willing to add a few words to the security considerations about name collisions (my co-author may disagree), but I am not willing to use "MUST" or "SHOULD" in those words. There is absolutely nothing that a client can do to determine deal with name collisions that are subordinate to the same trust anchor. Russ From owner-ietf-pkix@mail.imc.org Tue May 10 18:09:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27324 for ; Tue, 10 May 2005 18:09:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ALQsLG063166; Tue, 10 May 2005 14:26:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4ALQs7I063165; Tue, 10 May 2005 14:26:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ALQqAg063151 for ; Tue, 10 May 2005 14:26:53 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4ALQWaF002756; Tue, 10 May 2005 17:26:33 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4ALQA9r023610; Tue, 10 May 2005 17:26:10 -0400 (EDT) Message-Id: <5.1.0.14.2.20050510170022.02cc5b08@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 May 2005 17:27:21 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: WG Last Call: AIA CRL extension Cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates working group Last Call for the specification "Internet X.509 Public Key Infrastructure: Authority Information Access CRL Extension". While some issues raised in the working group are unresolved, the editors believe that rough consensus supports the current specification. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt Last Call will run for (at least) two weeks. That is, Last Call will not close before May 24. Thanks, Tim Polk From owner-ietf-pkix@mail.imc.org Tue May 10 21:21:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10706 for ; Tue, 10 May 2005 21:21:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B0ZUKm079131; Tue, 10 May 2005 17:35:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B0ZUsw079130; Tue, 10 May 2005 17:35:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B0ZSBN079123 for ; Tue, 10 May 2005 17:35:29 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Wed, 11 May 2005 10:34:17 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Wed, 11 May 2005 10:34:16 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Wed, 11 May 2005 10:33:58 +1000 From: "Simon McMahon" To: Subject: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4B0ZUBN079124 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, I have had a recent interoperability issue with a application vendor that didn't like the key-usage attributes in a cert from a CA vendor's certificate. Signing certs work fine, it was an encryption cert that failed. CA sets key-usage = "key encipherment". Application wants to encrypt some XML data so looks for key-usage = "data encipherment". Reason - because XML is data, not a key. I believe the application vendor is wrong and I explained that the RSA key actually encrypts an AES key so it doesn't directly encrypt the data but they want an official "pkix" ruling based on the standard so can someone please refer me to a statement in the standard that clears this up. Thanks, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** From owner-ietf-pkix@mail.imc.org Tue May 10 22:43:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15320 for ; Tue, 10 May 2005 22:43:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B1nLxU083627; Tue, 10 May 2005 18:49:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B1nLj9083626; Tue, 10 May 2005 18:49:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B1nHY4083608 for ; Tue, 10 May 2005 18:49:20 -0700 (PDT) (envelope-from andrewsciberras@gmail.com) Received: by zproxy.gmail.com with SMTP id 16so82630nzp for ; Tue, 10 May 2005 18:49:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Z7YVfm2B64NwF/8W5CSoWYYAPmV0Bgtus0x0t8zYxIO9AQDTA8b9zkJ0nRE/TsNkqRckUEJsVS9g0WtZ4KtVqaBSi4KtBvopRAlqY4SJLnO62sHbOp98ZvuDEpycnWpqxPhGvSKTn1p7weUn0EZG6i5N7oSVpduZg6D5KAyVMHw= Received: by 10.36.37.6 with SMTP id k6mr55185nzk; Tue, 10 May 2005 18:49:12 -0700 (PDT) Received: from ?192.168.1.10? ([202.164.196.167]) by mx.gmail.com with ESMTP id 10sm852051nzo.2005.05.10.18.49.10; Tue, 10 May 2005 18:49:12 -0700 (PDT) Message-ID: <42816598.2030001@gmail.com> Date: Wed, 11 May 2005 11:53:28 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon McMahon CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, From RFC2459: > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for enciphering user data, other than cryptographic keys. > Andrew Sciberras eB2Bcom Australia. Simon McMahon wrote: >Hi, > >I have had a recent interoperability issue with a application vendor that didn't like the key-usage attributes in a cert from a CA vendor's certificate. Signing certs work fine, it was an encryption cert that failed. > >CA sets key-usage = "key encipherment". >Application wants to encrypt some XML data so looks for key-usage = "data encipherment". Reason - because XML is data, not a key. > >I believe the application vendor is wrong and I explained that the RSA key actually encrypts an AES key so it doesn't directly encrypt the data but they want an official "pkix" ruling based on the standard so can someone please refer me to a statement in the standard that clears this up. > >Thanks, > >Simon McMahon. > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > > >*********************************************************************************** >This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. > >Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. > >If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. >*********************************************************************************** > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 11 02:22:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23348 for ; Wed, 11 May 2005 02:22:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B5YRQX012359; Tue, 10 May 2005 22:34:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B5YRff012358; Tue, 10 May 2005 22:34:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B5YPX6012340 for ; Tue, 10 May 2005 22:34:25 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 08097344BE; Wed, 11 May 2005 17:34:24 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05922-14; Wed, 11 May 2005 17:34:23 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 6AC40341C8; Wed, 11 May 2005 17:34:23 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 44B0137744; Wed, 11 May 2005 17:34:23 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DVjrY-0006hg-00; Wed, 11 May 2005 17:34:28 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: andrewsciberras@gmail.com, Simon_McMahon@health.qld.gov.au Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <42816598.2030001@gmail.com> Message-Id: Date: Wed, 11 May 2005 17:34:28 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Andrew Sciberras writes: > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for enciphering user data, other than cryptographic keys. Quoting that won't help (I've seen this sort of thing before) because as far as the user is concerned what's being encrypted is data, so the valid bit to use is dataEncipherment (quite logical to them). What might help is to make this more explicit in the text: The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. This bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data. Peter. From owner-ietf-pkix@mail.imc.org Wed May 11 02:22:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23660 for ; Wed, 11 May 2005 02:22:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B5fheW015967; Tue, 10 May 2005 22:41:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B5fhJD015966; Tue, 10 May 2005 22:41:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B5fg6e015950 for ; Tue, 10 May 2005 22:41:42 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 5BCF634DBB; Wed, 11 May 2005 17:41:41 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09358-24; Wed, 11 May 2005 17:41:41 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id DD48D33ED6; Wed, 11 May 2005 17:41:40 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CF24637744; Wed, 11 May 2005 17:41:40 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DVjyc-0006i8-00; Wed, 11 May 2005 17:41:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Simon_McMahon@health.qld.gov.au, wpolk@nist.gov Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <1115780746.4281768a300bf@webmail.nist.gov> Message-Id: Date: Wed, 11 May 2005 17:41:46 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: wpolk@nist.gov writes: >This is a recurring problem with applications. If this is a recurring problem then it's a strong indicator that the wording of the spec needs to be changed to address it. >If your vendor is cooperative, that will make your choice easier. They almost never are. The standard flow for this sort of thing is: 1. Vendor does something silly. 2. Vendor uses ambiguous wording of spec to justify their silliness because they don't want to fix their code. 3. User has the option of breaking their code to match the vendor silliness, or going somewhere else (learning to flip burgers, for example). Peter (who just last week went through an argument with a vendor who claimed that some open-ended wording in the X.509v3 spec (before sundry corrections and bugfixes are applied, and not counting X.509v4 updates or any bugfixes to that) allowed them to do something silly, and they weren't going to change their code, and anyone who didn't like it could bugger off). From owner-ietf-pkix@mail.imc.org Wed May 11 04:38:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13426 for ; Wed, 11 May 2005 04:38:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B7mNqw068050; Wed, 11 May 2005 00:48:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B7mNSb068048; Wed, 11 May 2005 00:48:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B7m6Kn067942 for ; Wed, 11 May 2005 00:48:18 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4B7qkS5008400; Wed, 11 May 2005 15:52:46 +0800 Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4B7tcGG009941; Wed, 11 May 2005 15:55:39 +0800 Message-ID: <019e01c555fd$b35a8cf0$4f85900a@wcwang> From: "Wen-Cheng Wang" To: "Peter Gutmann" , , Cc: References: Subject: Re: key usage - key encipherment or data encipherment Date: Wed, 11 May 2005 15:47:29 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > > Andrew Sciberras writes: > >> The keyEncipherment bit is asserted when the subject public key is >> used for key transport. For example, when an RSA key is to be >> used for key management, then this bit shall asserted. >> >> The dataEncipherment bit is asserted when the subject public key >> is used for enciphering user data, other than cryptographic keys. > > Quoting that won't help (I've seen this sort of thing before) because as far > as the user is concerned what's being encrypted is data, so the valid bit to > use is dataEncipherment (quite logical to them). What might help is to make > this more explicit in the text: > > The dataEncipherment bit is asserted when the subject public key is used for > directly enciphering raw user data without the use of an intermediate > symmetric cipher. This bit MUST NOT be set when the intention is to > encipher intermediate cryptographic keys rather than raw user data. > It is better to clarify that it is legitimate to assert both the keyEncipherment bit and the dataEncipherment bit in one certificate. In that case, it means that the key (e.g., RSA key) may be used for enciphering intermediate cryptographic keys or directly enciphering raw user data (e.g., user password). Wen-Cheng Wang From owner-ietf-pkix@mail.imc.org Wed May 11 06:30:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20241 for ; Wed, 11 May 2005 06:30:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9d1NM006649; Wed, 11 May 2005 02:39:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B9d10g006648; Wed, 11 May 2005 02:39:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9cxbj006635 for ; Wed, 11 May 2005 02:39:00 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id A0EA234A98; Wed, 11 May 2005 21:38:58 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28540-21; Wed, 11 May 2005 21:38:58 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id E96153468C; Wed, 11 May 2005 21:38:57 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 9081337744; Wed, 11 May 2005 21:38:57 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DVngG-0006pf-00; Wed, 11 May 2005 21:39:04 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: andrewsciberras@gmail.com, pgut001@cs.auckland.ac.nz, Simon_McMahon@health.qld.gov.au, wcwang@cht.com.tw Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <019e01c555fd$b35a8cf0$4f85900a@wcwang> Message-Id: Date: Wed, 11 May 2005 21:39:04 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Wen-Cheng Wang" writes: >It is better to clarify that it is legitimate to assert both the >keyEncipherment bit and the dataEncipherment bit in one certificate. In that >case, it means that the key (e.g., RSA key) may be used for enciphering >intermediate cryptographic keys or directly enciphering raw user data (e.g., >user password). Saying you can use both bits won't help, it still leaves it ambiguous to users as to what dataEncipherment should be used for. One interpretation I've heard of is keyEncipherment = exchange of session keys (SSL), dataEncipherment = data encryption (S/MIME). Peter. From owner-ietf-pkix@mail.imc.org Wed May 11 07:19:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23644 for ; Wed, 11 May 2005 07:19:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9S8pR002812; Wed, 11 May 2005 02:28:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B9S8Db002811; Wed, 11 May 2005 02:28:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9S5tV002754 for ; Wed, 11 May 2005 02:28:06 -0700 (PDT) (envelope-from andrewsciberras@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so62335nzn for ; Wed, 11 May 2005 02:28:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Ic6NKFgyvlIzCervQE2SRpcoVJRc+uMzRyCMzJDVnQlqTk/td/3zydNLK3X2QVDt4qKTztNfLULySrtBM4lroijVDLAZDWrw1gnB/Yc0w5s8Tqc7F1xeBJ1lErkeHKcEgELPmhi+jmLJk4yMNgJjcseLCFy/nLewuGt1amIRPeM= Received: by 10.36.146.12 with SMTP id t12mr38413nzd; Wed, 11 May 2005 02:28:00 -0700 (PDT) Received: from ?192.168.1.10? ([202.164.196.167]) by mx.gmail.com with ESMTP id 17sm264287nzo.2005.05.11.02.27.58; Wed, 11 May 2005 02:28:00 -0700 (PDT) Message-ID: <4281D11E.4070009@gmail.com> Date: Wed, 11 May 2005 19:32:14 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: Simon_McMahon@health.qld.gov.au, ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter Gutmann wrote: 
Andrew Sciberras <andrewsciberras@gmail.com> writes:

  
    The keyEncipherment bit is asserted when the subject public key is
     used for key transport.  For example, when an RSA key is to be
     used for key management, then this bit shall asserted.

     The dataEncipherment bit is asserted when the subject public key
     is used for enciphering user data, other than cryptographic keys.
    

Quoting that won't help (I've seen this sort of thing before) because as far
as the user is concerned what's being encrypted is data, so the valid bit to
use is dataEncipherment (quite logical to them).  What might help is to make
this more explicit in the text:

  The dataEncipherment bit is asserted when the subject public key is used for
  directly enciphering raw user data without the use of an intermediate
  symmetric cipher.  This bit MUST NOT be set when the intention is to
  encipher intermediate cryptographic keys rather than raw user data.
Yeah, I see your point Peter.
Simon seems to know what he's talking about and made the point that the key is actually encrypting an AES key, he then wanted a standards based opinion.
I think RFC 2459 clearly states what each of the key usage bits are to be used for.

I don't think that the user's interpretation of what's being encrypted is significant at all. Its more about the developers who are writing decision making code understanding the various usages. At that point the developer should be very aware of how the key associated with the certificate is being used and therefore 2459's description should suffice.


Peter.
Andrew Sciberras.
From owner-ietf-pkix@mail.imc.org Wed May 11 07:28:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24289 for ; Wed, 11 May 2005 07:28:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B35qXM089294; Tue, 10 May 2005 20:05:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B35qTX089293; Tue, 10 May 2005 20:05:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B35ojQ089287 for ; Tue, 10 May 2005 20:05:51 -0700 (PDT) (envelope-from wpolk@nist.gov) Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4B35kD1002813; Tue, 10 May 2005 23:05:46 -0400 Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id j4B35kmX003194; Tue, 10 May 2005 23:05:46 -0400 Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id j4B35kc4003192; Tue, 10 May 2005 23:05:46 -0400 Received: from pool-141-156-36-119.res.east.verizon.net (pool-141-156-36-119.res.east.verizon.net [141.156.36.119]) by webmail.nist.gov (IMP) with HTTP for ; Tue, 10 May 2005 23:05:46 -0400 Message-ID: <1115780746.4281768a300bf@webmail.nist.gov> Date: Tue, 10 May 2005 23:05:46 -0400 From: wpolk@nist.gov To: Simon McMahon Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 141.156.36.119 X-NIST-MailScanner: Found to be clean X-MailScanner-From: wpolk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Simon, Your interpretation matches the PKIX interpretation. Since the RSA key is used to encrypt the AES key, it is key encipherment not data encipherment. The AES key enciphers the data. This is a recurring problem with applications. In general, policies used by most PKIs (including the U.S. government) forbid setting the data encipherment bit. There are a number of security problems taht can arise if an application actuially uses the RSA key to encipher the datat directly. It is almost always a better choice to encrypt data under a good symmetric algorithm and encipher the key using the RSA algorithm. Unfortunatley, a number of applications have been implemnnted using your vendor's interpretations. This presents you with an uncomfortable choice - set data encipherment to enable your apps, but open a security vulnerability, or make the security purist choice and break your app. If your vendor is cooperative, that will make your choice easier. Tim Polk Quoting Simon McMahon : > > Hi, > > I have had a recent interoperability issue with a application vendor that > didn't like the key-usage attributes in a cert from a CA vendor's > certificate. Signing certs work fine, it was an encryption cert that failed. > > CA sets key-usage = "key encipherment". > Application wants to encrypt some XML data so looks for key-usage = "data > encipherment". Reason - because XML is data, not a key. > > I believe the application vendor is wrong and I explained that the RSA key > actually encrypts an AES key so it doesn't directly encrypt the data but they > want an official "pkix" ruling based on the standard so can someone please > refer me to a statement in the standard that clears this up. > > Thanks, > > Simon McMahon. > > > > Simon McMahon > > Work: (07) 31311420 > Mobile: (043) 2294180 > > > > Simon McMahon > > Work: (07) 31311420 > Mobile: (043) 2294180 > > > > > ******************************************************************************* **** > This email, including any attachments sent with it, is confidential and for > the sole use of the intended recipient(s). This confidentiality is not > waived or lost, if you receive it and you are not the intended recipient(s), > or if it is transmitted/received in error. > > Any unauthorised use, alteration, disclosure, distribution or review of this > email is prohibited. It may be subject to a statutory duty of > confidentiality if it relates to health service matters. > > If you are not the intended recipient(s), or if you have received this email > in error, you are asked to immediately notify the sender by telephone or by > return email. You should also delete this email and destroy any hard copies > produced. > ******************************************************************************* **** > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 11 07:42:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25031 for ; Wed, 11 May 2005 07:42:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BAmoDP032162; Wed, 11 May 2005 03:48:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BAmoL8032161; Wed, 11 May 2005 03:48:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BAmndO032124 for ; Wed, 11 May 2005 03:48:49 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com) Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id 35DF45FF4E; Wed, 11 May 2005 05:48:15 -0500 (CDT) Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id ; Wed, 11 May 2005 05:48:14 -0500 Message-ID: <5.1.0.14.0.20050511064836.00adf900@172.16.146.192> From: "Kazin, Joel" To: pgut001@cs.auckland.ac.nz, andrewsciberras@gmail.com, Simon_McMahon@health.qld.gov.au Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Date: Wed, 11 May 2005 05:49:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55616.EE7E8D2C" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55616.EE7E8D2C Content-Type: text/plain; charset="iso-8859-1" Peters rewording makes it clearer. At 12:34 AM 5/11/2005 -0500, pgut001@cs.auckland.ac.nz wrote: Andrew Sciberras writes: > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for enciphering user data, other than cryptographic keys. Quoting that won't help (I've seen this sort of thing before) because as far as the user is concerned what's being encrypted is data, so the valid bit to use is dataEncipherment (quite logical to them). What might help is to make this more explicit in the text: The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. This bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data. Peter. Joel S. Kazin CPA, CISA, CISSP, CISM Senior Consultant Atos Origin 40 Old Sleepy Hollow Road Pleasantville, New York 10570-3802 USA Phone +1 914-769-8780 Mobile +1 914-564-1484 email joel.kazin@atosorigin.com www.atosorigin.com ------_=_NextPart_001_01C55616.EE7E8D2C Content-Type: text/html; charset="iso-8859-1" Peters rewording makes it clearer.

At 12:34 AM 5/11/2005 -0500, pgut001@cs.auckland.ac.nz wrote:

Andrew Sciberras <andrewsciberras@gmail.com> writes:

>     The keyEncipherment bit is asserted when the subject public key is
>      used for key transport.  For example, when an RSA key is to be
>      used for key management, then this bit shall asserted.
>
>      The dataEncipherment bit is asserted when the subject public key
>      is used for enciphering user data, other than cryptographic keys.

Quoting that won't help (I've seen this sort of thing before) because as far
as the user is concerned what's being encrypted is data, so the valid bit to
use is dataEncipherment (quite logical to them).  What might help is to make
this more explicit in the text:

  The dataEncipherment bit is asserted when the subject public key is used for
  directly enciphering raw user data without the use of an intermediate
  symmetric cipher.  This bit MUST NOT be set when the intention is to
  encipher intermediate cryptographic keys rather than raw user data.

Peter.


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    joel.kazin@atosorigin.com
www.atosorigin.com
 ------_=_NextPart_001_01C55616.EE7E8D2C-- From owner-ietf-pkix@mail.imc.org Wed May 11 12:37:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22296 for ; Wed, 11 May 2005 12:37:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BFNfIe004688; Wed, 11 May 2005 08:23:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BFNff6004687; Wed, 11 May 2005 08:23:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4BFNego004675 for ; Wed, 11 May 2005 08:23:40 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 26369 invoked by uid 0); 11 May 2005 15:21:29 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.135.101) by woodstock.binhost.com with SMTP; 11 May 2005 15:21:29 -0000 Message-Id: <6.2.1.2.2.20050511110252.04b9c300@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 11:06:39 -0400 To: "Simon McMahon" From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon: If they are encrypting the XML data directly with the RSA key (which is very unlikely), then they are correct. The traditional way to handle this is to generate a random content-encryption key (CEK) and then encrypt the XML data with a symmetric algorithm using the CEK. The CEK is encrypted with the RSA key from the certificate. Thus, the RSA key is really being used to encrypt only symmetric keys. Russ At 08:33 PM 5/10/2005, Simon McMahon wrote: >Hi, > >I have had a recent interoperability issue with a application vendor that >didn't like the key-usage attributes in a cert from a CA vendor's >certificate. Signing certs work fine, it was an encryption cert that failed. > >CA sets key-usage = "key encipherment". >Application wants to encrypt some XML data so looks for key-usage = "data >encipherment". Reason - because XML is data, not a key. > >I believe the application vendor is wrong and I explained that the RSA key >actually encrypts an AES key so it doesn't directly encrypt the data but >they want an official "pkix" ruling based on the standard so can someone >please refer me to a statement in the standard that clears this up. > >Thanks, > >Simon McMahon. > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > > >*********************************************************************************** >This email, including any attachments sent with it, is confidential and >for the sole use of the intended recipient(s). This confidentiality is >not waived or lost, if you receive it and you are not the intended >recipient(s), or if it is transmitted/received in error. > >Any unauthorised use, alteration, disclosure, distribution or review of >this email is prohibited. It may be subject to a statutory duty of >confidentiality if it relates to health service matters. > >If you are not the intended recipient(s), or if you have received this >email in error, you are asked to immediately notify the sender by >telephone or by return email. You should also delete this email and >destroy any hard copies produced. >*********************************************************************************** From owner-ietf-pkix@mail.imc.org Wed May 11 12:42:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22585 for ; Wed, 11 May 2005 12:42:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BFgPTQ006619; Wed, 11 May 2005 08:42:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BFgPen006618; Wed, 11 May 2005 08:42:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4BFgOMW006612 for ; Wed, 11 May 2005 08:42:25 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 27169 invoked by uid 0); 11 May 2005 15:40:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.135.101) by woodstock.binhost.com with SMTP; 11 May 2005 15:40:15 -0000 Message-Id: <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 11:40:16 -0400 To: "Wen-Cheng Wang" From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: In-Reply-To: <019e01c555fd$b35a8cf0$4f85900a@wcwang> References: <019e01c555fd$b35a8cf0$4f85900a@wcwang> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe that RFC 3280 is quite clear that more than one of these bits can be set. It says: This profile does not restrict the combinations of bits that may be set in an instantiation of the keyUsage extension. However, appropriate values for keyUsage extensions for particular algorithms are specified in [PKIXALGS]. Russ At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: >Peter Gutmann wrote: >>Andrew Sciberras writes: >> >>> The keyEncipherment bit is asserted when the subject public key is >>> used for key transport. For example, when an RSA key is to be >>> used for key management, then this bit shall asserted. >>> >>> The dataEncipherment bit is asserted when the subject public key >>> is used for enciphering user data, other than cryptographic keys. >>Quoting that won't help (I've seen this sort of thing before) because as far >>as the user is concerned what's being encrypted is data, so the valid bit to >>use is dataEncipherment (quite logical to them). What might help is to make >>this more explicit in the text: >> The dataEncipherment bit is asserted when the subject public key is >> used for >> directly enciphering raw user data without the use of an intermediate >> symmetric cipher. This bit MUST NOT be set when the intention is to >> encipher intermediate cryptographic keys rather than raw user data. >It is better to clarify that it is legitimate to assert both the >keyEncipherment bit >and the dataEncipherment bit in one certificate. In that case, it means >that the >key (e.g., RSA key) may be used for enciphering intermediate cryptographic >keys or directly enciphering raw user data (e.g., user password). > >Wen-Cheng Wang > > From owner-ietf-pkix@mail.imc.org Wed May 11 14:14:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29239 for ; Wed, 11 May 2005 14:14:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BHKpp7015544; Wed, 11 May 2005 10:20:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BHKpII015543; Wed, 11 May 2005 10:20:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from [200.53.113.210] (mail.seguridata.com [200.53.113.210]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4BHKnXR015537 for ; Wed, 11 May 2005 10:20:50 -0700 (PDT) (envelope-from mars@seguridata.com) Received: from no.name.available by [200.53.113.210] via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Wed, 11 May 2005 13:19:03 -0500 Received: from miguel2 ([192.168.0.214]) by mail.seguridata.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 12:23:50 -0500 From: "Miguel A Rodriguez" To: Subject: RE: key usage - key encipherment or data encipherment Date: Wed, 11 May 2005 12:20:46 -0500 Message-ID: <000d01c5564d$c4a93060$d600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 11 May 2005 17:23:50.0119 (UTC) FILETIME=[324BBF70:01C5564E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4BHKoXR015538 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Does anyone use dataEncipherment? Miguel A Rodríguez SeguriData Mexico At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: >Peter Gutmann wrote: >>Andrew Sciberras writes: >> >>> The keyEncipherment bit is asserted when the subject public key is >>> used for key transport. For example, when an RSA key is to be >>> used for key management, then this bit shall asserted. >>> >>> The dataEncipherment bit is asserted when the subject public key >>> is used for enciphering user data, other than cryptographic >>> keys. >>Quoting that won't help (I've seen this sort of thing before) because >>as far as the user is concerned what's being encrypted is data, so the >>valid bit to use is dataEncipherment (quite logical to them). What >>might help is to make this more explicit in the text: >> The dataEncipherment bit is asserted when the subject public key is >> used for >> directly enciphering raw user data without the use of an intermediate >> symmetric cipher. This bit MUST NOT be set when the intention is to >> encipher intermediate cryptographic keys rather than raw user data. >It is better to clarify that it is legitimate to assert both the >keyEncipherment bit >and the dataEncipherment bit in one certificate. In that case, it means >that the >key (e.g., RSA key) may be used for enciphering intermediate cryptographic >keys or directly enciphering raw user data (e.g., user password). > >Wen-Cheng Wang > > From owner-ietf-pkix@mail.imc.org Wed May 11 14:54:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08106 for ; Wed, 11 May 2005 14:54:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BI2Evj019550; Wed, 11 May 2005 11:02:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BI2E6M019549; Wed, 11 May 2005 11:02:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BI2D9s019542 for ; Wed, 11 May 2005 11:02:13 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4BI1jD3004887 for ; Wed, 11 May 2005 14:01:45 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4BI1K9r010680 for ; Wed, 11 May 2005 14:01:20 -0400 (EDT) Message-Id: <5.1.0.14.2.20050511135058.034e5c80@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 May 2005 14:02:30 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: Evaluating Rough Consensus for 3770bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: After reviewing the traffic on the list, it appears to me that rough consensus has been achieved with the release of the latest draft of 3770bis, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)". I intend to forward the document to Sam Hartman this Friday (May 13) for progression unless I hear an outcry on the list. The current draft is available at http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-02.txt Thanks, Tim Polk From owner-ietf-pkix@mail.imc.org Wed May 11 16:59:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25581 for ; Wed, 11 May 2005 16:59:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BJx2Ce028403; Wed, 11 May 2005 12:59:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BJx2He028402; Wed, 11 May 2005 12:59:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4BJx0kU028395 for ; Wed, 11 May 2005 12:59:01 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18403 invoked by uid 0); 11 May 2005 19:57:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.94.125) by woodstock.binhost.com with SMTP; 11 May 2005 19:57:15 -0000 Message-Id: <6.2.1.2.2.20050511154032.05801770@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 15:57:12 -0400 To: "Miguel A Rodriguez" From: Russ Housley Subject: RE: key usage - key encipherment or data encipherment Cc: ietf-pkix@imc.org In-Reply-To: <000d01c5564d$c4a93060$d600a8c0@seguridata.com> References: <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com> <000d01c5564d$c4a93060$d600a8c0@seguridata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit As far as I know, SET was the only protocol that used data encipherment. Of course, SET used the same RSA public key for both data encipherment and key encipherment. Russ At 01:20 PM 5/11/2005, Miguel A Rodriguez wrote: >Does anyone use dataEncipherment? > >Miguel A Rodríguez >SeguriData >Mexico > >At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: > > > >Peter Gutmann wrote: > >>Andrew Sciberras writes: > >> > >>> The keyEncipherment bit is asserted when the subject public key >is > >>> used for key transport. For example, when an RSA key is to be > >>> used for key management, then this bit shall asserted. > >>> > >>> The dataEncipherment bit is asserted when the subject public >key > >>> is used for enciphering user data, other than cryptographic > >>> keys. > >>Quoting that won't help (I've seen this sort of thing before) because > >>as far as the user is concerned what's being encrypted is data, so the > > >>valid bit to use is dataEncipherment (quite logical to them). What > >>might help is to make this more explicit in the text: > >> The dataEncipherment bit is asserted when the subject public key is > >> used for > >> directly enciphering raw user data without the use of an >intermediate > >> symmetric cipher. This bit MUST NOT be set when the intention is to > >> encipher intermediate cryptographic keys rather than raw user data. > >It is better to clarify that it is legitimate to assert both the > >keyEncipherment bit > >and the dataEncipherment bit in one certificate. In that case, it means > > >that the > >key (e.g., RSA key) may be used for enciphering intermediate >cryptographic > >keys or directly enciphering raw user data (e.g., user password). > > > >Wen-Cheng Wang > > > > From owner-ietf-pkix@mail.imc.org Wed May 11 23:03:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23635 for ; Wed, 11 May 2005 23:03:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C2GEsg058827; Wed, 11 May 2005 19:16:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C2GErC058826; Wed, 11 May 2005 19:16:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C2GCEf058812 for ; Wed, 11 May 2005 19:16:13 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Thu, 12 May 2005 12:14:49 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Thu, 12 May 2005 12:14:49 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Thu, 12 May 2005 12:14:40 +1000 From: "Simon McMahon" To: Cc: Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C2GEEf058820 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Russ, They were calling an 'encrypt' function to encrypt XML data and they gave it an RSA key (the cert actually) to do it. Of course it internally made an AES key but they never saw it until the interoperability issue made them look. From what they saw at the level they were looking the interpretation was reasonable. When the transport key is well hidden and simply part of the protocol then it looks just like RSA is encrypting big slabs of data. If you know that RSA is bound by the modulus size then you know what is really happening but not all users of PKI know RSA so well. Why should they? Couple this interpretation of key-usage with a dubious decision to reject encryption requests with certs that dont have key-usage='data encipherment' and you have an interoperability problem. I say "dubious" because it is a public key so you cannot enforce usage policy anyway. The CA could set both flags to fix it, which by the way was the vendors preferred solution, but its not my CA or their CA and the CA doesn't do that. Why should they? This reference, in my opinion, allows the ambiguous interpretation: > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for enciphering user data, other than cryptographic keys. In this case the public key is clearly "intended" to be used to encrypt the XML data but it just doesn't do it directly because it cant. The term "key management" also has associations with more basic and explicit key management operations like installing trusted root certs or secure installation of shared secret keys etc. In this case it is much less obvious that key management is happening because the key is bundled with the data. It looks just like the public key is encrypting the data. In my opinion there are 3 cases presented as 2 in the RFC. 1. RSA encrypts data - hardly ever used. 2. RSA implicitly encrypts keys so it can really encrypt bulk data - common usage. 3. RSA explicitly encrypts keys for explicit key management functions - common usage. The current bits separate 1 from 2/3 yet people make the interpretation that they split the more common 2 from 3 assuming 1 and 2 are the same thing. Knowledge of RSA is required to know that 1 and 2 are different. Peter's comment "This bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data" is most relevant in my case. Does PKIX support this clarification? In my opinion this problem will not entirely go away by clarifying the standard because most people dont read it before they implement something. The two bits are there and as long as they are both there then the mistake will be made by busy developers. Unenforceable key-usage policy, to "public" keys, will also continue to be implemented. People will come looking for clarification once they have an interoperability issue but by then it is often too late - the issue usually gets decided by who has the biggest corporate balls. In this case it wasn't too late so thanks for the assistance. If I could recommend a change to the standard then I would suggest dropping one of the encryption bits and just have a single key-usage = "encryption". Give it the value the same as "key-encryption" since this is the common usage. Thanks, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Russ Housley 05/12/05 01:06am >>> Simon: If they are encrypting the XML data directly with the RSA key (which is very unlikely), then they are correct. The traditional way to handle this is to generate a random content-encryption key (CEK) and then encrypt the XML data with a symmetric algorithm using the CEK. The CEK is encrypted with the RSA key from the certificate. Thus, the RSA key is really being used to encrypt only symmetric keys. Russ At 08:33 PM 5/10/2005, Simon McMahon wrote: >Hi, > >I have had a recent interoperability issue with a application vendor that >didn't like the key-usage attributes in a cert from a CA vendor's >certificate. Signing certs work fine, it was an encryption cert that failed. > >CA sets key-usage = "key encipherment". >Application wants to encrypt some XML data so looks for key-usage = "data >encipherment". Reason - because XML is data, not a key. > >I believe the application vendor is wrong and I explained that the RSA key >actually encrypts an AES key so it doesn't directly encrypt the data but >they want an official "pkix" ruling based on the standard so can someone >please refer me to a statement in the standard that clears this up. > >Thanks, > >Simon McMahon. > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > > >*********************************************************************************** >This email, including any attachments sent with it, is confidential and >for the sole use of the intended recipient(s). This confidentiality is >not waived or lost, if you receive it and you are not the intended >recipient(s), or if it is transmitted/received in error. > >Any unauthorised use, alteration, disclosure, distribution or review of >this email is prohibited. It may be subject to a statutory duty of >confidentiality if it relates to health service matters. > >If you are not the intended recipient(s), or if you have received this >email in error, you are asked to immediately notify the sender by >telephone or by return email. You should also delete this email and >destroy any hard copies produced. >*********************************************************************************** *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** From owner-ietf-pkix@mail.imc.org Thu May 12 01:46:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04023 for ; Thu, 12 May 2005 01:46:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C4usv9079787; Wed, 11 May 2005 21:56:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C4ush2079785; Wed, 11 May 2005 21:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C4uo3Q079768 for ; Wed, 11 May 2005 21:56:53 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4C4ulEE030977; Thu, 12 May 2005 12:56:47 +0800 Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4C4ugj8014047; Thu, 12 May 2005 12:56:45 +0800 Message-ID: <011901c556ae$ffda6c10$4f85900a@wcwang> From: "Wen-Cheng Wang" To: "Miguel A Rodriguez" , "Russ Housley" Cc: References: <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com><000d01c5564d$c4a93060$d600a8c0@seguridata.com> <6.2.1.2.2.20050511154032.05801770@mail.binhost.com> Subject: Re: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 12:56:42 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit FYI: In the Asia PKI Interoperability Guideline (prepared by Asia PKI Forum), we suggest CA vendors or operators to assert both the keyEncipherment and dataEncipherment bits in an encryption cert. The main reason is that we intend to allow users to use the public key for directly enciphering raw user data. We certainly know that the public key is usually used to encrypt intermediate cryptographic keys. However, what if someday users really want to use that public key for directly enciphering raw user data (e.g., user password)? For the sake of supporting both kinds of encipherment, it is better to assert both bits in the beginning. I see no reason why a public key certified by an "encryption" certificate should be prohibit from being used for directly enciphering small-size user data. The second reason is that we believe that asserting both bits is helpful to achieve maximum Interoperability. By asserting both bits, no matter which interpretation the application implementators adopt, the cert should always work. Anyway, I believe that it is not harmful if the dataEncipherment bit is asserted in an encryption cert in addition to the keyEncipherment bit. Wen-Cheng Wang ----- Original Message ----- From: "Russ Housley" To: "Miguel A Rodriguez" Cc: Sent: Thursday, May 12, 2005 3:57 AM Subject: RE: key usage - key encipherment or data encipherment > > As far as I know, SET was the only protocol that used data encipherment. Of course, SET used the > same RSA public key for both data encipherment and key encipherment. > > Russ > > At 01:20 PM 5/11/2005, Miguel A Rodriguez wrote: > >>Does anyone use dataEncipherment? >> >>Miguel A Rodríguez >>SeguriData >>Mexico >> >>At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: >> >> >> >Peter Gutmann wrote: >> >>Andrew Sciberras writes: >> >> >> >>> The keyEncipherment bit is asserted when the subject public key >>is >> >>> used for key transport. For example, when an RSA key is to be >> >>> used for key management, then this bit shall asserted. >> >>> >> >>> The dataEncipherment bit is asserted when the subject public >>key >> >>> is used for enciphering user data, other than cryptographic >> >>> keys. >> >>Quoting that won't help (I've seen this sort of thing before) because >> >>as far as the user is concerned what's being encrypted is data, so the >> >> >>valid bit to use is dataEncipherment (quite logical to them). What >> >>might help is to make this more explicit in the text: >> >> The dataEncipherment bit is asserted when the subject public key is >> >> used for >> >> directly enciphering raw user data without the use of an >>intermediate >> >> symmetric cipher. This bit MUST NOT be set when the intention is to >> >> encipher intermediate cryptographic keys rather than raw user data. >> >It is better to clarify that it is legitimate to assert both the >> >keyEncipherment bit >> >and the dataEncipherment bit in one certificate. In that case, it means >> >> >that the >> >key (e.g., RSA key) may be used for enciphering intermediate >>cryptographic >> >keys or directly enciphering raw user data (e.g., user password). >> > >> >Wen-Cheng Wang >> > >> > > From owner-ietf-pkix@mail.imc.org Thu May 12 01:54:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04418 for ; Thu, 12 May 2005 01:54:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C5AZiS084744; Wed, 11 May 2005 22:10:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C5AZt3084743; Wed, 11 May 2005 22:10:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C5AXml084687 for ; Wed, 11 May 2005 22:10:34 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4C5AJWM032266; Thu, 12 May 2005 13:10:19 +0800 Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4C5AJX5015110; Thu, 12 May 2005 13:10:19 +0800 Message-ID: <013201c556b0$e4469170$4f85900a@wcwang> From: "Wen-Cheng Wang" To: "Russ Housley" Cc: References: <019e01c555fd$b35a8cf0$4f85900a@wcwang> <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com> Subject: Re: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 13:10:18 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, Yes, RFC 3280 is quite clear for that. However, I worried that the discussions of this thread might mislead the participants into believing that the two bits are mutually exclusive. Therefore, I simply want to remind the participants of this thread the fact that the keyEncipherment bit and dataEncipherment bit can work well togethor. Wen-Cheng Wang ----- Original Message ----- From: "Russ Housley" To: "Wen-Cheng Wang" Cc: Sent: Wednesday, May 11, 2005 11:40 PM Subject: Re: key usage - key encipherment or data encipherment >I believe that RFC 3280 is quite clear that more than one of these bits can > be set. It says: > > This profile does not restrict the combinations of bits that may be > set in an instantiation of the keyUsage extension. However, > appropriate values for keyUsage extensions for particular algorithms > are specified in [PKIXALGS]. > > Russ > > At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: > > >>Peter Gutmann wrote: >>>Andrew Sciberras writes: >>> >>>> The keyEncipherment bit is asserted when the subject public key is >>>> used for key transport. For example, when an RSA key is to be >>>> used for key management, then this bit shall asserted. >>>> >>>> The dataEncipherment bit is asserted when the subject public key >>>> is used for enciphering user data, other than cryptographic keys. >>>Quoting that won't help (I've seen this sort of thing before) because as far >>>as the user is concerned what's being encrypted is data, so the valid bit to >>>use is dataEncipherment (quite logical to them). What might help is to make >>>this more explicit in the text: >>> The dataEncipherment bit is asserted when the subject public key is >>> used for >>> directly enciphering raw user data without the use of an intermediate >>> symmetric cipher. This bit MUST NOT be set when the intention is to >>> encipher intermediate cryptographic keys rather than raw user data. >>It is better to clarify that it is legitimate to assert both the >>keyEncipherment bit >>and the dataEncipherment bit in one certificate. In that case, it means >>that the >>key (e.g., RSA key) may be used for enciphering intermediate cryptographic >>keys or directly enciphering raw user data (e.g., user password). >> >>Wen-Cheng Wang >> >> > From owner-ietf-pkix@mail.imc.org Thu May 12 02:16:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21157 for ; Thu, 12 May 2005 02:16:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C5XlVc098236; Wed, 11 May 2005 22:33:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C5XlSU098235; Wed, 11 May 2005 22:33:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C5XivN098178 for ; Wed, 11 May 2005 22:33:45 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4C5XHgw002099; Thu, 12 May 2005 13:33:17 +0800 Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4C5XAcp030585; Thu, 12 May 2005 13:33:11 +0800 Message-ID: <01a701c556b4$1987f650$4f85900a@wcwang> From: "Wen-Cheng Wang" To: "Peter Gutmann" , , Cc: References: Subject: Re: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 13:33:10 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, I think your clarification about the distinction between the keyEncipherment bit and the dataEncipherment bit is good. It would be better if RFC 3280 and X.509 could revise the explanation of the dataEncipherment bit based on your clarification. However, I worried that the statement "This (dataEncipherment) bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data" might mislead the reader to believe that the keyEncipherment bit and the dataEncipherment bit are mutually exclusive. Therefore, I suggest to revise the statement as "The dataEncipherment bit should not be use to represent the intention of allowing enciphering intermediate cryptographic keys. In that case, the keyEncipherment bit should be set." Wen-Cheng Wang ----- Original Message ----- From: "Peter Gutmann" To: ; ; ; Cc: Sent: Wednesday, May 11, 2005 5:39 PM Subject: Re: key usage - key encipherment or data encipherment > > "Wen-Cheng Wang" writes: > >>It is better to clarify that it is legitimate to assert both the >>keyEncipherment bit and the dataEncipherment bit in one certificate. In that >>case, it means that the key (e.g., RSA key) may be used for enciphering >>intermediate cryptographic keys or directly enciphering raw user data (e.g., >>user password). > > Saying you can use both bits won't help, it still leaves it ambiguous to users > as to what dataEncipherment should be used for. One interpretation I've heard > of is keyEncipherment = exchange of session keys (SSL), dataEncipherment = > data encryption (S/MIME). > > Peter. > From owner-ietf-pkix@mail.imc.org Thu May 12 05:51:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10146 for ; Thu, 12 May 2005 05:51:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C8tLCB084393; Thu, 12 May 2005 01:55:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C8tLeP084392; Thu, 12 May 2005 01:55:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth04.mail.atl.earthlink.net (smtpauth04.mail.atl.earthlink.net [209.86.89.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C8tK5J084383 for ; Thu, 12 May 2005 01:55:20 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.3]) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DW9TU-0005Td-0m; Thu, 12 May 2005 04:55:20 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:Date:To:From:Subject:Content-Type; b=UKfSvuhS7GB/BmzmmtG0G6YGXwXHboxCRsvY77eKuO7b0ZdGAKsYYZIVV2wuws7K; Mime-Version: 1.0 Message-Id: Date: Thu, 12 May 2005 01:51:24 -0700 To: "X.509":; From: Hoyt L Kesterson II Subject: Technical Corrigenda 3 to the 4th edition of X.509 Content-Type: text/html; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47874241ab66785ff6d62eb916411cfa52e56294888860517e9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Technical Corrigenda 3 to the 4th edition of X.509

Some you worked with the X.509 standards committee over the last few years revising the text on key usage.

The Technical Corrigenda containing that revised text was approved and is currently being incorporated into the 5th edition currently being prepared.

You can find the text of that Technical Corrigenda at:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf

Note that this document is written as a set of editing instructions to integrate the text into the 4th edition. If you prefer to wait, the 5th edition will be published before the end of the year

   hoyt
From owner-ietf-pkix@mail.imc.org Thu May 12 05:57:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10415 for ; Thu, 12 May 2005 05:57:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C8tKVd084380; Thu, 12 May 2005 01:55:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C8tKYq084379; Thu, 12 May 2005 01:55:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth04.mail.atl.earthlink.net (smtpauth04.mail.atl.earthlink.net [209.86.89.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C8tJci084369 for ; Thu, 12 May 2005 01:55:19 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.3]) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DW9TS-0005Td-F2; Thu, 12 May 2005 04:55:18 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:Date:To:From:Subject:Content-Type; b=QtwUZIeb55fvwiKyIdax+s9va2hbpoFGh3LQ0B8rDuGUo/kE9yMvRmuJTS+3yoIq; Mime-Version: 1.0 Message-Id: Date: Thu, 12 May 2005 01:54:12 -0700 To: "X.509":; From: Hoyt L Kesterson II Subject: the certificate enhancement DAM Content-Type: text/html; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47874241ab66785ff6d4117eb27ee25f1d6629cc9cca95413eb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: the certificate enhancement DAM
The directory group has completed work on a new amendment to the standard. That amendment is currently being integrated, along with approved TCs, into the 5th edition of the standard. That edition will be published before the end of the year.

The amendment can be found at

  ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf

        hoyt
From owner-ietf-pkix@mail.imc.org Thu May 12 06:02:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10802 for ; Thu, 12 May 2005 06:02:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9NDlB095459; Thu, 12 May 2005 02:23:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9NDdO095458; Thu, 12 May 2005 02:23:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9NBhk095409 for ; Thu, 12 May 2005 02:23:11 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA36536; Thu, 12 May 2005 11:37:59 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051211230124:968 ; Thu, 12 May 2005 11:23:01 +0200 Message-ID: <428320AE.5080809@bull.net> Date: Thu, 12 May 2005 11:23:58 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: David Cross CC: pkix Subject: Re: Comments on References: <3C69AE30038D9A4590F5EC20DCD41F680665BB8F@RED-MSG-41.redmond.corp.microsoft.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:23:01, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:23:02, Serialize complete at 12/05/2005 11:23:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David, Since Tim has now made the call at the WG level, please consider this message as an answer to the call. > Denis: > I have to disagree on removal of the text. I have not seen any > objections from the list or working group to this inclusion. I have to > disagree with your assertion that removing the text is a more secure > recommendation. The below text (slightly edited to my taste) is an > excellent recommendation from an implementation standoint and a security > consideration. You are using the wording "excellent" but as it will be demonstrated this is far from excellent. > I would personally concede that using MUST *may* be > incorrect here and a SHOULD *may* be more appropriate. Fine. > As a means of mitigating implementation challenges and security > issues related to issuer name collisions, CA names SHOULD be > formed in such a way that reduce the likelihood of name collisions. The word "mitigating" is used: it already indicates that it is not a secure solution. While this recommendation is wise, nothing forces CA to follow it. So the question is : what would happen if a CA name is formed in such a way that there is a name collision ? Relying parties cannot base their security on this "SHOULD requirement". So this does not suppress the issue: this should clearly be said that this is not a solution. > Implementations validating CRLs SHOULD ensure that the certification > path of the target certificate and the CRL issuer certification path > used to validate the target certificate, terminate at a common trust > anchor. This does not solve the issue either. Under the same trust anchor there may be a tree with many branches and leaves, nothing prevents two CRL Issuers to have the same name. For this reason the proposed text is inappropriate. Denis > David B. Cross > > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: Tuesday, May 10, 2005 12:01 AM > To: Russ Housley > Cc: ietf-pkix@imc.org > Subject: Re: Comments on > > > Russ, > > >>Denis: >> >>Yes, it is OBVIOUS that the CRL issuer certificate needs to be > > validated. > >>You say that it is not clear what validation policy needs to be used, >>but this is completely irrelevant to the discussion of the CRL AIA >>extension. This extension aid in certification path construction, not > > >>the validation of the path once it is constructed. > > > Not exactly, it could "help" finding a wrong path ! > > >>There are many factors which need to be considered in the validation >>of the CRL issue certificate. The values of the key usage extension >>and the certificate policies extension are two that jump to mind. >>There are probably more if I spend the time to consider each possible > > scenario. > > One simple rule would allow no security problem at all and I wonder why > you have so much resistance to mention it. > > >>In my opinion, this document is ready for WG Last Call. > > > As an editor of the draft, I may understand your position; but it is up > the the PKIX chairs to decide whether or not the document is ready for > WG last call. > > Once again the current Security Considerations section is not > acceptable. > In particular it contains a "MUST" statement that cannot be placed in > such a section and which is in addition fully wrong. > > Hereabove is the last one from draft 01: > > 3 Security Considerations > > Implementers should take into account the possible existence of > multiple unrelated CAs and CRL issuers with the same name. As > means of reducing problems and security issues related to issuer > name collisions, CA names SHOULD be formed in a way that reduce > the > likelihood of name collisions. Implementations validating CRLs > MUST ensure that the certification path of the target certificate > and the CRL issuer certification path used to validate the target > certificate, terminate at the same trust anchor. > > Implementers should be aware of risks involved if the Authority > Information Access extensions of corrupted CRLs contain links to > malicious code. Implementers should always take the steps of > validating the retrieved data to ensure that the data is properly > formed. > > Hereafter is a "minimalist" rewriting of this section, if we take the > choice to mention the issue, but not to provide any secure solution > (mentioning insecure or insufficient solutions is not appropriate). Two > sentences have thus been deleted. > > 3 Security Considerations > > Implementers should take into account the possible existence of > multiple unrelated CAs and CRL issuers with the same name. > > Implementers should be aware of risks involved if the Authority > Information Access extensions of corrupted CRLs contain links to > malicious code. Implementers should always take the steps of > validating the retrieved data to ensure that the data is properly > formed. > > Denis > > > >>Russ >> >> >>At 09:07 AM 5/9/2005, Denis Pinkas wrote: >> >> >>>Russ, >>> >>> >>>>Here is a quote from RFC 3280. To me, it is clear that a CRL >>>>issuer >>> >>>has >>> >>>>a certificate. >>> >>>True, a CRL issuer (that is different from the CA that has issued the >> > >>>target >>>certificate) has a certificate. So we both strongly agree on this >>>this. :-) >>> >>> >>>>Obviously, all certificates need to be validated, which includes >>>>certification path construction and certification path >>> >>>validation. >>> >>>When a sentence starts with "Obviously", it means that it is not so >>>obvious. >>>:-| >>> >>>The real question is whether the CRL issuer certificate has to be >>>verified using rules (i.e. a validation policy) which are independent >> > >>>from the certification path construction of the target certificate. >>>RFC 3280 does not provide a crystal clear answer to that question. >>> >>>If the rules are different, then you MAY end up with a security issue >> > >>>(see my previous explanations). The current "recommendations" that >>>are in the security considerations section do NOT solve this issue in >> > >>>the general case. >>> >>>If the rules are the same, i.e. the path used to validate the >>>certification path from the certificate are also used, then there is >>>no security issue. >>> >>>I do not think it would be good to hide this issue in the proposed >> > draft. > >>>Anyway, the current "recommendations" do NOT solve the issue and are >>>thus not acceptable and so this section cannot stand as it is. >>> >>>Denis >>> >>> >>>>5.1.1.3 signatureValue >>>> >>>> The signatureValue field contains a digital signature computed >>> > upon > >>>> the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded >>> >>>tbsCertList >>> >>>> is used as the input to the signature function. This signature >>> >>>value >>> >>>> is encoded as a BIT STRING and included in the CRL >>> > signatureValue > >>>> field. The details of this process are specified for each of >>> > the > >>>> supported algorithms in [PKIXALGS]. >>>> >>>> CAs that are also CRL issuers MAY use one private key to >>> > digitally > >>>> sign certificates and CRLs, or MAY use separate private keys to >>>> digitally sign certificates and CRLs. When separate private >>>>keys >>> >>>are >>> >>>> employed, each of the public keys associated with these private >>> > keys > >>>> is placed in a separate certificate, one with the keyCertSign >>>>bit >>> >>>set >>> >>>> in the key usage extension, and one with the cRLSign bit set in >>> > the > >>>> key usage extension (section 4.2.1.3). When separate private >>> > keys > >>>> are employed, certificates issued by the CA contain one >>>>authority >>> >>>key >>> >>>> identifier, and the corresponding CRLs contain a different >>> > authority > >>>> key identifier. The use of separate CA certificates for >>> > validation > >>>> of certificate signatures and CRL signatures can offer improved >>>> security characteristics; however, it imposes a burden on >>>> applications, and it might limit interoperability. Many >>> >>>applications >>> >>>> construct a certification path, and then validate the >>> > certification > >>>> path (section 6). CRL checking in turn requires a separate >>>> certification path to be constructed and validated for the CA's >>> > CRL > >>>> signature validation certificate. Applications that perform CRL >>>> checking MUST support certification path validation when >>> >>>certificates >>> >>>> and CRLs are digitally signed with the same CA private key. >>> > These > >>>> applications SHOULD support certification path validation when >>>> certificates and CRLs are digitally signed with different CA >>> > private > >>>> keys. >>>> >>>>Russ >>>> >>>>At 01:12 PM 4/28/2005, Denis Pinkas wrote: >>>> >>>> >>>>>Stefan and Russ, >>>>> >>>>> >>>>>>Denis, >>>>> >>>>> >>>>>>Russ and I have taken a thorough look at your text proposal and >>>>>>we >>>>> >>>have >>> >>>>>>edited a counter proposal where we try to meet your needs as much >>>>> > >>>>>>as possible without compromising what we think is the core >>>>>>purpose of >>>>> >>>the >>> >>>>>>draft (to enable certificate discovery bottom-up). >>>>> >>>>> >>>>>>The conclusion is that we suggest changes to the introduction >>>>>>section but we keep the old security considerations intact. >>>>> >>>>> >>>>>I would suggest that a merge would need to be done between the >>>> > "old" > >>>>>security considerations section and the "new" one. >>>>> >>>>>The "old" security considerations section is mentionning a >>>>>solution which does NOT suppress the problem, but minimize the >>>>>risk only in case the CAs are really "honest". >>>>> >>>>>The old" security considerations section does not provide a >>>>>solution in case the name collsion between two CRL issuer name is >>>>>deliberate, whereas the "new" security considerations section >>>>>provides a secure solution in one case and clearly mentions that >>>>>all other cases are dependant about "zillions" of *local* trust >>>>>conditions which cannot all be standardized. >>>>> >>>>>The main purpose of a security considerations section is to >>>>>provide the adequate warnings and solutions when they exist and >>>>>not to hide the problems. >>>>> >>>>> >>>>>>That is not because >>>>>>we necessarily disagree with all of the statements in your >>>>> >>>proposal, but >>> >>>>>>in the cases we don't, we still think it is out of scope for this >>>>> >>>work. >>> >>>>> >>>>>This is clearly within the scope of a security considerations >>>> > section. > >>>>>>The new introduction proposal based on your input is: >>>>>>-------------------------------------------------------------- >>>>>>RFC 3280 [PKIX1] specifies the validation of certification paths. >>>>> > >>>One >>> >>>>>>aspect involves the determination that a certificate has not been >>>>> > >>>>>>revoked, and one revocation checking mechanism is the Certificate >>>>> > >>>>>>Revocation List (CRL). CRL validation is also specified in RFC >>>>>>3280, >>>>> >>>>> >>>>>I would love this last sentence to be true but the reality is >>>> > that: > >>>>>"CRL validation is NOT specified in RFC 3280". :-( >>>>> >>>>> >>>>>>which involves the constructions of a valid certification path >>>>>>for >>>>> >>>the >>> >>>>>>CRL issuer. >>>>> >>>>> >>>>>There is no such a statement in RFC 3280. >>>>> >>>>> >>>>>>Building a CRL issuer certification path from the signer of >>>>> >>>>> >>>>>There is no notion of "CRL issuer certification path" in RFC 3280. >>>>>The primary requirement is to make sure that the CRL issuer >>>>>designated by the CA is indeed the right one. In some (but not >>>>>all) cases, I mean among the zillion of cases, there MAY be a need >>>> > >>>>>to construct a CRL issuer certification path. >>>>> >>>>> >>>>>>the CRL to a trust anchor is straightforward when the certificate >>>>> >>>of the >>> >>>>>>CRL issuer is present in the certification path associated with >>>>>>the target certificate, but it can be complex in other >>>>> > situations. > >>>>> >>>>>From the comments above, you can see that I cannot agree with the >>>>>above revised text. The remaining of the text is acceptable in >>>>>general, but could possibly be slightly revised to be more in >>>>>continuation with the changes there are needed above (i.e. it is >>>>>not cast in concrete). >>>>> >>>>>Denis >>>>> >>>>> >>>>>>There are several legitimate scenarios where the certificate of >>>>> >>>the CRL >>> >>>>>>issuer is not present, or easily discovered, from the target >>>>>>certification path. This can be the case when indirect CRLs are >>>>> >>>used, >>> >>>>>>when the certification Authority (CA) that issued the target >>>>> >>>certificate >>> >>>>>>changes its certificate signing key, or when the CA employs >>>>>>separate keys for certificate signing and CRL signing. >>>>>>Methods of finding the certificate of the CRL issuer are >>>>>>currently available, such as though an accessible directory >>>>>>location or through use of the Subject Information Access >>>>>>extension in intermediary CA certificates. >>>>>>Directory lookup requires existence and access to a directory >>>>>>that >>>>> >>>has >>> >>>>>>been populated with all of the necessary certificates. The >>>>>>Subject Information Access extension, which supports building the >>>>> > >>>>>>CRL issuer certification path top-down (in the direction from the >>>>> > >>>>>>trust >>>>> >>>anchor to >>> >>>>>>the CRL issuer), requires that some certificates in the CRL >>>>>>issuer certification path includes an appropriate Subject >>>>>>Information Access extension. >>>>>>RFC 3280 [PKIX1] provides for bottom-up discovery of >>>>>>certification >>>>> >>>paths >>> >>>>>>through the Authority Information Access extension, where the >>>>>>id-ad-caIssuers access method may specify one or more >>>>>>accessLocation fields that reference CA certificates associated >>>>>>with the certificate containing this extension. >>>>>>This document enables the use of the Authority Information Access >>>>> > >>>>>>extension in CRLs, enabling a CRL checking application to use the >>>>> >>>access >>> >>>>>>method (id-ad-caIssuers) to locate certificates that may be >>>>>>useful in the construction of a valid CRL issuer certification >>>>>>path to an appropriate trust anchor. >>>>>> >>>>>>Stefan Santesson >>>>>>Program Manager, Standards Liaison Windows Security >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>>>>>>Sent: den 18 april 2005 13:41 >>>>>>>To: Stefan Santesson >>>>>>>Cc: Russ Housley; pkix >>>>>>>Subject: Re: Comments on >>>>>>> >>>>>>>Stefan, >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Denis, >>>>>>> >>>>>>> >>>>>>>>I will come back and comment on your text proposals, but before >>>>>>> >>>>>>that, >>>>>> >>>>>> >>>>>>>>a few questions/comments: >>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>You point out some well known issues related to the lack of >>>>>>>>> >>>>>>absolute >>>>>> >>>>>> >>>>>>>>>>cryptographic binding between CRL and certificates where the >>>>>>>>>>certificate and CRL is not signed by the same key. >>>>>>>>> >>>>>>>>> >>>>>>>>>Not really. It is indeed possible to have an absolute >>>>>>>> >>>cryptographic >>> >>>>>>>>>binding between CRL and certificates where the certificate and >>>>>>>> > CRL > >>>>>>is >>>>>> >>>>>> >>>>>>>not >>>>>>> >>>>>>> >>>>>>>>>signed by the same key, but the key point is that proposed >>>>>>>> >>>>>>extension >>>>>> >>>>>> >>>>>>>>>is *not* the means to provide such a binding (and you agree >>>>>>>> > with > >>>>>>this >>>>>> >>>>>> >>>>>>>>>further down in this e-mail). >>>>>>>> >>>>>>> >>>>>>>>We agree that this extension does not add to the concept of >>>>>>>>cryptographic binding. But how do you mean it can be done? >>>>>>> >>>>>>> >>>>>>>Would this mean that you believed this could not be done ? :-) >>>>>>> >>>>>>>I already provided the information, but since at that time you >>>>>> > were > >>>>>>>focussing on another issue, you probably missed the point. >>>>>>> >>>>>>>I would encourage you to read again that thread, but I will >>>>>> >>>provide a >>> >>>>>>>short >>>>>>>reply here to your question. >>>>>>> >>>>>>>This can be done using cRLIssuer from the CRL DP. cRLIssuer >>>>>> > contains > >>>>>>the >>>>>> >>>>>> >>>>>>>DN >>>>>>>of the CRL Issuer and we all know that CAs are free to assign >>>>>> > the > >>>DNs >>> >>>>>>they >>>>>> >>>>>> >>>>>>>wish. The next point is for a verifier to make sure that the DN >>>>>> >>>which >>> >>>>>>>identifies the CRL Issuer (in the CRL DP) is indeed the one that >>>>>> > was > >>>>>>meant >>>>>> >>>>>> >>>>>>>by the CA. The CRL must be issued by a CRL Issuer that has the >>>>>> > same > >>>>>>DN. >>>>>> >>>>>> >>>>>>>The >>>>>>>CRL Issuer will have a certificate issued by a CA. >>>>>>> >>>>>>>Case a): the CA that has issued that certificate is the same as >>>>>> >>>the CA >>> >>>>>>>that >>>>>>>has issued the target certificate (which contains the hereabove >>>>>> >>>>>>mentionned >>>>>> >>>>>> >>>>>>>CRL DP). This is easy to check for a verifier since the verifier >>>>>> > >>>must >>> >>>>>>>first >>>>>>>build the certification path and then test the revocation status >>>>>> > of > >>>>>>every >>>>>> >>>>>> >>>>>>>element of the path. So the verifier knows the validated >>>>>> > sequence of > >>>>>>DNs >>>>>> >>>>>> >>>>>>>starting from a self-signed certificate. It must then use the >>>>>> > same > >>>>>>>sequence >>>>>>>of DNs to validate the CRL Issuer certificate. >>>>>>> >>>>>>>This is a general rule which does not require any extra local >>>>>> > trust > >>>>>>>information. >>>>>>> >>>>>>>Case b) : the CA that has issued that certificate is NOT the >>>>>> > same as > >>>>>>the >>>>>> >>>>>> >>>>>>>CA >>>>>>>that has issued the target certificate. This case requires extra >>>>>> >>>>>>*0local* >>>>>> >>>>>> >>>>>>>trust information. There are many such trust conditions possible >>>>>> > and > >>>>>>thus >>>>>> >>>>>> >>>>>>>this cannot be defined in general. Cases a) and b) are thus not >>>>>> >>>>>>equivalent >>>>>> >>>>>> >>>>>>>and have to be distinguished. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>This draft only introduces a new way to locate certificates >>>>>>>>>>that can be helpful in building this path. >>>>>>>>> >>>>>>>>> >>>>>>>>>At least one sentence of which we both agree ! >>>>>>>>>It should be copied and pasted in the abstract. >>>>>>>> >>>>>>>> >>>>>>>>Good, then I suggest that we leave unrelated topics out of this >>>>>>> >>>>>>draft >>>>>> >>>>>> >>>>>>>>and focus on the issues that are related to this limited scope. >>>>>>> >>>>>>> >>>>>>>This is what I did in my proposal, except that we need to have a >>>>>> >>>>>>security >>>>>> >>>>>> >>>>>>>considerations section and the goal of that section is not to >>>>>> > hide > >>>>>>>problems >>>>>>>but to correctly warn users. Thus why an informatiove annex on >>>>>> > the > >>>>>>topics >>>>>> >>>>>> >>>>>>>mentionned in the security considerations section would be quite >>>>>> >>>>>>useful. >>>>>> >>>>>> >>>>>>>In fact, its content would be along the lines of the >>>>>> > explanations > >>>>>>which >>>>>> >>>>>> >>>>>>>are >>>>>>>just above. >>>>>>> >>>>>>>I hope this e-mail will help us to progress. >>>>>>> >>>>>>>Denis >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Stefan Santesson >>>>>>>>Program Manager - Standards Liaison >>>>>>>>Windows Security >>>>>>> >>>>> >>>> >>> >>> >> > > > From owner-ietf-pkix@mail.imc.org Thu May 12 06:08:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11069 for ; Thu, 12 May 2005 06:08:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9Q35C096521; Thu, 12 May 2005 02:26:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9Q3l3096520; Thu, 12 May 2005 02:26:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9Q0AL096442 for ; Thu, 12 May 2005 02:26:01 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA27662; Thu, 12 May 2005 11:40:43 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051211254571:969 ; Thu, 12 May 2005 11:25:45 +0200 Message-ID: <42832153.8000802@bull.net> Date: Thu, 12 May 2005 11:26:43 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: pkix Subject: Re: Comments on References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:25:45, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:25:47, Serialize complete at 12/05/2005 11:25:47 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, Since Tim has now made the call at the WG level, please consider this message as an answer to the call: the current security considerations section is not acceptable. > The document already says that the CA and the CRL issuer need to > terminate at the same trust anchor. This is the important point. > I disagree that there is anything else that ought to be said in the > security considerations. This statement still does not answer to the point I raised, but I will nevertheless answer to your statement. The same trust anchor is not a *sufficient* condition. The same node in the certification tree is the necessary condition. This implies, of course, the same trust anchor, but since two CRL issuers located at different nodes (i.e. certified by different CAS) might have the same CRL issuer name, this condition is insufficient to solve the issue. May I recall an extract from the security considerations section of an approved draft that will be published soon as RFC 4043 ? (this is the permanent-identifier document): Subject names in certificates are chosen by the issuing CA and are mandated to be unique for each CA; so there can be no name collision between subject names from the same CA. Such a name may be an end- entity name when the certificate is a leaf certificate, or a CA name, when it is a CA certificate. Since a name is only unique towards its superior CA, unless some naming constraints are being used, a name would only be guaranteed to be globally unique when considered to include a sequence of all the names of the superior CAs. (...) Additional checks need to be done, e.g., to check if the public key values of the two CAs which have issued the certificates to be compared are identical or if the sequence of CA names in the certification path from the trust anchor to the CA are identical. (...) The certification of different CAs with the same DN by different CAs has other negative consequences in various parts of the PKI, notably rendering the IssuerAndSerialNumber structure in [RFC3852] section 10.2.4 ambiguous. It speaks for itself, as it applies to CRL Issuers as well. Some parts of it should indeed be copied and pasted in the security considerations section of the current proposed draft. When the certification path used to validate the target certificate is also used to validate the CRL Issuer certificate, then there is no security issue: this should be said in the security considerations section. What about the other cases ? The other cases belong to the category of indirect CRLs. Depending on the local validation policy checks done or not done there may be security issues. Denis > Russ > > At 02:59 AM 5/10/2005, Denis Pinkas wrote: > >> Russ, >> >> Your statement below is correct, but does not answer to any of my >> questions/issues. In particular, the last one. I am still awaiting >> your responses. >> >> Denis >> >>> Denis: >>> RFC 3280 does not tell an implementor how for locate certificates for >>> any certification path construction. There are several extensions >>> that provide pointers that may help an implementation, but other >>> approaches to obtaining the same certificates are always permitted. >>> I would fully expect an implementation to check any local cache >>> before accessing a repository. >>> The CRL AIA extension fits this pattern. A method for locating a >>> certificate is provided, but any other mechanism for locating the >>> same certificate is acceptable. >>> Russ >>> >>>> Stefan, >>>> >>>> I made the e-mail shorter. Your main arguments are the following: >>>> >>>> ========================================================================== >>>> >>>> >>>> [Stefan] But it has to provide a warning to something that is >>>> introduced >>>> by the standard. This standard does not introduce the concept of CRL >>>> signature checking or CRL issuer certificate validation, so that is >>>> clearly out of scope. More about that below; >>>> >>>> [Denis] See below the last answer and also my arguments in the >>>> soon-to-be-posted answer to Russ. >>>> >>>> ========================================================================== >>>> >>>> >>>> >>>> > > RFC 3280 [PKIX1] specifies the validation of certification paths. >>>> > > One aspect involves the determination that a certificate has not >>>> been >>>> > > revoked, and one revocation checking mechanism is the Certificate >>>> > > Revocation List (CRL). CRL validation is also specified in RFC >>>> 3280, >>>> >>>> > I would love this last sentence to be true but the reality is that: >>>> > "CRL validation is NOT specified in RFC 3280". :-( >>>> >>>> [Stefan] In fact it is. >>>> >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: >>>> >>>> (f) Obtain and validate the certification path for the complete CRL >>>> issuer. If a key usage extension is present in the CRL issuer's >>>> certificate, verify that the cRLSign bit is set. >>>> >>>> (g) Validate the signature on the complete CRL using the public key >>>> validated in step (f). >>>> >>>> [Denis] The text does not say how to obtain and validate the >>>> certification path for the complete (???) CRL issuer. The text is >>>> not clear enough so that two implementors only looking at this >>>> sentence will provide interoperable implementations. >>>> >>>> ========================================================================== >>>> >>>> >>>> [Stefan] It is my hope that the provided responses here can help >>>> convince you to change your mind about that. If it doesn't I still >>>> argue >>>> that the place to specify requirements and security considerations for >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. >>>> >>>> [Denis] I can agree with your last sentence, ... which means that it >>>> should not be in the main body of the document. In the security >>>> considerations section, text is free and we shall at the very >>>> minimum warn implementers and we should provide some guidance. When >>>> the same certification path (i.e. the path used to validate the >>>> target certificate) is used, then there is no security issue: this >>>> should be said. For all other cases, there MAY be problems: this >>>> should also be said. It is as simple as that. >>>> >>>> Denis >>> >> >> > > From owner-ietf-pkix@mail.imc.org Thu May 12 06:25:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11875 for ; Thu, 12 May 2005 06:25:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9fk8c002777; Thu, 12 May 2005 02:41:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9fkOo002776; Thu, 12 May 2005 02:41:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9fii8002735 for ; Thu, 12 May 2005 02:41:45 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA30866; Thu, 12 May 2005 11:56:34 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051211413567:975 ; Thu, 12 May 2005 11:41:35 +0200 Message-ID: <42832509.5020001@bull.net> Date: Thu, 12 May 2005 11:42:33 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org Subject: Re: Comments on References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:41:35, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:41:37, Serialize complete at 12/05/2005 11:41:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, > Denis: >>> Yes, it is OBVIOUS that the CRL issuer certificate needs to be >>> validated. >>> You say that it is not clear what validation policy needs to be used, >>> but this is completely irrelevant to the discussion of the CRL AIA >>> extension. This extension aid in certification path construction, >>> not the validation of the path once it is constructed. >> Not exactly, it could "help" finding a wrong path ! > Not likely. The signer of the CRL is providing a pointer to their own > certificate. Path construction to locate a parent of that certificate > through a complex PKI might include paths that are acceptable and paths > that are unacceptable, but the certificate that contains the public key > needed to validate the signature on the CRL is clearly needed. The problem is to know if a CRL that has been fetched "somewhere" is adequate for the target certificate. It is not to validate a CRL that has been fetched "somewhere". >>> There are many factors which need to be considered in the validation >>> of the CRL issue certificate. The values of the key usage extension >>> and the certificate policies extension are two that jump to mind. >>> There are probably more if I spend the time to consider each possible >>> scenario. >> One simple rule would allow no security problem at all and I wonder >> why you have so much resistance to mention it. > We have that rule: The CA certificate and the CRL Issuer certificate > must validate back to the same trust anchor. As explained in a just posted e-mail this rule is insufficient and thus insecure. >>> In my opinion, this document is ready for WG Last Call. >> >> >> As an editor of the draft, I may understand your position; but it is >> up the the PKIX chairs to decide whether or not the document is ready >> for WG last call. > Correct. I included this sentence for the WG chairs. I hope they will > agree with me, and that they will issue WG Last Call for this document. >> Once again the current Security Considerations section is not acceptable. > To you... No one else is advocating this change. I continue to believe > that requiring the CA certificate and the CRL Issuer certificate to > validate back to the same trust anchor resolves your concern. It does not. > I am > willing to add a few words to the security considerations about name > collisions (my co-author may disagree), but I am not willing to use > "MUST" or "SHOULD" in those words. We agree that "MUST" or "SHOULD" should not be used in the security considerations section. > There is absolutely nothing that a > client can do to determine deal with name collisions that are > subordinate to the same trust anchor. This last statement is wrong. Please look again at the security considerations section of "Permanent Identifier". As an example: "Since a name is only unique towards its superior CA, unless some naming constraints are being used, a name would only be guaranteed to be globally unique when considered to include a sequence of all the names of the superior CAs". Denis > Russ From owner-ietf-pkix@mail.imc.org Thu May 12 06:26:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11989 for ; Thu, 12 May 2005 06:26:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9iUN5003789; Thu, 12 May 2005 02:44:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9iUOf003787; Thu, 12 May 2005 02:44:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9iSlT003743 for ; Thu, 12 May 2005 02:44:29 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA42990; Thu, 12 May 2005 11:59:16 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051211441863:976 ; Thu, 12 May 2005 11:44:18 +0200 Message-ID: <428325AC.40803@bull.net> Date: Thu, 12 May 2005 11:45:16 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley , Stefan Santesson CC: ietf-pkix@imc.org Subject: Typo in References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:44:18, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:44:19, Serialize complete at 12/05/2005 11:44:19 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Please correct this typo: AccessDescription specifying id-ad-caIssuers as the acessMethod ^^ Denis From owner-ietf-pkix@mail.imc.org Thu May 12 06:38:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12883 for ; Thu, 12 May 2005 06:38:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9qvQ6006874; Thu, 12 May 2005 02:52:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9qvCk006873; Thu, 12 May 2005 02:52:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9qtYe006831 for ; Thu, 12 May 2005 02:52:56 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 10:52:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Typo in Date: Thu, 12 May 2005 10:52:40 +0100 Message-ID: Thread-Topic: Typo in Thread-Index: AcVW1zet5QWtTlXUQOKcWj4FUUU00QAAQuGQ From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: X-OriginalArrivalTime: 12 May 2005 09:52:50.0270 (UTC) FILETIME=[5BC837E0:01C556D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C9quYe006865 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Thanks Denis, Typo noted and will be corrected Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 12 maj 2005 11:45 > To: Russ Housley; Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: Typo in > > Please correct this typo: > > AccessDescription specifying id-ad-caIssuers as the acessMethod > ^^ > > > Denis > > From owner-ietf-pkix@mail.imc.org Thu May 12 08:19:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19136 for ; Thu, 12 May 2005 08:19:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CBdO5c050018; Thu, 12 May 2005 04:39:24 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CBdOE2050017; Thu, 12 May 2005 04:39:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CBdNw8049980 for ; Thu, 12 May 2005 04:39:23 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 12:39:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on Date: Thu, 12 May 2005 12:39:08 +0100 Message-ID: Thread-Topic: Comments on Thread-Index: AcVW20qkEAyEpBkhR1uSL+f+s8bQ/AACcm3A From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: "pkix" X-OriginalArrivalTime: 12 May 2005 11:39:17.0645 (UTC) FILETIME=[3AF44BD0:01C556E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CBdOw8050011 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, My main comment to this is that there is no exact definition of what is "sufficient" in this case. What is sufficient to you may not be sufficient to me or vice versa. This issue is as many times when security is the issue a tradeoff. In IT security you always have the 3 goals: - Cheep - Easy to use - Secure The sad truth is that we often discover that we can have any 2 of those but never all 3. The fact about name uniqueness you provide in the referenced text is a true facts but it still does not tell me what is sufficient or not in my environment or how I can achieve reasonable security when the trust paths differ (in case they have to). My basic assessment is that there is neither a single truth nor a single solution to the problem. The chaining to a common root was the reasonable recommendation agreed at the San Diego PKIX meeting. This is in my mind not intended to be advertised as a "sufficient" solution, just good practice to reduce the risk of problems. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 12 maj 2005 11:27 > To: Russ Housley > Cc: pkix > Subject: Re: Comments on > > > Russ, > > Since Tim has now made the call at the WG level, please consider this > message as an answer to the call: the current security considerations > section is not acceptable. > > > The document already says that the CA and the CRL issuer need to > > terminate at the same trust anchor. This is the important point. > > I disagree that there is anything else that ought to be said in the > > security considerations. > > This statement still does not answer to the point I raised, but > I will nevertheless answer to your statement. > > The same trust anchor is not a *sufficient* condition. The same node in > the > certification tree is the necessary condition. This implies, of course, > the > same trust anchor, but since two CRL issuers located at different nodes > (i.e. certified by different CAS) might have the same CRL issuer name, > this > condition is insufficient to solve the issue. > > May I recall an extract from the security considerations section of an > approved draft that will be published soon as RFC 4043 ? (this is the > permanent-identifier document): > > Subject names in certificates are chosen by the issuing CA and are > mandated to be unique for each CA; so there can be no name collision > between subject names from the same CA. Such a name may be an end- > entity name when the certificate is a leaf certificate, or a CA > name, > when it is a CA certificate. > > Since a name is only unique towards its superior CA, unless some > naming constraints are being used, a name would only be guaranteed > to > be globally unique when considered to include a sequence of all the > names of the superior CAs. (...) > > Additional checks need to be done, e.g., to check if the public key > values of the two CAs which have issued the certificates to be > compared are identical or if the sequence of CA names in the > certification path from the trust anchor to the CA are identical. > > (...) > > The certification of different CAs with the same DN by different CAs > has other negative consequences in various parts of the PKI, notably > rendering the IssuerAndSerialNumber structure in [RFC3852] section > 10.2.4 ambiguous. > > It speaks for itself, as it applies to CRL Issuers as well. Some parts of > it should indeed be copied and pasted in the security considerations > section > of the current proposed draft. > > When the certification path used to validate the target certificate is > also used to validate the CRL Issuer certificate, then there is no > security > issue: this should be said in the security considerations section. > > What about the other cases ? The other cases belong to the category of > indirect CRLs. Depending on the local validation policy checks done or not > done there may be security issues. > > Denis > > > Russ > > > > At 02:59 AM 5/10/2005, Denis Pinkas wrote: > > > >> Russ, > >> > >> Your statement below is correct, but does not answer to any of my > >> questions/issues. In particular, the last one. I am still awaiting > >> your responses. > >> > >> Denis > >> > >>> Denis: > >>> RFC 3280 does not tell an implementor how for locate certificates > for > >>> any certification path construction. There are several extensions > >>> that provide pointers that may help an implementation, but other > >>> approaches to obtaining the same certificates are always permitted. > >>> I would fully expect an implementation to check any local cache > >>> before accessing a repository. > >>> The CRL AIA extension fits this pattern. A method for locating a > >>> certificate is provided, but any other mechanism for locating the > >>> same certificate is acceptable. > >>> Russ > >>> > >>>> Stefan, > >>>> > >>>> I made the e-mail shorter. Your main arguments are the following: > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> [Stefan] But it has to provide a warning to something that is > >>>> introduced > >>>> by the standard. This standard does not introduce the concept of > CRL > >>>> signature checking or CRL issuer certificate validation, so that is > >>>> clearly out of scope. More about that below; > >>>> > >>>> [Denis] See below the last answer and also my arguments in the > >>>> soon-to-be-posted answer to Russ. > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> > >>>> > > RFC 3280 [PKIX1] specifies the validation of certification > paths. > >>>> > > One aspect involves the determination that a certificate has > not > >>>> been > >>>> > > revoked, and one revocation checking mechanism is the > Certificate > >>>> > > Revocation List (CRL). CRL validation is also specified in RFC > >>>> 3280, > >>>> > >>>> > I would love this last sentence to be true but the reality is > that: > >>>> > "CRL validation is NOT specified in RFC 3280". :-( > >>>> > >>>> [Stefan] In fact it is. > >>>> > >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: > >>>> > >>>> (f) Obtain and validate the certification path for the complete > CRL > >>>> issuer. If a key usage extension is present in the CRL issuer's > >>>> certificate, verify that the cRLSign bit is set. > >>>> > >>>> (g) Validate the signature on the complete CRL using the public > key > >>>> validated in step (f). > >>>> > >>>> [Denis] The text does not say how to obtain and validate the > >>>> certification path for the complete (???) CRL issuer. The text is > >>>> not clear enough so that two implementors only looking at this > >>>> sentence will provide interoperable implementations. > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> [Stefan] It is my hope that the provided responses here can help > >>>> convince you to change your mind about that. If it doesn't I still > >>>> argue > >>>> that the place to specify requirements and security considerations > for > >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL > draft. > >>>> > >>>> [Denis] I can agree with your last sentence, ... which means that > it > >>>> should not be in the main body of the document. In the security > >>>> considerations section, text is free and we shall at the very > >>>> minimum warn implementers and we should provide some guidance. When > >>>> the same certification path (i.e. the path used to validate the > >>>> target certificate) is used, then there is no security issue: this > >>>> should be said. For all other cases, there MAY be problems: this > >>>> should also be said. It is as simple as that. > >>>> > >>>> Denis > >>> > >> > >> > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 12 08:19:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19162 for ; Thu, 12 May 2005 08:19:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CBNveA043725; Thu, 12 May 2005 04:23:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CBNvFT043724; Thu, 12 May 2005 04:23:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CBNt7X043673 for ; Thu, 12 May 2005 04:23:55 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 12:23:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Structuring Denis issues RE: Comments on Date: Thu, 12 May 2005 12:23:40 +0100 Message-ID: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVW20qkEAyEpBkhR1uSL+f+s8bQ/AAB8tDw From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: "pkix" X-OriginalArrivalTime: 12 May 2005 11:23:49.0672 (UTC) FILETIME=[11D6DA80:01C556E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CBNu7X043716 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, The core of your comments are spread over many emails and opinions may have changed on details so I'm not sure I have got the latest picture of your recorded problems and what you propose as resolution. I'm thus trying to summarize the current complete picture of the last call comments below. Please correct me if something is wrong or missing. Note that I'm not arguing here, just trying to structure the issues (I will argue in separate mails). Also note that agreed typos are omitted from the list: 1) Problem: There are SHOULD and MUST requirements in the security considerations section. Proposed resolution: Reword to make sure we don't use SHOULD or MUST in this section. ----- 2) Problem: The security considerations talk about "mitigation" of the name collision problem but gives inadequate advice. Proposed resolution: Either delete all text talking about how to mitigate this problem or provide full guidance on what it takes to guarantee that a CRL Issuer with a matching name actually is the intended CRL Issuer. Also explain that this is not an issue when the CRL Issuer certification path and the target certificate certification path are identical. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 12 maj 2005 11:27 > To: Russ Housley > Cc: pkix > Subject: Re: Comments on > > > Russ, > > Since Tim has now made the call at the WG level, please consider this > message as an answer to the call: the current security considerations > section is not acceptable. > > > The document already says that the CA and the CRL issuer need to > > terminate at the same trust anchor. This is the important point. > > I disagree that there is anything else that ought to be said in the > > security considerations. > > This statement still does not answer to the point I raised, but > I will nevertheless answer to your statement. > > The same trust anchor is not a *sufficient* condition. The same node in > the > certification tree is the necessary condition. This implies, of course, > the > same trust anchor, but since two CRL issuers located at different nodes > (i.e. certified by different CAS) might have the same CRL issuer name, > this > condition is insufficient to solve the issue. > > May I recall an extract from the security considerations section of an > approved draft that will be published soon as RFC 4043 ? (this is the > permanent-identifier document): > > Subject names in certificates are chosen by the issuing CA and are > mandated to be unique for each CA; so there can be no name collision > between subject names from the same CA. Such a name may be an end- > entity name when the certificate is a leaf certificate, or a CA > name, > when it is a CA certificate. > > Since a name is only unique towards its superior CA, unless some > naming constraints are being used, a name would only be guaranteed > to > be globally unique when considered to include a sequence of all the > names of the superior CAs. (...) > > Additional checks need to be done, e.g., to check if the public key > values of the two CAs which have issued the certificates to be > compared are identical or if the sequence of CA names in the > certification path from the trust anchor to the CA are identical. > > (...) > > The certification of different CAs with the same DN by different CAs > has other negative consequences in various parts of the PKI, notably > rendering the IssuerAndSerialNumber structure in [RFC3852] section > 10.2.4 ambiguous. > > It speaks for itself, as it applies to CRL Issuers as well. Some parts of > it should indeed be copied and pasted in the security considerations > section > of the current proposed draft. > > When the certification path used to validate the target certificate is > also used to validate the CRL Issuer certificate, then there is no > security > issue: this should be said in the security considerations section. > > What about the other cases ? The other cases belong to the category of > indirect CRLs. Depending on the local validation policy checks done or not > done there may be security issues. > > Denis > > > Russ > > > > At 02:59 AM 5/10/2005, Denis Pinkas wrote: > > > >> Russ, > >> > >> Your statement below is correct, but does not answer to any of my > >> questions/issues. In particular, the last one. I am still awaiting > >> your responses. > >> > >> Denis > >> > >>> Denis: > >>> RFC 3280 does not tell an implementor how for locate certificates > for > >>> any certification path construction. There are several extensions > >>> that provide pointers that may help an implementation, but other > >>> approaches to obtaining the same certificates are always permitted. > >>> I would fully expect an implementation to check any local cache > >>> before accessing a repository. > >>> The CRL AIA extension fits this pattern. A method for locating a > >>> certificate is provided, but any other mechanism for locating the > >>> same certificate is acceptable. > >>> Russ > >>> > >>>> Stefan, > >>>> > >>>> I made the e-mail shorter. Your main arguments are the following: > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> [Stefan] But it has to provide a warning to something that is > >>>> introduced > >>>> by the standard. This standard does not introduce the concept of > CRL > >>>> signature checking or CRL issuer certificate validation, so that is > >>>> clearly out of scope. More about that below; > >>>> > >>>> [Denis] See below the last answer and also my arguments in the > >>>> soon-to-be-posted answer to Russ. > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> > >>>> > > RFC 3280 [PKIX1] specifies the validation of certification > paths. > >>>> > > One aspect involves the determination that a certificate has > not > >>>> been > >>>> > > revoked, and one revocation checking mechanism is the > Certificate > >>>> > > Revocation List (CRL). CRL validation is also specified in RFC > >>>> 3280, > >>>> > >>>> > I would love this last sentence to be true but the reality is > that: > >>>> > "CRL validation is NOT specified in RFC 3280". :-( > >>>> > >>>> [Stefan] In fact it is. > >>>> > >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: > >>>> > >>>> (f) Obtain and validate the certification path for the complete > CRL > >>>> issuer. If a key usage extension is present in the CRL issuer's > >>>> certificate, verify that the cRLSign bit is set. > >>>> > >>>> (g) Validate the signature on the complete CRL using the public > key > >>>> validated in step (f). > >>>> > >>>> [Denis] The text does not say how to obtain and validate the > >>>> certification path for the complete (???) CRL issuer. The text is > >>>> not clear enough so that two implementors only looking at this > >>>> sentence will provide interoperable implementations. > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> [Stefan] It is my hope that the provided responses here can help > >>>> convince you to change your mind about that. If it doesn't I still > >>>> argue > >>>> that the place to specify requirements and security considerations > for > >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL > draft. > >>>> > >>>> [Denis] I can agree with your last sentence, ... which means that > it > >>>> should not be in the main body of the document. In the security > >>>> considerations section, text is free and we shall at the very > >>>> minimum warn implementers and we should provide some guidance. When > >>>> the same certification path (i.e. the path used to validate the > >>>> target certificate) is used, then there is no security issue: this > >>>> should be said. For all other cases, there MAY be problems: this > >>>> should also be said. It is as simple as that. > >>>> > >>>> Denis > >>> > >> > >> > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 12 09:41:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23949 for ; Thu, 12 May 2005 09:41:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCeuwd070936; Thu, 12 May 2005 05:40:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CCeunm070935; Thu, 12 May 2005 05:40:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCetv4070919 for ; Thu, 12 May 2005 05:40:55 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from [10.0.0.81] (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft6.fr.colt.net with ESMTP id j4CCenp19895; Thu, 12 May 2005 14:40:50 +0200 Message-ID: <42834ED0.9090306@free.fr> Date: Thu, 12 May 2005 14:40:48 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050501 MIME-Version: 1.0 To: Hoyt L Kesterson II CC: pkix Subject: Re: Technical Corrigenda 3 to the 4th edition of X.509 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hoyt L Kesterson II wrote: > Some you worked with the X.509 standards committee over the last few > years revising the text on key usage. > > You can find the text of that Technical Corrigenda at: > ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf You should avoid using characters in the filename that are not compatible with the Microsoft OS, it makes it harder to download that file. From the text : "Bits in the KeyUsage type are as follows: [...] c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport; d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above; e) keyAgreement: for use as a public key agreement key;" It's not yet very precise. The contentCommitment bit text got very clear, so it shows how much we can improve on those bits. The text by Peter is quite good, how about : c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport, and also data encryption that uses an intermediate symmetric cipher; d) dataEncipherment: for directly enciphering raw user data, without the use of an intermediate symmetric cipher e) keyAgreement: for use as a public key agreement key, for example a Diffie-Hellman protocol key; Shouldn't we best find a way to say that an SSL client requires at a minimum only digitalSignature, but the SSL server must have keyEncipherment ? Maybe we should precise : In practice when someone wishes to send enciphered key or security information, he must check that the recipient has the keyEncipherment bit set before using his public key to encipher. For example in an SSL handshake, the client must check that the server has the keyEncipherment bit set before sending him an enciphered secret, but never needs to have that bit set in his own certificate, because the server will use his certificate only for authentification, not to send enciphered data. From owner-ietf-pkix@mail.imc.org Thu May 12 10:04:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26264 for ; Thu, 12 May 2005 10:04:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCuksv076754; Thu, 12 May 2005 05:56:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CCukP9076753; Thu, 12 May 2005 05:56:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCui43076701 for ; Thu, 12 May 2005 05:56:45 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 13:56:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Structuring Denis issues RE: Comments on Date: Thu, 12 May 2005 13:56:29 +0100 Message-ID: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVW20qkEAyEpBkhR1uSL+f+s8bQ/AAB8tDwAAOjX8A= From: "Stefan Santesson" To: "Stefan Santesson" , "Denis Pinkas" , "Russ Housley" Cc: "pkix" X-OriginalArrivalTime: 12 May 2005 12:56:38.0773 (UTC) FILETIME=[09483A50:01C556F2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CCuj43076746 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, Reading my own e-mail I think I was not 100% clear on one point. "Proposed resolution" should read "Denis proposed resolution". Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Stefan Santesson > Sent: den 12 maj 2005 13:24 > To: Denis Pinkas; Russ Housley > Cc: pkix > Subject: Structuring Denis issues RE: Comments on 00.txt> > > > Denis, > > The core of your comments are spread over many emails and opinions may > have changed on details so I'm not sure I have got the latest picture of > your recorded problems and what you propose as resolution. > > I'm thus trying to summarize the current complete picture of the last > call comments below. Please correct me if something is wrong or missing. > Note that I'm not arguing here, just trying to structure the issues (I > will argue in separate mails). Also note that agreed typos are omitted > from the list: > > 1) > Problem: There are SHOULD and MUST requirements in the security > considerations section. > > Proposed resolution: Reword to make sure we don't use SHOULD or MUST in > this section. > > ----- > 2) > Problem: The security considerations talk about "mitigation" of the name > collision problem but gives inadequate advice. > > Proposed resolution: Either delete all text talking about how to > mitigate this problem or provide full guidance on what it takes to > guarantee that a CRL Issuer with a matching name actually is the > intended CRL Issuer. Also explain that this is not an issue when the CRL > Issuer certification path and the target certificate certification path > are identical. > > > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Denis Pinkas > > Sent: den 12 maj 2005 11:27 > > To: Russ Housley > > Cc: pkix > > Subject: Re: Comments on > > > > > > Russ, > > > > Since Tim has now made the call at the WG level, please consider this > > message as an answer to the call: the current security considerations > > section is not acceptable. > > > > > The document already says that the CA and the CRL issuer need to > > > terminate at the same trust anchor. This is the important point. > > > I disagree that there is anything else that ought to be said in > the > > > security considerations. > > > > This statement still does not answer to the point I raised, but > > I will nevertheless answer to your statement. > > > > The same trust anchor is not a *sufficient* condition. The same node > in > > the > > certification tree is the necessary condition. This implies, of > course, > > the > > same trust anchor, but since two CRL issuers located at different > nodes > > (i.e. certified by different CAS) might have the same CRL issuer name, > > this > > condition is insufficient to solve the issue. > > > > May I recall an extract from the security considerations section of an > > approved draft that will be published soon as RFC 4043 ? (this is the > > permanent-identifier document): > > > > Subject names in certificates are chosen by the issuing CA and > are > > mandated to be unique for each CA; so there can be no name > collision > > between subject names from the same CA. Such a name may be an > end- > > entity name when the certificate is a leaf certificate, or a CA > > name, > > when it is a CA certificate. > > > > Since a name is only unique towards its superior CA, unless some > > naming constraints are being used, a name would only be > guaranteed > > to > > be globally unique when considered to include a sequence of all > the > > names of the superior CAs. (...) > > > > Additional checks need to be done, e.g., to check if the public > key > > values of the two CAs which have issued the certificates to be > > compared are identical or if the sequence of CA names in the > > certification path from the trust anchor to the CA are > identical. > > > > (...) > > > > The certification of different CAs with the same DN by different > CAs > > has other negative consequences in various parts of the PKI, > notably > > rendering the IssuerAndSerialNumber structure in [RFC3852] > section > > 10.2.4 ambiguous. > > > > It speaks for itself, as it applies to CRL Issuers as well. Some parts > of > > it should indeed be copied and pasted in the security considerations > > section > > of the current proposed draft. > > > > When the certification path used to validate the target certificate is > > also used to validate the CRL Issuer certificate, then there is no > > security > > issue: this should be said in the security considerations section. > > > > What about the other cases ? The other cases belong to the category of > > indirect CRLs. Depending on the local validation policy checks done or > not > > done there may be security issues. > > > > Denis > > > > > Russ > > > > > > At 02:59 AM 5/10/2005, Denis Pinkas wrote: > > > > > >> Russ, > > >> > > >> Your statement below is correct, but does not answer to any of my > > >> questions/issues. In particular, the last one. I am still > awaiting > > >> your responses. > > >> > > >> Denis > > >> > > >>> Denis: > > >>> RFC 3280 does not tell an implementor how for locate > certificates > > for > > >>> any certification path construction. There are several > extensions > > >>> that provide pointers that may help an implementation, but other > > >>> approaches to obtaining the same certificates are always > permitted. > > >>> I would fully expect an implementation to check any local cache > > >>> before accessing a repository. > > >>> The CRL AIA extension fits this pattern. A method for locating > a > > >>> certificate is provided, but any other mechanism for locating > the > > >>> same certificate is acceptable. > > >>> Russ > > >>> > > >>>> Stefan, > > >>>> > > >>>> I made the e-mail shorter. Your main arguments are the > following: > > >>>> > > >>>> > > > ======================================================================== > == > > >>>> > > >>>> > > >>>> [Stefan] But it has to provide a warning to something that is > > >>>> introduced > > >>>> by the standard. This standard does not introduce the concept > of > > CRL > > >>>> signature checking or CRL issuer certificate validation, so > that is > > >>>> clearly out of scope. More about that below; > > >>>> > > >>>> [Denis] See below the last answer and also my arguments in the > > >>>> soon-to-be-posted answer to Russ. > > >>>> > > >>>> > > > ======================================================================== > == > > >>>> > > >>>> > > >>>> > > >>>> > > RFC 3280 [PKIX1] specifies the validation of certification > > paths. > > >>>> > > One aspect involves the determination that a certificate > has > > not > > >>>> been > > >>>> > > revoked, and one revocation checking mechanism is the > > Certificate > > >>>> > > Revocation List (CRL). CRL validation is also specified in > RFC > > >>>> 3280, > > >>>> > > >>>> > I would love this last sentence to be true but the reality is > > that: > > >>>> > "CRL validation is NOT specified in RFC 3280". :-( > > >>>> > > >>>> [Stefan] In fact it is. > > >>>> > > >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: > > >>>> > > >>>> (f) Obtain and validate the certification path for the > complete > > CRL > > >>>> issuer. If a key usage extension is present in the CRL > issuer's > > >>>> certificate, verify that the cRLSign bit is set. > > >>>> > > >>>> (g) Validate the signature on the complete CRL using the > public > > key > > >>>> validated in step (f). > > >>>> > > >>>> [Denis] The text does not say how to obtain and validate the > > >>>> certification path for the complete (???) CRL issuer. The text > is > > >>>> not clear enough so that two implementors only looking at this > > >>>> sentence will provide interoperable implementations. > > >>>> > > >>>> > > > ======================================================================== > == > > >>>> > > >>>> > > >>>> [Stefan] It is my hope that the provided responses here can > help > > >>>> convince you to change your mind about that. If it doesn't I > still > > >>>> argue > > >>>> that the place to specify requirements and security > considerations > > for > > >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL > > draft. > > >>>> > > >>>> [Denis] I can agree with your last sentence, ... which means > that > > it > > >>>> should not be in the main body of the document. In the security > > >>>> considerations section, text is free and we shall at the very > > >>>> minimum warn implementers and we should provide some guidance. > When > > >>>> the same certification path (i.e. the path used to validate the > > >>>> target certificate) is used, then there is no security issue: > this > > >>>> should be said. For all other cases, there MAY be problems: > this > > >>>> should also be said. It is as simple as that. > > >>>> > > >>>> Denis > > >>> > > >> > > >> > > > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 12 10:57:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00538 for ; Thu, 12 May 2005 10:57:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CE6QOr085122; Thu, 12 May 2005 07:06:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CE6QPc085121; Thu, 12 May 2005 07:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CE6OOM085113 for ; Thu, 12 May 2005 07:06:24 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 27496 invoked by uid 0); 12 May 2005 14:05:10 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.98.205) by woodstock.binhost.com with SMTP; 12 May 2005 14:05:10 -0000 Message-Id: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 10:05:10 -0400 To: "Simon McMahon" From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since we are working on an update to RFC 3280, I propose the following revisions to these descritions. The keyEncipherment bit is asserted when the subject public key is used for key transport. For example, when an RSA key is to be used for key management by encrypting a symmetric content-encryption key, then this bit shall asserted. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Russ At 10:14 PM 5/11/2005, Simon McMahon wrote: >Russ, > >They were calling an 'encrypt' function to encrypt XML data and they gave >it an RSA key (the cert actually) to do it. Of course it internally made >an AES key but they never saw it until the interoperability issue made >them look. From what they saw at the level they were looking the >interpretation was reasonable. When the transport key is well hidden and >simply part of the protocol then it looks just like RSA is encrypting big >slabs of data. If you know that RSA is bound by the modulus size then you >know what is really happening but not all users of PKI know RSA so well. >Why should they? > >Couple this interpretation of key-usage with a dubious decision to reject >encryption requests with certs that dont have key-usage='data >encipherment' and you have an interoperability problem. I say "dubious" >because it is a public key so you cannot enforce usage policy anyway. The >CA could set both flags to fix it, which by the way was the vendors >preferred solution, but its not my CA or their CA and the CA doesn't do >that. Why should they? > >This reference, in my opinion, allows the ambiguous interpretation: > > The keyEncipherment bit is asserted when the subject public key is > > used for key transport. For example, when an RSA key is to be > > used for key management, then this bit shall asserted. > > > > The dataEncipherment bit is asserted when the subject public key > > is used for enciphering user data, other than cryptographic keys. > >In this case the public key is clearly "intended" to be used to encrypt >the XML data but it just doesn't do it directly because it cant. The term >"key management" also has associations with more basic and explicit key >management operations like installing trusted root certs or secure >installation of shared secret keys etc. In this case it is much less >obvious that key management is happening because the key is bundled with >the data. It looks just like the public key is encrypting the data. > >In my opinion there are 3 cases presented as 2 in the RFC. >1. RSA encrypts data - hardly ever used. >2. RSA implicitly encrypts keys so it can really encrypt bulk data - >common usage. >3. RSA explicitly encrypts keys for explicit key management functions - >common usage. >The current bits separate 1 from 2/3 yet people make the interpretation >that they split the more common 2 from 3 assuming 1 and 2 are the same >thing. Knowledge of RSA is required to know that 1 and 2 are different. > >Peter's comment "This bit MUST NOT be set when the intention is to >encipher intermediate cryptographic keys rather than raw user data" is >most relevant in my case. Does PKIX support this clarification? > >In my opinion this problem will not entirely go away by clarifying the >standard because most people dont read it before they implement something. >The two bits are there and as long as they are both there then the mistake >will be made by busy developers. Unenforceable key-usage policy, to >"public" keys, will also continue to be implemented. People will come >looking for clarification once they have an interoperability issue but by >then it is often too late - the issue usually gets decided by who has the >biggest corporate balls. In this case it wasn't too late so thanks for the >assistance. > >If I could recommend a change to the standard then I would suggest >dropping one of the encryption bits and just have a single key-usage = >"encryption". Give it the value the same as "key-encryption" since this is >the common usage. > >Thanks, > >Simon McMahon. > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > >>> Russ Housley 05/12/05 01:06am >>> >Simon: > >If they are encrypting the XML data directly with the RSA key (which is >very unlikely), then they are correct. > >The traditional way to handle this is to generate a random >content-encryption key (CEK) and then encrypt the XML data with a >symmetric algorithm using the CEK. The CEK is encrypted with the RSA key >from the certificate. Thus, the RSA key is really being used to encrypt only >symmetric keys. > >Russ > > At 08:33 PM 5/10/2005, Simon McMahon wrote: > > >Hi, > > > >I have had a recent interoperability issue with a application vendor > that >didn't like the key-usage attributes in a cert from a CA vendor's > >certificate. Signing certs work fine, it was an encryption cert that failed. > > > >CA sets key-usage = "key encipherment". > >Application wants to encrypt some XML data so looks for key-usage = "data > >encipherment". Reason - because XML is data, not a key. > > > >I believe the application vendor is wrong and I explained that the RSA > key >actually encrypts an AES key so it doesn't directly encrypt the data > but >they want an official "pkix" ruling based on the standard so can > someone >please refer me to a statement in the standard that clears this up. > > > >Thanks, > > > >Simon McMahon. > > > > > > > >Simon McMahon > > > >Work: (07) 31311420 > >Mobile: (043) 2294180 > > > > > > > >Simon McMahon > > > >Work: (07) 31311420 > >Mobile: (043) 2294180 > > > > > > > > > >************************************************************************* > ********** > >This email, including any attachments sent with it, is confidential and > >for the sole use of the intended recipient(s). This confidentiality is > >not waived or lost, if you receive it and you are not the intended > >recipient(s), or if it is transmitted/received in error. > > > >Any unauthorised use, alteration, disclosure, distribution or review of > >this email is prohibited. It may be subject to a statutory duty of > >confidentiality if it relates to health service matters. > > > >If you are not the intended recipient(s), or if you have received this > >email in error, you are asked to immediately notify the sender by > >telephone or by return email. You should also delete this email and > >destroy any hard copies produced. > >************************************************************************* > ********** > > > >*********************************************************************************** >This email, including any attachments sent with it, is confidential and >for the sole use of the intended recipient(s). This confidentiality is >not waived or lost, if you receive it and you are not the intended >recipient(s), or if it is transmitted/received in error. > >Any unauthorised use, alteration, disclosure, distribution or review of >this email is prohibited. It may be subject to a statutory duty of >confidentiality if it relates to health service matters. > >If you are not the intended recipient(s), or if you have received this >email in error, you are asked to immediately notify the sender by >telephone or by return email. You should also delete this email and >destroy any hard copies produced. >*********************************************************************************** From owner-ietf-pkix@mail.imc.org Thu May 12 11:37:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04953 for ; Thu, 12 May 2005 11:37:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CEhiOJ088531; Thu, 12 May 2005 07:43:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CEhiqh088530; Thu, 12 May 2005 07:43:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CEhh4Y088498 for ; Thu, 12 May 2005 07:43:43 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA46150; Thu, 12 May 2005 16:58:29 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051216433132:1144 ; Thu, 12 May 2005 16:43:31 +0200 Message-ID: <42836BCC.5000804@bull.net> Date: Thu, 12 May 2005 16:44:28 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 16:43:31, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 16:43:33, Serialize complete at 12/05/2005 16:43:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, > Since we are working on an update to RFC 3280, I propose the following > revisions to these descritions. > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management by encrypting a symmetric content-encryption > key, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate symmetric cipher. Thank you for this strawman proposal. I would rather propose: The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e. for key transport. For example, this bit shall be set when a public RSA key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate key. Reasons: a) "Key transport" is not explicit enough. The purpose is to encipher either a private key or a secret key. b) The example is not clear enough: "RSA key" can be a private key or a public key, hence why "public" has been added. c) The key that is communicated is a decryption key rather than an encryption key, hence why "content-encryption" has been changed into "content-decryption". d) The example has been extended to cover the case of an asymmetric cipher as well. e) In the last statement, the intermediate key would not necessarily be a symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has been replaced by "key'. Note that the current text from X.509 is: c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport; d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above; Denis > Russ > > At 10:14 PM 5/11/2005, Simon McMahon wrote: > >> Russ, >> >> They were calling an 'encrypt' function to encrypt XML data and they >> gave it an RSA key (the cert actually) to do it. Of course it >> internally made an AES key but they never saw it until the >> interoperability issue made them look. From what they saw at the level >> they were looking the interpretation was reasonable. When the >> transport key is well hidden and simply part of the protocol then it >> looks just like RSA is encrypting big slabs of data. If you know that >> RSA is bound by the modulus size then you know what is really >> happening but not all users of PKI know RSA so well. Why should they? >> >> Couple this interpretation of key-usage with a dubious decision to >> reject encryption requests with certs that dont have key-usage='data >> encipherment' and you have an interoperability problem. I say >> "dubious" because it is a public key so you cannot enforce usage >> policy anyway. The CA could set both flags to fix it, which by the way >> was the vendors preferred solution, but its not my CA or their CA and >> the CA doesn't do that. Why should they? >> >> This reference, in my opinion, allows the ambiguous interpretation: >> > The keyEncipherment bit is asserted when the subject public key is >> > used for key transport. For example, when an RSA key is to be >> > used for key management, then this bit shall asserted. >> > >> > The dataEncipherment bit is asserted when the subject public key >> > is used for enciphering user data, other than cryptographic keys. >> >> In this case the public key is clearly "intended" to be used to >> encrypt the XML data but it just doesn't do it directly because it >> cant. The term "key management" also has associations with more basic >> and explicit key management operations like installing trusted root >> certs or secure installation of shared secret keys etc. In this case >> it is much less obvious that key management is happening because the >> key is bundled with the data. It looks just like the public key is >> encrypting the data. >> >> In my opinion there are 3 cases presented as 2 in the RFC. >> 1. RSA encrypts data - hardly ever used. >> 2. RSA implicitly encrypts keys so it can really encrypt bulk data - >> common usage. >> 3. RSA explicitly encrypts keys for explicit key management functions >> - common usage. >> The current bits separate 1 from 2/3 yet people make the >> interpretation that they split the more common 2 from 3 assuming 1 and >> 2 are the same thing. Knowledge of RSA is required to know that 1 and >> 2 are different. >> >> Peter's comment "This bit MUST NOT be set when the intention is to >> encipher intermediate cryptographic keys rather than raw user data" is >> most relevant in my case. Does PKIX support this clarification? >> >> In my opinion this problem will not entirely go away by clarifying the >> standard because most people dont read it before they implement >> something. The two bits are there and as long as they are both there >> then the mistake will be made by busy developers. Unenforceable >> key-usage policy, to "public" keys, will also continue to be >> implemented. People will come looking for clarification once they have >> an interoperability issue but by then it is often too late - the issue >> usually gets decided by who has the biggest corporate balls. In this >> case it wasn't too late so thanks for the assistance. >> >> If I could recommend a change to the standard then I would suggest >> dropping one of the encryption bits and just have a single key-usage = >> "encryption". Give it the value the same as "key-encryption" since >> this is the common usage. >> >> Thanks, >> >> Simon McMahon. >> >> >> Simon McMahon >> >> Work: (07) 31311420 >> Mobile: (043) 2294180 >> >> >> >>> Russ Housley 05/12/05 01:06am >>> >> Simon: >> >> If they are encrypting the XML data directly with the RSA key (which is >> very unlikely), then they are correct. >> >> The traditional way to handle this is to generate a random >> content-encryption key (CEK) and then encrypt the XML data with a >> symmetric algorithm using the CEK. The CEK is encrypted with the RSA >> key from the certificate. Thus, the RSA key is really being used to >> encrypt only >> symmetric keys. >> >> Russ >> >> At 08:33 PM 5/10/2005, Simon McMahon wrote: >> >> >Hi, >> > >> >I have had a recent interoperability issue with a application vendor >> that >didn't like the key-usage attributes in a cert from a CA vendor's >> >certificate. Signing certs work fine, it was an encryption cert that >> failed. >> > >> >CA sets key-usage = "key encipherment". >> >Application wants to encrypt some XML data so looks for key-usage = >> "data >> >encipherment". Reason - because XML is data, not a key. >> > >> >I believe the application vendor is wrong and I explained that the >> RSA key >actually encrypts an AES key so it doesn't directly encrypt >> the data but >they want an official "pkix" ruling based on the >> standard so can someone >please refer me to a statement in the >> standard that clears this up. >> > >> >Thanks, >> > >> >Simon McMahon. >> > >> > >> > >> >Simon McMahon >> > >> >Work: (07) 31311420 >> >Mobile: (043) 2294180 >> > >> > >> > >> >Simon McMahon >> > >> >Work: (07) 31311420 >> >Mobile: (043) 2294180 >> > >> > >> > >> > >> >************************************************************************* >> ********** >> >This email, including any attachments sent with it, is confidential and >> >for the sole use of the intended recipient(s). This confidentiality is >> >not waived or lost, if you receive it and you are not the intended >> >recipient(s), or if it is transmitted/received in error. >> > >> >Any unauthorised use, alteration, disclosure, distribution or review of >> >this email is prohibited. It may be subject to a statutory duty of >> >confidentiality if it relates to health service matters. >> > >> >If you are not the intended recipient(s), or if you have received this >> >email in error, you are asked to immediately notify the sender by >> >telephone or by return email. You should also delete this email and >> >destroy any hard copies produced. >> >************************************************************************* >> ********** >> >> >> >> *********************************************************************************** >> >> This email, including any attachments sent with it, is confidential >> and for the sole use of the intended recipient(s). This >> confidentiality is not waived or lost, if you receive it and you are >> not the intended recipient(s), or if it is transmitted/received in error. >> >> Any unauthorised use, alteration, disclosure, distribution or review >> of this email is prohibited. It may be subject to a statutory duty of >> confidentiality if it relates to health service matters. >> >> If you are not the intended recipient(s), or if you have received this >> email in error, you are asked to immediately notify the sender by >> telephone or by return email. You should also delete this email and >> destroy any hard copies produced. >> *********************************************************************************** >> > > > From owner-ietf-pkix@mail.imc.org Thu May 12 11:41:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05270 for ; Thu, 12 May 2005 11:41:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CErMlN089201; Thu, 12 May 2005 07:53:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CErMKV089200; Thu, 12 May 2005 07:53:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CErLIp089194 for ; Thu, 12 May 2005 07:53:21 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8868 invoked by uid 0); 12 May 2005 14:53:18 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.148.50) by woodstock.binhost.com with SMTP; 12 May 2005 14:53:18 -0000 Message-Id: <6.2.1.2.2.20050512104257.0608b450@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 10:53:06 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: pkix In-Reply-To: <42832153.8000802@bull.net> References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> <42832153.8000802@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: Finally! We now uncover the actual point of disagreement. You say: The same trust anchor is not a *sufficient* condition. The same node in the certification tree is the necessary condition. This implies, of course, the same trust anchor, but since two CRL issuers located at different nodes (i.e. certified by different CAS) might have the same CRL issuer name, this condition is insufficient to solve the issue. When policies, procedures, and practices are followed, I do not believe that two different CRL issuers that are subordinate to the same trust anchor can legitimately have the same name. As I said yesterday, I am willing to add text to the Security Considerations section to state this. I am even willing to state that certificate users should not include trust anchors that do not have policies, procedures, and practices that would prevent such name collisions. Russ From owner-ietf-pkix@mail.imc.org Thu May 12 11:54:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06303 for ; Thu, 12 May 2005 11:54:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CF1P17089711; Thu, 12 May 2005 08:01:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CF1PsU089710; Thu, 12 May 2005 08:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CF1NrA089704 for ; Thu, 12 May 2005 08:01:24 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 20127 invoked by uid 0); 12 May 2005 15:01:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.148.50) by woodstock.binhost.com with SMTP; 12 May 2005 15:01:19 -0000 Message-Id: <6.2.1.2.2.20050512105428.060f0210@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 10:56:46 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: ietf-pkix@imc.org In-Reply-To: <42832509.5020001@bull.net> References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> <42832509.5020001@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: > >>> You say that it is not clear what validation policy needs to be used, > >>> but this is completely irrelevant to the discussion of the CRL AIA > >>> extension. This extension aid in certification path construction, > >>> not the validation of the path once it is constructed. > > >> Not exactly, it could "help" finding a wrong path ! > > > Not likely. The signer of the CRL is providing a pointer to their own > > certificate. Path construction to locate a parent of that certificate > > through a complex PKI might include paths that are acceptable and paths > > that are unacceptable, but the certificate that contains the public key > > needed to validate the signature on the CRL is clearly needed. > >The problem is to know if a CRL that has been fetched "somewhere" is >adequate for the target certificate. It is not to validate a CRL that has >been fetched "somewhere". You continue to miss the whole point of this document. The certificate user has already obtained the CRL, but needs the certificate of the CRL issuer in order to validate the signature on the CRL. That is the scope of this document. You keep trying to make it something else. Russ From owner-ietf-pkix@mail.imc.org Thu May 12 12:05:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06914 for ; Thu, 12 May 2005 12:05:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CFIHuT091797; Thu, 12 May 2005 08:18:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CFIH1t091796; Thu, 12 May 2005 08:18:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CFIG7L091774 for ; Thu, 12 May 2005 08:18:16 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 4947E100B9 for ; Thu, 12 May 2005 11:18:10 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06890-67 for ; Thu, 12 May 2005 11:17:55 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 7A2BB10084 for ; Thu, 12 May 2005 11:17:55 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005051211173420-15101 ; Thu, 12 May 2005 11:17:34 -0400 Date: Thu, 12 May 2005 11:17:55 -0400 From: Sam Roberts To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Message-ID: <20050512151755.GA7289@certicom.com> References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> Mime-Version: 1.0 In-Reply-To: <42836BCC.5000804@bull.net> User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/12/2005 11:17:34 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/12/2005 11:17:34 AM, Serialize complete at 05/12/2005 11:17:34 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Denis Pinkas , on Thu, May 12, 2005 at 04:44:28PM +0200: > > Russ, > > >Since we are working on an update to RFC 3280, I propose the following > >revisions to these descritions. > > > The keyEncipherment bit is asserted when the subject public key is > > used for key transport. For example, when an RSA key is to be > > used for key management by encrypting a symmetric content-encryption > > key, then this bit shall asserted. > > > > The dataEncipherment bit is asserted when the subject public key > > is used for directly enciphering raw user data without the use of > > an intermediate symmetric cipher. > > Thank you for this strawman proposal. I would rather propose: > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e. for key transport. > For example, this bit shall be set when a public RSA key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. Hi Denis, I think this text has the same problem as the current. In other words, somebody might read it and think "I'm not encrypting a key, I'm encrypting email, and I'm "transporting" a word document, not a key, so this isn't the bit I should look for". This is what happens now. I can't think of appropriate wording, but if the goal is to make it clear to non-security experts so the bit is used consistently, a little bit more explanation is needed. > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate key. This is clear, I think. Cheers, Sam > Reasons: > > a) "Key transport" is not explicit enough. The purpose is to encipher > either a private key or a secret key. > > b) The example is not clear enough: "RSA key" can be a private key or a > public key, hence why "public" has been added. > > c) The key that is communicated is a decryption key rather than an > encryption key, hence why "content-encryption" has been changed into > "content-decryption". > > d) The example has been extended to cover the case of an asymmetric cipher > as well. > > e) In the last statement, the intermediate key would not necessarily be a > symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has > been replaced by "key'. > > Note that the current text from X.509 is: > > c) keyEncipherment: for enciphering keys or other security information, > e.g. for key transport; > > d) dataEncipherment: for enciphering user data, but not keys or other > security information as in c) above; > > Denis > > >Russ > > > >At 10:14 PM 5/11/2005, Simon McMahon wrote: > > > >>Russ, > >> > >>They were calling an 'encrypt' function to encrypt XML data and they > >>gave it an RSA key (the cert actually) to do it. Of course it > >>internally made an AES key but they never saw it until the > >>interoperability issue made them look. From what they saw at the level > >>they were looking the interpretation was reasonable. When the > >>transport key is well hidden and simply part of the protocol then it > >>looks just like RSA is encrypting big slabs of data. If you know that > >>RSA is bound by the modulus size then you know what is really > >>happening but not all users of PKI know RSA so well. Why should they? > >> > >>Couple this interpretation of key-usage with a dubious decision to > >>reject encryption requests with certs that dont have key-usage='data > >>encipherment' and you have an interoperability problem. I say > >>"dubious" because it is a public key so you cannot enforce usage > >>policy anyway. The CA could set both flags to fix it, which by the way > >>was the vendors preferred solution, but its not my CA or their CA and > >>the CA doesn't do that. Why should they? > >> > >>This reference, in my opinion, allows the ambiguous interpretation: > >>> The keyEncipherment bit is asserted when the subject public key is > >>> used for key transport. For example, when an RSA key is to be > >>> used for key management, then this bit shall asserted. > >>> > >>> The dataEncipherment bit is asserted when the subject public key > >>> is used for enciphering user data, other than cryptographic keys. > >> > >>In this case the public key is clearly "intended" to be used to > >>encrypt the XML data but it just doesn't do it directly because it > >>cant. The term "key management" also has associations with more basic > >>and explicit key management operations like installing trusted root > >>certs or secure installation of shared secret keys etc. In this case > >>it is much less obvious that key management is happening because the > >>key is bundled with the data. It looks just like the public key is > >>encrypting the data. > >> > >>In my opinion there are 3 cases presented as 2 in the RFC. > >>1. RSA encrypts data - hardly ever used. > >>2. RSA implicitly encrypts keys so it can really encrypt bulk data - > >>common usage. > >>3. RSA explicitly encrypts keys for explicit key management functions > >>- common usage. > >>The current bits separate 1 from 2/3 yet people make the > >>interpretation that they split the more common 2 from 3 assuming 1 and > >>2 are the same thing. Knowledge of RSA is required to know that 1 and > >>2 are different. > >> > >>Peter's comment "This bit MUST NOT be set when the intention is to > >>encipher intermediate cryptographic keys rather than raw user data" is > >>most relevant in my case. Does PKIX support this clarification? > >> > >>In my opinion this problem will not entirely go away by clarifying the > >>standard because most people dont read it before they implement > >>something. The two bits are there and as long as they are both there > >>then the mistake will be made by busy developers. Unenforceable > >>key-usage policy, to "public" keys, will also continue to be > >>implemented. People will come looking for clarification once they have > >>an interoperability issue but by then it is often too late - the issue > >>usually gets decided by who has the biggest corporate balls. In this > >>case it wasn't too late so thanks for the assistance. > >> > >>If I could recommend a change to the standard then I would suggest > >>dropping one of the encryption bits and just have a single key-usage = > >>"encryption". Give it the value the same as "key-encryption" since > >>this is the common usage. > >> > >>Thanks, > >> > >>Simon McMahon. > >> > >> > >>Simon McMahon > >> > >>Work: (07) 31311420 > >>Mobile: (043) 2294180 > >> > >> > >>>>> Russ Housley 05/12/05 01:06am >>> > >>Simon: > >> > >>If they are encrypting the XML data directly with the RSA key (which is > >>very unlikely), then they are correct. > >> > >>The traditional way to handle this is to generate a random > >>content-encryption key (CEK) and then encrypt the XML data with a > >>symmetric algorithm using the CEK. The CEK is encrypted with the RSA > >>key from the certificate. Thus, the RSA key is really being used to > >>encrypt only > >>symmetric keys. > >> > >>Russ > >> > >> At 08:33 PM 5/10/2005, Simon McMahon wrote: > >> > >>>Hi, > >>> > >>>I have had a recent interoperability issue with a application vendor > >>that >didn't like the key-usage attributes in a cert from a CA vendor's > >>>certificate. Signing certs work fine, it was an encryption cert that > >>failed. > >>> > >>>CA sets key-usage = "key encipherment". > >>>Application wants to encrypt some XML data so looks for key-usage = > >>"data > >>>encipherment". Reason - because XML is data, not a key. > >>> > >>>I believe the application vendor is wrong and I explained that the > >>RSA key >actually encrypts an AES key so it doesn't directly encrypt > >>the data but >they want an official "pkix" ruling based on the > >>standard so can someone >please refer me to a statement in the > >>standard that clears this up. > >>> > >>>Thanks, > >>> > >>>Simon McMahon. > >>> > >>> > >>> > >>>Simon McMahon > >>> > >>>Work: (07) 31311420 > >>>Mobile: (043) 2294180 > >>> > >>> > >>> > >>>Simon McMahon > >>> > >>>Work: (07) 31311420 > >>>Mobile: (043) 2294180 > >>> > >>> > >>> > >>> > >>>************************************************************************* > >>********** > >>>This email, including any attachments sent with it, is confidential and > >>>for the sole use of the intended recipient(s). This confidentiality is > >>>not waived or lost, if you receive it and you are not the intended > >>>recipient(s), or if it is transmitted/received in error. > >>> > >>>Any unauthorised use, alteration, disclosure, distribution or review of > >>>this email is prohibited. It may be subject to a statutory duty of > >>>confidentiality if it relates to health service matters. > >>> > >>>If you are not the intended recipient(s), or if you have received this > >>>email in error, you are asked to immediately notify the sender by > >>>telephone or by return email. You should also delete this email and > >>>destroy any hard copies produced. > >>>************************************************************************* > >>********** > >> > >> > >> > >>*********************************************************************************** > >> > >>This email, including any attachments sent with it, is confidential > >>and for the sole use of the intended recipient(s). This > >>confidentiality is not waived or lost, if you receive it and you are > >>not the intended recipient(s), or if it is transmitted/received in error. > >> > >>Any unauthorised use, alteration, disclosure, distribution or review > >>of this email is prohibited. It may be subject to a statutory duty of > >>confidentiality if it relates to health service matters. > >> > >>If you are not the intended recipient(s), or if you have received this > >>email in error, you are asked to immediately notify the sender by > >>telephone or by return email. You should also delete this email and > >>destroy any hard copies produced. > >>*********************************************************************************** > >> > > > > > > > -- http://www.certicom.com From owner-ietf-pkix@mail.imc.org Thu May 12 12:24:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08700 for ; Thu, 12 May 2005 12:24:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CFZaal093343; Thu, 12 May 2005 08:35:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CFZaXL093342; Thu, 12 May 2005 08:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CFZaCM093335 for ; Thu, 12 May 2005 08:35:36 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 20476 invoked by uid 0); 12 May 2005 15:35:32 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.148.50) by woodstock.binhost.com with SMTP; 12 May 2005 15:35:32 -0000 Message-Id: <6.2.1.2.2.20050512112059.0613bc20@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 11:22:04 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <42836BCC.5000804@bull.net> References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: Thanks. I think you suggestion improves the text. Russ At 10:44 AM 5/12/2005, Denis Pinkas wrote: >Russ, > >>Since we are working on an update to RFC 3280, I propose the following >>revisions to these descritions. > >> The keyEncipherment bit is asserted when the subject public key is >> used for key transport. For example, when an RSA key is to be >> used for key management by encrypting a symmetric content-encryption >> key, then this bit shall asserted. >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate symmetric cipher. > >Thank you for this strawman proposal. I would rather propose: > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e. for key transport. > For example, this bit shall be set when a public RSA key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate key. > >Reasons: > >a) "Key transport" is not explicit enough. The purpose is to encipher >either a private key or a secret key. > >b) The example is not clear enough: "RSA key" can be a private key or a >public key, hence why "public" has been added. > >c) The key that is communicated is a decryption key rather than an >encryption key, hence why "content-encryption" has been changed into >"content-decryption". > >d) The example has been extended to cover the case of an asymmetric cipher >as well. > >e) In the last statement, the intermediate key would not necessarily be a >symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" >has been replaced by "key'. > >Note that the current text from X.509 is: > > c) keyEncipherment: for enciphering keys or other security information, > e.g. for key transport; > > d) dataEncipherment: for enciphering user data, but not keys or other > security information as in c) above; > >Denis From owner-ietf-pkix@mail.imc.org Thu May 12 13:16:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12891 for ; Thu, 12 May 2005 13:16:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CGPwoW097750; Thu, 12 May 2005 09:25:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CGPwns097749; Thu, 12 May 2005 09:25:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from lxme02.infocamere.it (lxme02.infocamere.it [80.82.0.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CGPv2C097736 for ; Thu, 12 May 2005 09:25:58 -0700 (PDT) (envelope-from alfredo.esposito@infocamere.it) Received: from lxm02.icnet (lxm02.icnet [1.5.0.11]) by lxme02.infocamere.it (8.12.11/8.12.11) with ESMTP id j4CGPfE6019340; Thu, 12 May 2005 18:25:42 +0200 Received: from lxm02.icnet (localhost.localdomain [127.0.0.1]) by lxm02.icnet (8.12.8/8.12.8) with ESMTP id j4CGPe1v004055; Thu, 12 May 2005 18:25:41 +0200 Received: from [1.71.4.82] (IC2300323.ic.intra.infocamere.it [1.71.4.82]) (authenticated bits=0) by lxm02.icnet (8.12.8/8.12.8) with ESMTP id j4CGPaa9003962; Thu, 12 May 2005 18:25:40 +0200 Message-ID: <42838382.8060504@infocamere.it> Date: Thu, 12 May 2005 18:25:38 +0200 From: Dino Esposito User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Roberts CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> <20050512151755.GA7289@certicom.com> In-Reply-To: <20050512151755.GA7289@certicom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (lxme02.infocamere.it [80.82.0.240]); Thu, 12 May 2005 18:25:42 +0200 (CEST) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit IMO, the typical reader of a RFC is a technician. Especially for a RFC full of PKI jargon. If we wanted to write for a layman reader, we should write an encyclopedia I think the Pinkas' proposal is quite clear. Dino Esposito Sam Roberts wrote: >Wrote Denis Pinkas , on Thu, May 12, 2005 at 04:44:28PM +0200: > > >>Russ, >> >> >> >>>Since we are working on an update to RFC 3280, I propose the following >>>revisions to these descritions. >>> >>> >>> The keyEncipherment bit is asserted when the subject public key is >>> used for key transport. For example, when an RSA key is to be >>> used for key management by encrypting a symmetric content-encryption >>> key, then this bit shall asserted. >>> >>> The dataEncipherment bit is asserted when the subject public key >>> is used for directly enciphering raw user data without the use of >>> an intermediate symmetric cipher. >>> >>> >>Thank you for this strawman proposal. I would rather propose: >> >> The keyEncipherment bit is asserted when the subject public key is >> used for enciphering private or secret keys, i.e. for key transport. >> For example, this bit shall be set when a public RSA key is to be >> used for encrypting a symmetric content-decryption key or an >> asymmetric private key. >> >> > >Hi Denis, > >I think this text has the same problem as the current. In other words, >somebody might read it and think "I'm not encrypting a key, I'm >encrypting email, and I'm "transporting" a word document, not a key, so >this isn't the bit I should look for". This is what happens now. > >I can't think of appropriate wording, but if the goal is to make it >clear to non-security experts so the bit is used consistently, a little >bit more explanation is needed. > > > >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate key. >> >> > >This is clear, I think. > >Cheers, >Sam > > > >>Reasons: >> >>a) "Key transport" is not explicit enough. The purpose is to encipher >>either a private key or a secret key. >> >>b) The example is not clear enough: "RSA key" can be a private key or a >>public key, hence why "public" has been added. >> >>c) The key that is communicated is a decryption key rather than an >>encryption key, hence why "content-encryption" has been changed into >>"content-decryption". >> >>d) The example has been extended to cover the case of an asymmetric cipher >>as well. >> >>e) In the last statement, the intermediate key would not necessarily be a >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has >>been replaced by "key'. >> >>Note that the current text from X.509 is: >> >> c) keyEncipherment: for enciphering keys or other security information, >> e.g. for key transport; >> >> d) dataEncipherment: for enciphering user data, but not keys or other >> security information as in c) above; >> >>Denis >> >> >> >>>Russ >>> >>>At 10:14 PM 5/11/2005, Simon McMahon wrote: >>> >>> >>> >>>>Russ, >>>> >>>>They were calling an 'encrypt' function to encrypt XML data and they >>>>gave it an RSA key (the cert actually) to do it. Of course it >>>>internally made an AES key but they never saw it until the >>>>interoperability issue made them look. From what they saw at the level >>>>they were looking the interpretation was reasonable. When the >>>>transport key is well hidden and simply part of the protocol then it >>>>looks just like RSA is encrypting big slabs of data. If you know that >>>>RSA is bound by the modulus size then you know what is really >>>>happening but not all users of PKI know RSA so well. Why should they? >>>> >>>>Couple this interpretation of key-usage with a dubious decision to >>>>reject encryption requests with certs that dont have key-usage='data >>>>encipherment' and you have an interoperability problem. I say >>>>"dubious" because it is a public key so you cannot enforce usage >>>>policy anyway. The CA could set both flags to fix it, which by the way >>>>was the vendors preferred solution, but its not my CA or their CA and >>>>the CA doesn't do that. Why should they? >>>> >>>>This reference, in my opinion, allows the ambiguous interpretation: >>>> >>>> >>>>> The keyEncipherment bit is asserted when the subject public key is >>>>> used for key transport. For example, when an RSA key is to be >>>>> used for key management, then this bit shall asserted. >>>>> >>>>> The dataEncipherment bit is asserted when the subject public key >>>>> is used for enciphering user data, other than cryptographic keys. >>>>> >>>>> >>>>In this case the public key is clearly "intended" to be used to >>>>encrypt the XML data but it just doesn't do it directly because it >>>>cant. The term "key management" also has associations with more basic >>>>and explicit key management operations like installing trusted root >>>>certs or secure installation of shared secret keys etc. In this case >>>>it is much less obvious that key management is happening because the >>>>key is bundled with the data. It looks just like the public key is >>>>encrypting the data. >>>> >>>>In my opinion there are 3 cases presented as 2 in the RFC. >>>>1. RSA encrypts data - hardly ever used. >>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data - >>>>common usage. >>>>3. RSA explicitly encrypts keys for explicit key management functions >>>>- common usage. >>>>The current bits separate 1 from 2/3 yet people make the >>>>interpretation that they split the more common 2 from 3 assuming 1 and >>>>2 are the same thing. Knowledge of RSA is required to know that 1 and >>>>2 are different. >>>> >>>>Peter's comment "This bit MUST NOT be set when the intention is to >>>>encipher intermediate cryptographic keys rather than raw user data" is >>>>most relevant in my case. Does PKIX support this clarification? >>>> >>>>In my opinion this problem will not entirely go away by clarifying the >>>>standard because most people dont read it before they implement >>>>something. The two bits are there and as long as they are both there >>>>then the mistake will be made by busy developers. Unenforceable >>>>key-usage policy, to "public" keys, will also continue to be >>>>implemented. People will come looking for clarification once they have >>>>an interoperability issue but by then it is often too late - the issue >>>>usually gets decided by who has the biggest corporate balls. In this >>>>case it wasn't too late so thanks for the assistance. >>>> >>>>If I could recommend a change to the standard then I would suggest >>>>dropping one of the encryption bits and just have a single key-usage = >>>>"encryption". Give it the value the same as "key-encryption" since >>>>this is the common usage. >>>> >>>>Thanks, >>>> >>>>Simon McMahon. >>>> >>>> >>>>Simon McMahon >>>> >>>>Work: (07) 31311420 >>>>Mobile: (043) 2294180 >>>> >>>> >>>> >>>> >>>>>>>Russ Housley 05/12/05 01:06am >>> >>>>>>> >>>>>>> >>>>Simon: >>>> >>>>If they are encrypting the XML data directly with the RSA key (which is >>>>very unlikely), then they are correct. >>>> >>>>The traditional way to handle this is to generate a random >>>>content-encryption key (CEK) and then encrypt the XML data with a >>>>symmetric algorithm using the CEK. The CEK is encrypted with the RSA >>>>key from the certificate. Thus, the RSA key is really being used to >>>>encrypt only >>>>symmetric keys. >>>> >>>>Russ >>>> >>>> At 08:33 PM 5/10/2005, Simon McMahon wrote: >>>> >>>> >>>> >>>>>Hi, >>>>> >>>>>I have had a recent interoperability issue with a application vendor >>>>> >>>>> >>>>that >didn't like the key-usage attributes in a cert from a CA vendor's >>>> >>>> >>>>>certificate. Signing certs work fine, it was an encryption cert that >>>>> >>>>> >>>>failed. >>>> >>>> >>>>>CA sets key-usage = "key encipherment". >>>>>Application wants to encrypt some XML data so looks for key-usage = >>>>> >>>>> >>>>"data >>>> >>>> >>>>>encipherment". Reason - because XML is data, not a key. >>>>> >>>>>I believe the application vendor is wrong and I explained that the >>>>> >>>>> >>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt >>>>the data but >they want an official "pkix" ruling based on the >>>>standard so can someone >please refer me to a statement in the >>>>standard that clears this up. >>>> >>>> >>>>>Thanks, >>>>> >>>>>Simon McMahon. >>>>> >>>>> >>>>> >>>>>Simon McMahon >>>>> >>>>>Work: (07) 31311420 >>>>>Mobile: (043) 2294180 >>>>> >>>>> >>>>> >>>>>Simon McMahon >>>>> >>>>>Work: (07) 31311420 >>>>>Mobile: (043) 2294180 >>>>> >>>>> >>>>> >>>>> >>>>>************************************************************************* >>>>> >>>>> >>>>********** >>>> >>>> >>>>>This email, including any attachments sent with it, is confidential and >>>>>for the sole use of the intended recipient(s). This confidentiality is >>>>>not waived or lost, if you receive it and you are not the intended >>>>>recipient(s), or if it is transmitted/received in error. >>>>> >>>>>Any unauthorised use, alteration, disclosure, distribution or review of >>>>>this email is prohibited. It may be subject to a statutory duty of >>>>>confidentiality if it relates to health service matters. >>>>> >>>>>If you are not the intended recipient(s), or if you have received this >>>>>email in error, you are asked to immediately notify the sender by >>>>>telephone or by return email. You should also delete this email and >>>>>destroy any hard copies produced. >>>>>************************************************************************* >>>>> >>>>> >>>>********** >>>> >>>> >>>> >>>>*********************************************************************************** >>>> >>>>This email, including any attachments sent with it, is confidential >>>>and for the sole use of the intended recipient(s). This >>>>confidentiality is not waived or lost, if you receive it and you are >>>>not the intended recipient(s), or if it is transmitted/received in error. >>>> >>>>Any unauthorised use, alteration, disclosure, distribution or review >>>>of this email is prohibited. It may be subject to a statutory duty of >>>>confidentiality if it relates to health service matters. >>>> >>>>If you are not the intended recipient(s), or if you have received this >>>>email in error, you are asked to immediately notify the sender by >>>>telephone or by return email. You should also delete this email and >>>>destroy any hard copies produced. >>>>*********************************************************************************** >>>> >>>> >>>> >>> >>> >>> > > > From owner-ietf-pkix@mail.imc.org Thu May 12 14:42:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19908 for ; Thu, 12 May 2005 14:42:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHRnvY002987; Thu, 12 May 2005 10:27:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CHRnj2002986; Thu, 12 May 2005 10:27:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth09.mail.atl.earthlink.net (smtpauth09.mail.atl.earthlink.net [209.86.89.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHRm2Q002979 for ; Thu, 12 May 2005 10:27:48 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.3]) by smtpauth09.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DWHTP-0002Mf-LX; Thu, 12 May 2005 13:27:48 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Subject:Cc:Content-Type; b=RUcbwiKjPzcffmlKAsRTMD4OMqnP43KUlNfjswPsQtBajYU2SlOftPGhBDNmJmLz; Mime-Version: 1.0 Message-Id: In-Reply-To: <42834ED0.9090306@free.fr> References: <42834ED0.9090306@free.fr> Date: Thu, 12 May 2005 10:27:27 -0700 To: Jean-Marc Desperrier From: Hoyt L Kesterson II Subject: Re: Technical Corrigenda 3 to the 4th edition of X.509 Cc: pkix Content-Type: text/plain; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47874241ab66785ff6d830ffa856bbc35b2e28ca8a23ac5204d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: i apologize for the name problem This is approved text with no posibility of change except by subsequent defect report or amendment. Denis Pinkas was very active in the several ballots held on this document over the last few years as well as several other PKIX participants. Your comments would have been appreciated and considered during that period but cannot now be applied to the document that has had approval within ISO and ITU. hoyt At 14:40 +0200 5/12/05, Jean-Marc Desperrier wrote: >Hoyt L Kesterson II wrote: > >>Some you worked with the X.509 standards committee over the last few years revising the text on key usage. >> >>You can find the text of that Technical Corrigenda at: >>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf > >You should avoid using characters in the filename that are not compatible with the Microsoft OS, it makes it harder to download that file. > >From the text : >"Bits in the KeyUsage type are as follows: >[...] >c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport; >d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above; >e) keyAgreement: for use as a public key agreement key;" > >It's not yet very precise. The contentCommitment bit text got very clear, so it shows how much we can improve on those bits. > >The text by Peter is quite good, how about : > >c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport, and also data encryption that uses an intermediate symmetric cipher; >d) dataEncipherment: for directly enciphering raw user data, without the use of an intermediate symmetric cipher >e) keyAgreement: for use as a public key agreement key, for example a Diffie-Hellman protocol key; > >Shouldn't we best find a way to say that an SSL client requires at a minimum only digitalSignature, but the SSL server must have keyEncipherment ? > >Maybe we should precise : >In practice when someone wishes to send enciphered key or security information, he must check that the recipient has the keyEncipherment bit set before using his public key to encipher. For example in an SSL handshake, the client must check that the server has the keyEncipherment bit set before sending him an enciphered secret, but never needs to have that bit set in his own certificate, because the server will use his certificate only for authentification, not to send enciphered data. From owner-ietf-pkix@mail.imc.org Thu May 12 14:45:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20508 for ; Thu, 12 May 2005 14:45:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHl1dO004100; Thu, 12 May 2005 10:47:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CHl1j1004099; Thu, 12 May 2005 10:47:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CHl00c004092 for ; Thu, 12 May 2005 10:47:00 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id A63FD100B2 for ; Thu, 12 May 2005 13:46:59 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08071-20 for ; Thu, 12 May 2005 13:46:43 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 7103A10090 for ; Thu, 12 May 2005 13:46:43 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005051213462073-15485 ; Thu, 12 May 2005 13:46:20 -0400 Date: Thu, 12 May 2005 13:46:41 -0400 From: Sam Roberts To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Message-ID: <20050512174641.GA11305@certicom.com> References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> <20050512151755.GA7289@certicom.com> <42838382.8060504@infocamere.it> Mime-Version: 1.0 In-Reply-To: <42838382.8060504@infocamere.it> User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/12/2005 01:46:20 PM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/12/2005 01:46:22 PM, Serialize complete at 05/12/2005 01:46:22 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Dino Esposito , on Thu, May 12, 2005 at 06:25:38PM +0200: > IMO, the typical reader of a RFC is a technician. Especially for a RFC > full of PKI jargon. Many of the PKI flags are sufficiently succinctly subscribed that they have been interpreted differently by "technicians". Didn't an earlier poster recount an experience with a *certificate authority* that had been using the wrong flag? If an issuer of certs doesn't get it, then its not clear enough, IMHO. Making it clear enough that this conversation doesn't have to happen again would be useful. It helps none of us if people who (arguably) don't know enough about pki/crypto deploy systems wrongly, because we get asked to interop with them. My 2 cents. > If we wanted to write for a layman reader, we should write an encyclopedia Its always a balance, but when interop has failed to occur, perhaps we need to be more encyclopedic. > I think the Pinkas' proposal is quite clear. You probably understood the original text, too. Cheers, Sam > Dino Esposito > > Sam Roberts wrote: > > >Wrote Denis Pinkas , on Thu, May 12, 2005 at > >04:44:28PM +0200: > > > > > >>Russ, > >> > >> > >> > >>>Since we are working on an update to RFC 3280, I propose the following > >>>revisions to these descritions. > >>> > >>> > >>> The keyEncipherment bit is asserted when the subject public key is > >>> used for key transport. For example, when an RSA key is to be > >>> used for key management by encrypting a symmetric content-encryption > >>> key, then this bit shall asserted. > >>> > >>> The dataEncipherment bit is asserted when the subject public key > >>> is used for directly enciphering raw user data without the use of > >>> an intermediate symmetric cipher. > >>> > >>> > >>Thank you for this strawman proposal. I would rather propose: > >> > >> The keyEncipherment bit is asserted when the subject public key is > >> used for enciphering private or secret keys, i.e. for key transport. > >> For example, this bit shall be set when a public RSA key is to be > >> used for encrypting a symmetric content-decryption key or an > >> asymmetric private key. > >> > >> > > > >Hi Denis, > > > >I think this text has the same problem as the current. In other words, > >somebody might read it and think "I'm not encrypting a key, I'm > >encrypting email, and I'm "transporting" a word document, not a key, so > >this isn't the bit I should look for". This is what happens now. > > > >I can't think of appropriate wording, but if the goal is to make it > >clear to non-security experts so the bit is used consistently, a little > >bit more explanation is needed. > > > > > > > >> The dataEncipherment bit is asserted when the subject public key > >> is used for directly enciphering raw user data without the use of > >> an intermediate key. > >> > >> > > > >This is clear, I think. > > > >Cheers, > >Sam > > > > > > > >>Reasons: > >> > >>a) "Key transport" is not explicit enough. The purpose is to encipher > >>either a private key or a secret key. > >> > >>b) The example is not clear enough: "RSA key" can be a private key or a > >>public key, hence why "public" has been added. > >> > >>c) The key that is communicated is a decryption key rather than an > >>encryption key, hence why "content-encryption" has been changed into > >>"content-decryption". > >> > >>d) The example has been extended to cover the case of an asymmetric > >>cipher as well. > >> > >>e) In the last statement, the intermediate key would not necessarily be a > >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" > >>has been replaced by "key'. > >> > >>Note that the current text from X.509 is: > >> > >> c) keyEncipherment: for enciphering keys or other security information, > >> e.g. for key transport; > >> > >> d) dataEncipherment: for enciphering user data, but not keys or other > >> security information as in c) above; > >> > >>Denis > >> > >> > >> > >>>Russ > >>> > >>>At 10:14 PM 5/11/2005, Simon McMahon wrote: > >>> > >>> > >>> > >>>>Russ, > >>>> > >>>>They were calling an 'encrypt' function to encrypt XML data and they > >>>>gave it an RSA key (the cert actually) to do it. Of course it > >>>>internally made an AES key but they never saw it until the > >>>>interoperability issue made them look. From what they saw at the level > >>>>they were looking the interpretation was reasonable. When the > >>>>transport key is well hidden and simply part of the protocol then it > >>>>looks just like RSA is encrypting big slabs of data. If you know that > >>>>RSA is bound by the modulus size then you know what is really > >>>>happening but not all users of PKI know RSA so well. Why should they? > >>>> > >>>>Couple this interpretation of key-usage with a dubious decision to > >>>>reject encryption requests with certs that dont have key-usage='data > >>>>encipherment' and you have an interoperability problem. I say > >>>>"dubious" because it is a public key so you cannot enforce usage > >>>>policy anyway. The CA could set both flags to fix it, which by the way > >>>>was the vendors preferred solution, but its not my CA or their CA and > >>>>the CA doesn't do that. Why should they? > >>>> > >>>>This reference, in my opinion, allows the ambiguous interpretation: > >>>> > >>>> > >>>>> The keyEncipherment bit is asserted when the subject public key is > >>>>> used for key transport. For example, when an RSA key is to be > >>>>> used for key management, then this bit shall asserted. > >>>>> > >>>>> The dataEncipherment bit is asserted when the subject public key > >>>>> is used for enciphering user data, other than cryptographic keys. > >>>>> > >>>>> > >>>>In this case the public key is clearly "intended" to be used to > >>>>encrypt the XML data but it just doesn't do it directly because it > >>>>cant. The term "key management" also has associations with more basic > >>>>and explicit key management operations like installing trusted root > >>>>certs or secure installation of shared secret keys etc. In this case > >>>>it is much less obvious that key management is happening because the > >>>>key is bundled with the data. It looks just like the public key is > >>>>encrypting the data. > >>>> > >>>>In my opinion there are 3 cases presented as 2 in the RFC. > >>>>1. RSA encrypts data - hardly ever used. > >>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data - > >>>>common usage. > >>>>3. RSA explicitly encrypts keys for explicit key management functions > >>>>- common usage. > >>>>The current bits separate 1 from 2/3 yet people make the > >>>>interpretation that they split the more common 2 from 3 assuming 1 and > >>>>2 are the same thing. Knowledge of RSA is required to know that 1 and > >>>>2 are different. > >>>> > >>>>Peter's comment "This bit MUST NOT be set when the intention is to > >>>>encipher intermediate cryptographic keys rather than raw user data" is > >>>>most relevant in my case. Does PKIX support this clarification? > >>>> > >>>>In my opinion this problem will not entirely go away by clarifying the > >>>>standard because most people dont read it before they implement > >>>>something. The two bits are there and as long as they are both there > >>>>then the mistake will be made by busy developers. Unenforceable > >>>>key-usage policy, to "public" keys, will also continue to be > >>>>implemented. People will come looking for clarification once they have > >>>>an interoperability issue but by then it is often too late - the issue > >>>>usually gets decided by who has the biggest corporate balls. In this > >>>>case it wasn't too late so thanks for the assistance. > >>>> > >>>>If I could recommend a change to the standard then I would suggest > >>>>dropping one of the encryption bits and just have a single key-usage = > >>>>"encryption". Give it the value the same as "key-encryption" since > >>>>this is the common usage. > >>>> > >>>>Thanks, > >>>> > >>>>Simon McMahon. > >>>> > >>>> > >>>>Simon McMahon > >>>> > >>>>Work: (07) 31311420 > >>>>Mobile: (043) 2294180 > >>>> > >>>> > >>>> > >>>> > >>>>>>>Russ Housley 05/12/05 01:06am >>> > >>>>>>> > >>>>>>> > >>>>Simon: > >>>> > >>>>If they are encrypting the XML data directly with the RSA key (which is > >>>>very unlikely), then they are correct. > >>>> > >>>>The traditional way to handle this is to generate a random > >>>>content-encryption key (CEK) and then encrypt the XML data with a > >>>>symmetric algorithm using the CEK. The CEK is encrypted with the RSA > >>>>key from the certificate. Thus, the RSA key is really being used to > >>>>encrypt only > >>>>symmetric keys. > >>>> > >>>>Russ > >>>> > >>>>At 08:33 PM 5/10/2005, Simon McMahon wrote: > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>I have had a recent interoperability issue with a application vendor > >>>>> > >>>>> > >>>>that >didn't like the key-usage attributes in a cert from a CA vendor's > >>>> > >>>> > >>>>>certificate. Signing certs work fine, it was an encryption cert that > >>>>> > >>>>> > >>>>failed. > >>>> > >>>> > >>>>>CA sets key-usage = "key encipherment". > >>>>>Application wants to encrypt some XML data so looks for key-usage = > >>>>> > >>>>> > >>>>"data > >>>> > >>>> > >>>>>encipherment". Reason - because XML is data, not a key. > >>>>> > >>>>>I believe the application vendor is wrong and I explained that the > >>>>> > >>>>> > >>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt > >>>>the data but >they want an official "pkix" ruling based on the > >>>>standard so can someone >please refer me to a statement in the > >>>>standard that clears this up. > >>>> > >>>> > >>>>>Thanks, > >>>>> > >>>>>Simon McMahon. > >>>>> > >>>>> > >>>>> > >>>>>Simon McMahon > >>>>> > >>>>>Work: (07) 31311420 > >>>>>Mobile: (043) 2294180 > >>>>> > >>>>> > >>>>> > >>>>>Simon McMahon > >>>>> > >>>>>Work: (07) 31311420 > >>>>>Mobile: (043) 2294180 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>************************************************************************* > >>>>> > >>>>> > >>>>********** > >>>> > >>>> > >>>>>This email, including any attachments sent with it, is confidential and > >>>>>for the sole use of the intended recipient(s). This confidentiality is > >>>>>not waived or lost, if you receive it and you are not the intended > >>>>>recipient(s), or if it is transmitted/received in error. > >>>>> > >>>>>Any unauthorised use, alteration, disclosure, distribution or review of > >>>>>this email is prohibited. It may be subject to a statutory duty of > >>>>>confidentiality if it relates to health service matters. > >>>>> > >>>>>If you are not the intended recipient(s), or if you have received this > >>>>>email in error, you are asked to immediately notify the sender by > >>>>>telephone or by return email. You should also delete this email and > >>>>>destroy any hard copies produced. > >>>>>************************************************************************* > >>>>> > >>>>> > >>>>********** > >>>> > >>>> > >>>> > >>>>*********************************************************************************** > >>>> > >>>>This email, including any attachments sent with it, is confidential > >>>>and for the sole use of the intended recipient(s). This > >>>>confidentiality is not waived or lost, if you receive it and you are > >>>>not the intended recipient(s), or if it is transmitted/received in > >>>>error. > >>>> > >>>>Any unauthorised use, alteration, disclosure, distribution or review > >>>>of this email is prohibited. It may be subject to a statutory duty of > >>>>confidentiality if it relates to health service matters. > >>>> > >>>>If you are not the intended recipient(s), or if you have received this > >>>>email in error, you are asked to immediately notify the sender by > >>>>telephone or by return email. You should also delete this email and > >>>>destroy any hard copies produced. > >>>>*********************************************************************************** > >>>> > >>>> > >>>> > >>> > >>> > >>> > > > > > > -- http://www.certicom.com From owner-ietf-pkix@mail.imc.org Thu May 12 15:04:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22144 for ; Thu, 12 May 2005 15:04:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CI4r4j005439; Thu, 12 May 2005 11:04:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CI4rAq005438; Thu, 12 May 2005 11:04:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CI4pRe005424 for ; Thu, 12 May 2005 11:04:52 -0700 (PDT) (envelope-from todd.glassey@worldnet.att.net) Received: from gw (124.san-jose-09-10rs.ca.dial-access.att.net[12.72.195.124]) by worldnet.att.net (mtiwmhc13) with SMTP id <2005051218052311300pd3hse>; Thu, 12 May 2005 18:05:33 +0000 Message-ID: <00ae01c5571d$1b512ce0$010aff0a@gw> Reply-To: "todd glassey" From: "todd glassey" To: References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> <20050512151755.GA7289@certicom.com> <42838382.8060504@infocamere.it> Subject: Re: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 11:04:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hmmm - The person you are writing for is an IT Auditor because there is NO PKI system that is ever going to be deployed commercially from say 9/11 onward and especially after SOX that is going not have an Auditor's Approval. That means something I tried to get this WG to think about several years ago and that was Practice or Use Models for the IP's themselves. Todd Glassey, CISM, CIFI ----- Original Message ----- From: "Dino Esposito" To: "Sam Roberts" Cc: Sent: Thursday, May 12, 2005 9:25 AM Subject: Re: key usage - key encipherment or data encipherment > > IMO, the typical reader of a RFC is a technician. Especially for a RFC > full of PKI jargon. > If we wanted to write for a layman reader, we should write an encyclopedia > I think the Pinkas' proposal is quite clear. > > Dino Esposito > > Sam Roberts wrote: > > >Wrote Denis Pinkas , on Thu, May 12, 2005 at 04:44:28PM +0200: > > > > > >>Russ, > >> > >> > >> > >>>Since we are working on an update to RFC 3280, I propose the following > >>>revisions to these descritions. > >>> > >>> > >>> The keyEncipherment bit is asserted when the subject public key is > >>> used for key transport. For example, when an RSA key is to be > >>> used for key management by encrypting a symmetric content-encryption > >>> key, then this bit shall asserted. > >>> > >>> The dataEncipherment bit is asserted when the subject public key > >>> is used for directly enciphering raw user data without the use of > >>> an intermediate symmetric cipher. > >>> > >>> > >>Thank you for this strawman proposal. I would rather propose: > >> > >> The keyEncipherment bit is asserted when the subject public key is > >> used for enciphering private or secret keys, i.e. for key transport. > >> For example, this bit shall be set when a public RSA key is to be > >> used for encrypting a symmetric content-decryption key or an > >> asymmetric private key. > >> > >> > > > >Hi Denis, > > > >I think this text has the same problem as the current. In other words, > >somebody might read it and think "I'm not encrypting a key, I'm > >encrypting email, and I'm "transporting" a word document, not a key, so > >this isn't the bit I should look for". This is what happens now. > > > >I can't think of appropriate wording, but if the goal is to make it > >clear to non-security experts so the bit is used consistently, a little > >bit more explanation is needed. > > > > > > > >> The dataEncipherment bit is asserted when the subject public key > >> is used for directly enciphering raw user data without the use of > >> an intermediate key. > >> > >> > > > >This is clear, I think. > > > >Cheers, > >Sam > > > > > > > >>Reasons: > >> > >>a) "Key transport" is not explicit enough. The purpose is to encipher > >>either a private key or a secret key. > >> > >>b) The example is not clear enough: "RSA key" can be a private key or a > >>public key, hence why "public" has been added. > >> > >>c) The key that is communicated is a decryption key rather than an > >>encryption key, hence why "content-encryption" has been changed into > >>"content-decryption". > >> > >>d) The example has been extended to cover the case of an asymmetric cipher > >>as well. > >> > >>e) In the last statement, the intermediate key would not necessarily be a > >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has > >>been replaced by "key'. > >> > >>Note that the current text from X.509 is: > >> > >> c) keyEncipherment: for enciphering keys or other security information, > >> e.g. for key transport; > >> > >> d) dataEncipherment: for enciphering user data, but not keys or other > >> security information as in c) above; > >> > >>Denis > >> > >> > >> > >>>Russ > >>> > >>>At 10:14 PM 5/11/2005, Simon McMahon wrote: > >>> > >>> > >>> > >>>>Russ, > >>>> > >>>>They were calling an 'encrypt' function to encrypt XML data and they > >>>>gave it an RSA key (the cert actually) to do it. Of course it > >>>>internally made an AES key but they never saw it until the > >>>>interoperability issue made them look. From what they saw at the level > >>>>they were looking the interpretation was reasonable. When the > >>>>transport key is well hidden and simply part of the protocol then it > >>>>looks just like RSA is encrypting big slabs of data. If you know that > >>>>RSA is bound by the modulus size then you know what is really > >>>>happening but not all users of PKI know RSA so well. Why should they? > >>>> > >>>>Couple this interpretation of key-usage with a dubious decision to > >>>>reject encryption requests with certs that dont have key-usage='data > >>>>encipherment' and you have an interoperability problem. I say > >>>>"dubious" because it is a public key so you cannot enforce usage > >>>>policy anyway. The CA could set both flags to fix it, which by the way > >>>>was the vendors preferred solution, but its not my CA or their CA and > >>>>the CA doesn't do that. Why should they? > >>>> > >>>>This reference, in my opinion, allows the ambiguous interpretation: > >>>> > >>>> > >>>>> The keyEncipherment bit is asserted when the subject public key is > >>>>> used for key transport. For example, when an RSA key is to be > >>>>> used for key management, then this bit shall asserted. > >>>>> > >>>>> The dataEncipherment bit is asserted when the subject public key > >>>>> is used for enciphering user data, other than cryptographic keys. > >>>>> > >>>>> > >>>>In this case the public key is clearly "intended" to be used to > >>>>encrypt the XML data but it just doesn't do it directly because it > >>>>cant. The term "key management" also has associations with more basic > >>>>and explicit key management operations like installing trusted root > >>>>certs or secure installation of shared secret keys etc. In this case > >>>>it is much less obvious that key management is happening because the > >>>>key is bundled with the data. It looks just like the public key is > >>>>encrypting the data. > >>>> > >>>>In my opinion there are 3 cases presented as 2 in the RFC. > >>>>1. RSA encrypts data - hardly ever used. > >>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data - > >>>>common usage. > >>>>3. RSA explicitly encrypts keys for explicit key management functions > >>>>- common usage. > >>>>The current bits separate 1 from 2/3 yet people make the > >>>>interpretation that they split the more common 2 from 3 assuming 1 and > >>>>2 are the same thing. Knowledge of RSA is required to know that 1 and > >>>>2 are different. > >>>> > >>>>Peter's comment "This bit MUST NOT be set when the intention is to > >>>>encipher intermediate cryptographic keys rather than raw user data" is > >>>>most relevant in my case. Does PKIX support this clarification? > >>>> > >>>>In my opinion this problem will not entirely go away by clarifying the > >>>>standard because most people dont read it before they implement > >>>>something. The two bits are there and as long as they are both there > >>>>then the mistake will be made by busy developers. Unenforceable > >>>>key-usage policy, to "public" keys, will also continue to be > >>>>implemented. People will come looking for clarification once they have > >>>>an interoperability issue but by then it is often too late - the issue > >>>>usually gets decided by who has the biggest corporate balls. In this > >>>>case it wasn't too late so thanks for the assistance. > >>>> > >>>>If I could recommend a change to the standard then I would suggest > >>>>dropping one of the encryption bits and just have a single key-usage = > >>>>"encryption". Give it the value the same as "key-encryption" since > >>>>this is the common usage. > >>>> > >>>>Thanks, > >>>> > >>>>Simon McMahon. > >>>> > >>>> > >>>>Simon McMahon > >>>> > >>>>Work: (07) 31311420 > >>>>Mobile: (043) 2294180 > >>>> > >>>> > >>>> > >>>> > >>>>>>>Russ Housley 05/12/05 01:06am >>> > >>>>>>> > >>>>>>> > >>>>Simon: > >>>> > >>>>If they are encrypting the XML data directly with the RSA key (which is > >>>>very unlikely), then they are correct. > >>>> > >>>>The traditional way to handle this is to generate a random > >>>>content-encryption key (CEK) and then encrypt the XML data with a > >>>>symmetric algorithm using the CEK. The CEK is encrypted with the RSA > >>>>key from the certificate. Thus, the RSA key is really being used to > >>>>encrypt only > >>>>symmetric keys. > >>>> > >>>>Russ > >>>> > >>>> At 08:33 PM 5/10/2005, Simon McMahon wrote: > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>I have had a recent interoperability issue with a application vendor > >>>>> > >>>>> > >>>>that >didn't like the key-usage attributes in a cert from a CA vendor's > >>>> > >>>> > >>>>>certificate. Signing certs work fine, it was an encryption cert that > >>>>> > >>>>> > >>>>failed. > >>>> > >>>> > >>>>>CA sets key-usage = "key encipherment". > >>>>>Application wants to encrypt some XML data so looks for key-usage = > >>>>> > >>>>> > >>>>"data > >>>> > >>>> > >>>>>encipherment". Reason - because XML is data, not a key. > >>>>> > >>>>>I believe the application vendor is wrong and I explained that the > >>>>> > >>>>> > >>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt > >>>>the data but >they want an official "pkix" ruling based on the > >>>>standard so can someone >please refer me to a statement in the > >>>>standard that clears this up. > >>>> > >>>> > >>>>>Thanks, > >>>>> > >>>>>Simon McMahon. > >>>>> > >>>>> > >>>>> > >>>>>Simon McMahon > >>>>> > >>>>>Work: (07) 31311420 > >>>>>Mobile: (043) 2294180 > >>>>> > >>>>> > >>>>> > >>>>>Simon McMahon > >>>>> > >>>>>Work: (07) 31311420 > >>>>>Mobile: (043) 2294180 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>*********************************************************************** ** > >>>>> > >>>>> > >>>>********** > >>>> > >>>> > >>>>>This email, including any attachments sent with it, is confidential and > >>>>>for the sole use of the intended recipient(s). This confidentiality is > >>>>>not waived or lost, if you receive it and you are not the intended > >>>>>recipient(s), or if it is transmitted/received in error. > >>>>> > >>>>>Any unauthorised use, alteration, disclosure, distribution or review of > >>>>>this email is prohibited. It may be subject to a statutory duty of > >>>>>confidentiality if it relates to health service matters. > >>>>> > >>>>>If you are not the intended recipient(s), or if you have received this > >>>>>email in error, you are asked to immediately notify the sender by > >>>>>telephone or by return email. You should also delete this email and > >>>>>destroy any hard copies produced. > >>>>>*********************************************************************** ** > >>>>> > >>>>> > >>>>********** > >>>> > >>>> > >>>> > >>>>************************************************************************ *********** > >>>> > >>>>This email, including any attachments sent with it, is confidential > >>>>and for the sole use of the intended recipient(s). This > >>>>confidentiality is not waived or lost, if you receive it and you are > >>>>not the intended recipient(s), or if it is transmitted/received in error. > >>>> > >>>>Any unauthorised use, alteration, disclosure, distribution or review > >>>>of this email is prohibited. It may be subject to a statutory duty of > >>>>confidentiality if it relates to health service matters. > >>>> > >>>>If you are not the intended recipient(s), or if you have received this > >>>>email in error, you are asked to immediately notify the sender by > >>>>telephone or by return email. You should also delete this email and > >>>>destroy any hard copies produced. > >>>>************************************************************************ *********** > >>>> > >>>> > >>>> > >>> > >>> > >>> > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 12 16:14:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03909 for ; Thu, 12 May 2005 16:14:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJL7jP010841; Thu, 12 May 2005 12:21:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CJL7DZ010840; Thu, 12 May 2005 12:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CJL6Gt010834 for ; Thu, 12 May 2005 12:21:06 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8024 invoked by uid 0); 12 May 2005 19:20:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.201) by woodstock.binhost.com with SMTP; 12 May 2005 19:20:59 -0000 Message-Id: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 15:21:02 -0400 To: ietf-pkix@vpnc.org From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ From owner-ietf-pkix@mail.imc.org Thu May 12 16:31:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07203 for ; Thu, 12 May 2005 16:31:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJj8uD011958; Thu, 12 May 2005 12:45:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CJj8ac011957; Thu, 12 May 2005 12:45:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottmxsecs3.entrust.com (sottmxsecs3.entrust.com [216.191.252.14]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CJj70H011929 for ; Thu, 12 May 2005 12:45:07 -0700 (PDT) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 18939 invoked from network); 12 May 2005 19:41:14 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.3.0;12 May 2005 19:41:14 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 12 May 2005 19:41:14 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 May 2005 15:45:01 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F03A03339@sottmxs05.entrust.com> From: Sharon Boeyen To: "'Russ Housley'" , Denis Pinkas Cc: ietf-pkix@vpnc.org Subject: RE: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 15:44:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5572A.CD40DDF9" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5572A.CD40DDF9 Content-Type: text/plain I like the proposed text also. My only suggestion is could we add "symmetric" in the sentence for dataEncipherment, so it would read "... without the use of an intermediate symmetric key." I don't feel strongly about this but do think it helps with the clarity. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 11:22 AM To: Denis Pinkas Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Denis: Thanks. I think you suggestion improves the text. Russ At 10:44 AM 5/12/2005, Denis Pinkas wrote: >Russ, > >>Since we are working on an update to RFC 3280, I propose the following >>revisions to these descritions. > >> The keyEncipherment bit is asserted when the subject public key is >> used for key transport. For example, when an RSA key is to be >> used for key management by encrypting a symmetric content-encryption >> key, then this bit shall asserted. >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate symmetric cipher. > >Thank you for this strawman proposal. I would rather propose: > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e. for key transport. > For example, this bit shall be set when a public RSA key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate key. > >Reasons: > >a) "Key transport" is not explicit enough. The purpose is to encipher >either a private key or a secret key. > >b) The example is not clear enough: "RSA key" can be a private key or a >public key, hence why "public" has been added. > >c) The key that is communicated is a decryption key rather than an >encryption key, hence why "content-encryption" has been changed into >"content-decryption". > >d) The example has been extended to cover the case of an asymmetric >cipher >as well. > >e) In the last statement, the intermediate key would not necessarily be >a >symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" >has been replaced by "key'. > >Note that the current text from X.509 is: > > c) keyEncipherment: for enciphering keys or other security information, > e.g. for key transport; > > d) dataEncipherment: for enciphering user data, but not keys or other > security information as in c) above; > >Denis ------_=_NextPart_001_01C5572A.CD40DDF9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: key usage - key encipherment or data encipherment

I like the proposed text also. My only suggestion is = could we add "symmetric" in the sentence for = dataEncipherment, so it would read "... without the use of an = intermediate symmetric key." I don't feel strongly about this but = do think it helps with the clarity.

Cheers,
Sharon

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail= .imc.org] On Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 11:22 AM
To: Denis Pinkas
Cc: ietf-pkix@vpnc.org
Subject: Re: key usage - key encipherment or data = encipherment



Denis:

Thanks.  I think you suggestion improves the = text.

Russ

At 10:44 AM 5/12/2005, Denis Pinkas wrote:
>Russ,
>
>>Since we are working on an update to RFC = 3280, I propose the following
>>revisions to these descritions.
>
>>      The = keyEncipherment bit is asserted when the subject public key is
>>      used for key = transport.  For example, when an RSA key is to be
>>      used for key = management by encrypting a symmetric content-encryption
>>      key, then = this bit shall asserted.
>>      The = dataEncipherment bit is asserted when the subject public key
>>      is used for = directly enciphering raw user data without the use of
>>      an = intermediate symmetric cipher.
>
>Thank you for this strawman proposal. I would = rather propose:
>
>       The = keyEncipherment bit is asserted when the subject public key is
>       used for = enciphering private or secret keys, i.e. for key transport.
>       For = example, this bit shall be set when a public RSA key is to be
>       used for = encrypting a symmetric content-decryption key or an
>       asymmetric = private key.
>
>       The = dataEncipherment bit is asserted when the subject public key
>       is used for = directly enciphering raw user data without the use of
>       an = intermediate key.
>
>Reasons:
>
>a) "Key transport" is not explicit = enough. The purpose is to encipher
>either a private key or a secret key.
>
>b) The example is not clear enough: "RSA = key" can be a private key or a
>public key, hence why "public" has = been added.
>
>c) The key that is communicated is a decryption = key rather than an
>encryption key, hence why = "content-encryption" has been changed into
>"content-decryption".
>
>d) The example has been extended to cover the = case of an asymmetric
>cipher
>as well.
>
>e) In the last statement, the intermediate key = would not necessarily be
>a
>symmetric cipher, hence why = "symmetric" has been deleted. Also "cipher"
>has been replaced by "key'.
>
>Note that the current text from X.509 is:
>
>   c) keyEncipherment: for enciphering = keys or other security information,
>      e.g. for key = transport;
>
>   d) dataEncipherment: for = enciphering user data, but not keys or other
>      security = information as in c) above;
>
>Denis

------_=_NextPart_001_01C5572A.CD40DDF9-- From owner-ietf-pkix@mail.imc.org Thu May 12 22:12:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04892 for ; Thu, 12 May 2005 22:12:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D1KsbQ033550; Thu, 12 May 2005 18:20:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D1KsgH033549; Thu, 12 May 2005 18:20:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D1Kqg8033542 for ; Thu, 12 May 2005 18:20:52 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Fri, 13 May 2005 11:19:36 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Fri, 13 May 2005 11:19:36 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Fri, 13 May 2005 11:19:20 +1000 From: "Simon McMahon" To: , , Cc: Subject: RE: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4D1Krg8033544 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sorry but I think this new text is just more jargon and does not address the problem. The problem is that there are 2 bits for encryption instead of 1 so people can make a choice and need direction in that choice, but will still get it wrong anyway, just because they can (Murphy). The misunderstanding is that "keyEncipherment" is nearly always the correct choice but sometimes people use "dataEncipherment" because the transport keys are not explicit. Note that a new definition of a public key cipher RSA' that internally used "RSA+AES" but didn't publish that fact could have RSA' public keys (not RSA keys but internally identical to them) that directly encrypt large amounts of data. The transport key just blends into the cipher text. "dataEncipherment" is then the correct bit for the RSA' key but I'll bet people who know its really RSA+AES will use "keyEncipherment" because that is what is really happening. The bottom line is that this problem will never go away as long as you have two bits whose meanings overlap like these ones do. The bits should be merged because CA's that know about interoperability issues just set both anyway. I would prefer a consolidation these flags and to deprecate "dataEncipherment". That would leave "keyEncipherment" that could be renamed to "encipherment". Then there is no confusion because there is no choice anymore. Anyway, back to the text... Why did the "private" key creep into this description? "Private" keys are also "secret". By the way, how does a public key encrypt a private key? It is impossible, at least with RSA without a symmetric key in there, unless the private key is a lot smaller. The latest proposed text example specifies "content-decryption" now but symmetric keys exchanged this way can also be for encryption too. Also, the symmetric key encrypted by the public key was in fact an encryption key when the originator used it. Proposed rewording preserving both bits: " The keyEncipherment bit is asserted when the subject public key is used for transport of a secret key or data encryption using an intermediate secret key. For example, when a public key is to be used to encrypt a secret cipher key that will encrypt some data or key, then this bit shall asserted. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering user data other than cryptographic keys. " Proposed rewording with only one bit: " The dataEncipherment bit is deprecated. If asserted then this bit now has the same meaning as keyEncipherment. The keyEncipherment bit is renamed to "encipherment" and is asserted when either of the previous bits were asserted. Whenever a public key is used to encrypt data or keys then this bit shall be asserted. " Regards, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Sharon Boeyen 05/13/05 05:44am >>> I like the proposed text also. My only suggestion is could we add "symmetric" in the sentence for dataEncipherment, so it would read "... without the use of an intermediate symmetric key." I don't feel strongly about this but do think it helps with the clarity. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 11:22 AM To: Denis Pinkas Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Denis: Thanks. I think you suggestion improves the text. Russ At 10:44 AM 5/12/2005, Denis Pinkas wrote: >Russ, > >>Since we are working on an update to RFC 3280, I propose the following >>revisions to these descritions. > >> The keyEncipherment bit is asserted when the subject public key is >> used for key transport. For example, when an RSA key is to be >> used for key management by encrypting a symmetric content-encryption >> key, then this bit shall asserted. >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate symmetric cipher. > >Thank you for this strawman proposal. I would rather propose: > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e. for key transport. > For example, this bit shall be set when a public RSA key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate key. > >Reasons: > >a) "Key transport" is not explicit enough. The purpose is to encipher >either a private key or a secret key. > >b) The example is not clear enough: "RSA key" can be a private key or a >public key, hence why "public" has been added. > >c) The key that is communicated is a decryption key rather than an >encryption key, hence why "content-encryption" has been changed into >"content-decryption". > >d) The example has been extended to cover the case of an asymmetric >cipher >as well. > >e) In the last statement, the intermediate key would not necessarily be >a >symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" >has been replaced by "key'. > >Note that the current text from X.509 is: > > c) keyEncipherment: for enciphering keys or other security information, > e.g. for key transport; > > d) dataEncipherment: for enciphering user data, but not keys or other > security information as in c) above; > >Denis *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** From owner-ietf-pkix@mail.imc.org Fri May 13 00:10:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13567 for ; Fri, 13 May 2005 00:10:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D3cnq8045961; Thu, 12 May 2005 20:38:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D3cn7M045959; Thu, 12 May 2005 20:38:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D3cnpa045938 for ; Thu, 12 May 2005 20:38:49 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from [192.168.0.7] (hera.noorhome.net [192.168.0.7]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPS id <0IGE0084JRJ1UC@igw.noorhome.net> for ietf-pkix@vpnc.org; Thu, 12 May 2005 20:11:25 -0700 (PDT) Date: Thu, 12 May 2005 20:38:36 -0700 From: Arshad Noor Subject: Re: key usage - key encipherment or data encipherment In-reply-to: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> To: ietf-pkix@vpnc.org Message-id: <4284213C.8070000@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) References: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT I am afraid, this still does not provide sufficient clarity. Some questions that I cannot answer, based on reading the text below (although I know the answers from practice) are: 1) Whose private key am I encrypting with the public key? Mine? Hopefully not, because if this were the only copy of my private key, what am I going to use to decrypt the cipher-text with? While this may appear as a ridiculous notion, the point is that the text does not clarify this question. 2) What if I'm not using the certificate for key transport? I may have issued a certificate to a database that generates symmetric keys to encrypt database content, and then stores the encrypted symmetric key within the same database with the cipher-text. I'm not transporting the symmetric key anywhere, so should I be using the keyEncipherment bit or the dataEncirpherment bit? In my opinion, the confusion arises because the two bits perform the same function: encipherment (as Simon McMahon pointed out in an earlier posting), but for different purposes. There is a certain simplicity to having just one encipherment bit, letting applications decide what they want to encrypt with the certificate's public-key and letting them codify it in *their* protocols - as S/MIME does - or through EKU's. Arshad Noor StrongAuth, Inc. Russ Housley wrote: > > There has been a whole lot of discussion about these paragraphs. Since > some of the discussion has not been CCed to the PKIX mail list, I am > posting the resulting words. > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e., for key transport. > For example, this bit shall be set when a RSA public key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate symmetric cipher. Note that the use of this > bit is extremely uncommon; almost all applications use > key transport or key agreement to establish a symmetric key. > > I hope we a re close to closure on this one.... > > Russ > From owner-ietf-pkix@mail.imc.org Fri May 13 00:14:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13817 for ; Fri, 13 May 2005 00:14:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D3QvTC044593; Thu, 12 May 2005 20:26:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D3Qvfh044592; Thu, 12 May 2005 20:26:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D3QuP5044585 for ; Thu, 12 May 2005 20:26:57 -0700 (PDT) (envelope-from eldub@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 1C6E67A2; Thu, 12 May 2005 23:26:52 -0400 (EDT) Received: from distopia (c-24-22-214-246.hsd1.wa.comcast.net [24.22.214.246]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 6F08A8B; Thu, 12 May 2005 23:26:50 -0400 (EDT) From: "Laudon Williams" To: "'Russ Housley'" , Subject: RE: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 20:26:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVXMU5iLY8+5IXuQai+x1jw20eNrwAOY50g In-Reply-To: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050513032650.6F08A8B@orb.sasl.smtp.pobox.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Simply an observation, not a disagreement. Unfortunately, the keyEncipherment bit has grown to be used for both key encipherment and data encipherment. I see this a lot, especially with field-level encryption in databases, and encryption of small data files. I guess what I'm getting at is that I never see certificates with the dataEncipherment bit set in it in actual use, but I come across lots of places when data is encrypted with the private key. With that said, I like the text below. -Laudon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 12:21 PM To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ From owner-ietf-pkix@mail.imc.org Fri May 13 03:30:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16939 for ; Fri, 13 May 2005 03:30:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D6hAjG099345; Thu, 12 May 2005 23:43:10 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D6hAd6099344; Thu, 12 May 2005 23:43:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D6h85H099290 for ; Thu, 12 May 2005 23:43:09 -0700 (PDT) (envelope-from adriano.santoni@actalis.it) Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with SMTP id j4D6gt0c006752; Fri, 13 May 2005 08:42:55 +0200 (METDST) Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 08:42:54 +0200 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: R: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 08:42:54 +0200 Message-ID: Thread-Topic: key usage - key encipherment or data encipherment thread-index: AcVXKMKrk6a7r8bvTYiBPx796SM65gAXUjKQ From: "Santoni Adriano" To: "Russ Housley" Cc: X-OriginalArrivalTime: 13 May 2005 06:42:54.0834 (UTC) FILETIME=[FDFC6D20:01C55786] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4D6h95H099337 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'd suggest to modify the first part like follows (or equivalently): The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key (e.g. as it occurs in the TLS protocol with the server's public key). This would add another bit of clarity to the prescription. My 2 cents (of Euro :-) Adriano -----Messaggio originale----- Da: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] Per conto di Russ Housley Inviato: giovedì 12 maggio 2005 21.21 A: ietf-pkix@vpnc.org Oggetto: Re: key usage - key encipherment or data encipherment There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ *******************Internet Email Confidentiality Footer******************* Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof. From owner-ietf-pkix@mail.imc.org Fri May 13 04:36:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20745 for ; Fri, 13 May 2005 04:36:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7up02027721; Fri, 13 May 2005 00:56:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D7updX027720; Fri, 13 May 2005 00:56:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7uonU027676 for ; Fri, 13 May 2005 00:56:50 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA28398; Fri, 13 May 2005 10:11:40 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051309564137:1317 ; Fri, 13 May 2005 09:56:41 +0200 Message-ID: <42845DF4.8020405@bull.net> Date: Fri, 13 May 2005 09:57:40 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: pkix Subject: Re: Comments on References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> <42832153.8000802@bull.net> <6.2.1.2.2.20050512104257.0608b450@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:56:41, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:56:43, Serialize complete at 13/05/2005 09:56:43 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, > Denis: > > Finally! We now uncover the actual point of disagreement. I would hope, but I am still unsure. > You say: >> The same trust anchor is not a *sufficient* condition. The same node >> in the certification tree is the necessary condition. This implies, of >> course, the same trust anchor, but since two CRL issuers located at >> different nodes (i.e. certified by different CAS) might have the >> same CRL issuer name, this condition is insufficient to solve the >> issue. > When policies, procedures, and practices are followed, I do not believe > that two different CRL issuers that are subordinate to the same trust > anchor can legitimately have the same name. You have certainly heard of the name "Eurostar". That name was originally used by a French truck company, and the French-British railways anyway made accidentally a name collision with it. We can hope that this does not happen again, but we cannot make sure it already happened. We need to build a secure PKI, not a "nearly secure" PKI and there ARE solutions to make it fully secure. I also know there are current solutions which are NOT fully secure. The goal of our group is to say how to make it secure. > As I said yesterday, I am > willing to add text to the Security Considerations section to state > this. As mentioned above, this is untrue in general. > I am even willing to state that certificate users should not > include trust anchors that do not have policies, procedures, and > practices that would prevent such name collisions. This is impossible to state since the certification tree may be growing and thus you cannot make sure that you have explored all the tree. See my detailed response to Stefan from a few minutes ago on what needs to be covered in the security considerations section. Denis > Russ From owner-ietf-pkix@mail.imc.org Fri May 13 04:38:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20960 for ; Fri, 13 May 2005 04:38:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7qqhq026306; Fri, 13 May 2005 00:52:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D7qqiA026305; Fri, 13 May 2005 00:52:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7qoIS026258 for ; Fri, 13 May 2005 00:52:51 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA45772; Fri, 13 May 2005 10:07:38 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051309523802:1314 ; Fri, 13 May 2005 09:52:38 +0200 Message-ID: <42845D00.6050909@bull.net> Date: Fri, 13 May 2005 09:53:36 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:52:38, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:52:40, Serialize complete at 13/05/2005 09:52:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan, > Denis, > > My main comment to this is that there is no exact definition of what is > "sufficient" in this case. > > What is sufficient to you may not be sufficient to me or vice versa. > This issue is as many times when security is the issue a tradeoff. In IT > security you always have the 3 goals: > > - Cheep > - Easy to use > - Secure No. There is not such a trade-off in security. Either it is secure or not. > The sad truth is that we often discover that we can have any 2 of those > but never all 3. I do know some implementations that have this problem, and I won't nominate any. I will simply quote some recent good words from Peter Gutmann: " 1. Vendor does something silly. 2. Vendor uses ambiguous wording of spec to justify their silliness because they don't want to fix their code. 3. User has the option of breaking their code to match the vendor silliness, or going somewhere else (learning to flip burgers, for example)". I do not want cases 1 and 2 to happen, and this is exactly what is going to happen in the present case. Denis > The fact about name uniqueness you provide in the referenced text is a > true facts but it still does not tell me what is sufficient or not in my > environment or how I can achieve reasonable security when the trust > paths differ (in case they have to). > > My basic assessment is that there is neither a single truth nor a single > solution to the problem. The chaining to a common root was the > reasonable recommendation agreed at the San Diego PKIX meeting. This is > in my mind not intended to be advertised as a "sufficient" solution, > just good practice to reduce the risk of problems. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 12 maj 2005 11:27 >>To: Russ Housley >>Cc: pkix >>Subject: Re: Comments on >> >> >>Russ, >> >>Since Tim has now made the call at the WG level, please consider this >>message as an answer to the call: the current security considerations >>section is not acceptable. >> >> > The document already says that the CA and the CRL issuer need to >> > terminate at the same trust anchor. This is the important point. >> > I disagree that there is anything else that ought to be said in > > the > >> > security considerations. >> >>This statement still does not answer to the point I raised, but >>I will nevertheless answer to your statement. >> >>The same trust anchor is not a *sufficient* condition. The same node > > in > >>the >>certification tree is the necessary condition. This implies, of > > course, > >>the >>same trust anchor, but since two CRL issuers located at different > > nodes > >>(i.e. certified by different CAS) might have the same CRL issuer name, >>this >>condition is insufficient to solve the issue. >> >>May I recall an extract from the security considerations section of an >>approved draft that will be published soon as RFC 4043 ? (this is the >>permanent-identifier document): >> >> Subject names in certificates are chosen by the issuing CA and > > are > >> mandated to be unique for each CA; so there can be no name > > collision > >> between subject names from the same CA. Such a name may be an > > end- > >> entity name when the certificate is a leaf certificate, or a CA >>name, >> when it is a CA certificate. >> >> Since a name is only unique towards its superior CA, unless some >> naming constraints are being used, a name would only be > > guaranteed > >>to >> be globally unique when considered to include a sequence of all > > the > >> names of the superior CAs. (...) >> >> Additional checks need to be done, e.g., to check if the public > > key > >> values of the two CAs which have issued the certificates to be >> compared are identical or if the sequence of CA names in the >> certification path from the trust anchor to the CA are > > identical. > >> (...) >> >> The certification of different CAs with the same DN by different > > CAs > >> has other negative consequences in various parts of the PKI, > > notably > >> rendering the IssuerAndSerialNumber structure in [RFC3852] > > section > >> 10.2.4 ambiguous. >> >>It speaks for itself, as it applies to CRL Issuers as well. Some parts > > of > >>it should indeed be copied and pasted in the security considerations >>section >>of the current proposed draft. >> >>When the certification path used to validate the target certificate is >>also used to validate the CRL Issuer certificate, then there is no >>security >>issue: this should be said in the security considerations section. >> >>What about the other cases ? The other cases belong to the category of >>indirect CRLs. Depending on the local validation policy checks done or > > not > >>done there may be security issues. >> >>Denis >> >> > Russ >> > >> > At 02:59 AM 5/10/2005, Denis Pinkas wrote: >> > >> >> Russ, >> >> >> >> Your statement below is correct, but does not answer to any of my >> >> questions/issues. In particular, the last one. I am still > > awaiting > >> >> your responses. >> >> >> >> Denis >> >> >> >>> Denis: >> >>> RFC 3280 does not tell an implementor how for locate > > certificates > >>for >> >>> any certification path construction. There are several > > extensions > >> >>> that provide pointers that may help an implementation, but other >> >>> approaches to obtaining the same certificates are always > > permitted. > >> >>> I would fully expect an implementation to check any local cache >> >>> before accessing a repository. >> >>> The CRL AIA extension fits this pattern. A method for locating > > a > >> >>> certificate is provided, but any other mechanism for locating > > the > >> >>> same certificate is acceptable. >> >>> Russ >> >>> >> >>>> Stefan, >> >>>> >> >>>> I made the e-mail shorter. Your main arguments are the > > following: > >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> [Stefan] But it has to provide a warning to something that is >> >>>> introduced >> >>>> by the standard. This standard does not introduce the concept > > of > >>CRL >> >>>> signature checking or CRL issuer certificate validation, so > > that is > >> >>>> clearly out of scope. More about that below; >> >>>> >> >>>> [Denis] See below the last answer and also my arguments in the >> >>>> soon-to-be-posted answer to Russ. >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> >> >>>> > > RFC 3280 [PKIX1] specifies the validation of certification >>paths. >> >>>> > > One aspect involves the determination that a certificate > > has > >>not >> >>>> been >> >>>> > > revoked, and one revocation checking mechanism is the >>Certificate >> >>>> > > Revocation List (CRL). CRL validation is also specified in > > RFC > >> >>>> 3280, >> >>>> >> >>>> > I would love this last sentence to be true but the reality is >>that: >> >>>> > "CRL validation is NOT specified in RFC 3280". :-( >> >>>> >> >>>> [Stefan] In fact it is. >> >>>> >> >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: >> >>>> >> >>>> (f) Obtain and validate the certification path for the > > complete > >>CRL >> >>>> issuer. If a key usage extension is present in the CRL > > issuer's > >> >>>> certificate, verify that the cRLSign bit is set. >> >>>> >> >>>> (g) Validate the signature on the complete CRL using the > > public > >>key >> >>>> validated in step (f). >> >>>> >> >>>> [Denis] The text does not say how to obtain and validate the >> >>>> certification path for the complete (???) CRL issuer. The text > > is > >> >>>> not clear enough so that two implementors only looking at this >> >>>> sentence will provide interoperable implementations. >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> [Stefan] It is my hope that the provided responses here can > > help > >> >>>> convince you to change your mind about that. If it doesn't I > > still > >> >>>> argue >> >>>> that the place to specify requirements and security > > considerations > >>for >> >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL >>draft. >> >>>> >> >>>> [Denis] I can agree with your last sentence, ... which means > > that > >>it >> >>>> should not be in the main body of the document. In the security >> >>>> considerations section, text is free and we shall at the very >> >>>> minimum warn implementers and we should provide some guidance. > > When > >> >>>> the same certification path (i.e. the path used to validate the >> >>>> target certificate) is used, then there is no security issue: > > this > >> >>>> should be said. For all other cases, there MAY be problems: > > this > >> >>>> should also be said. It is as simple as that. >> >>>> >> >>>> Denis >> >>> >> >> >> >> >> > >> > >> >> >> > > From owner-ietf-pkix@mail.imc.org Fri May 13 04:45:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21446 for ; Fri, 13 May 2005 04:45:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7oV4W025475; Fri, 13 May 2005 00:50:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D7oV5u025474; Fri, 13 May 2005 00:50:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7oD8e025334 for ; Fri, 13 May 2005 00:50:30 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA60650; Fri, 13 May 2005 10:05:03 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051309500478:1313 ; Fri, 13 May 2005 09:50:04 +0200 Message-ID: <42845C67.4020501@bull.net> Date: Fri, 13 May 2005 09:51:03 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: Structuring Denis issues RE: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:50:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:50:05, Serialize complete at 13/05/2005 09:50:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan, > Denis, > > The core of your comments are spread over many emails and opinions may > have changed on details so I'm not sure I have got the latest picture of > your recorded problems and what you propose as resolution. > > I'm thus trying to summarize the current complete picture of the last > call comments below. Please correct me if something is wrong or missing. > Note that I'm not arguing here, just trying to structure the issues (I > will argue in separate mails). Also note that agreed typos are omitted > from the list: > 1) > Problem: There are SHOULD and MUST requirements in the security > considerations section. > Proposed resolution: Reword to make sure we don't use SHOULD or MUST in > this section. I believe they we all agree on this. > ----- > 2) > Problem: The security considerations talk about "mitigation" of the name > collision problem but gives inadequate advice. > Proposed resolution: Either delete all text talking about how to > mitigate this problem or provide full guidance on what it takes to > guarantee that a CRL Issuer with a matching name actually is the > intended CRL Issuer. Also explain that this is not an issue when the CRL > Issuer certification path and the target certificate certification path > are identical. Not exactly. I would say : a) warn the user that the CRL where this extension was found may not be the right one. b) warn the user that the CRL issuer certificate he might obtain using this extension may not be the right one. c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed the one nominated by the CA that has issued the target certificate (i.e. when the CRL Issuer certification path and the target certificate certification path are identical). d) say that other possibilities exists, but need additional trust conditions (there are zillions of such possible trust conditions). Denis > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 12 maj 2005 11:27 >>To: Russ Housley >>Cc: pkix >>Subject: Re: Comments on >> >> >>Russ, >> >>Since Tim has now made the call at the WG level, please consider this >>message as an answer to the call: the current security considerations >>section is not acceptable. >> >> > The document already says that the CA and the CRL issuer need to >> > terminate at the same trust anchor. This is the important point. >> > I disagree that there is anything else that ought to be said in > > the > >> > security considerations. >> >>This statement still does not answer to the point I raised, but >>I will nevertheless answer to your statement. >> >>The same trust anchor is not a *sufficient* condition. The same node > > in > >>the >>certification tree is the necessary condition. This implies, of > > course, > >>the >>same trust anchor, but since two CRL issuers located at different > > nodes > >>(i.e. certified by different CAS) might have the same CRL issuer name, >>this >>condition is insufficient to solve the issue. >> >>May I recall an extract from the security considerations section of an >>approved draft that will be published soon as RFC 4043 ? (this is the >>permanent-identifier document): >> >> Subject names in certificates are chosen by the issuing CA and > > are > >> mandated to be unique for each CA; so there can be no name > > collision > >> between subject names from the same CA. Such a name may be an > > end- > >> entity name when the certificate is a leaf certificate, or a CA >>name, >> when it is a CA certificate. >> >> Since a name is only unique towards its superior CA, unless some >> naming constraints are being used, a name would only be > > guaranteed > >>to >> be globally unique when considered to include a sequence of all > > the > >> names of the superior CAs. (...) >> >> Additional checks need to be done, e.g., to check if the public > > key > >> values of the two CAs which have issued the certificates to be >> compared are identical or if the sequence of CA names in the >> certification path from the trust anchor to the CA are > > identical. > >> (...) >> >> The certification of different CAs with the same DN by different > > CAs > >> has other negative consequences in various parts of the PKI, > > notably > >> rendering the IssuerAndSerialNumber structure in [RFC3852] > > section > >> 10.2.4 ambiguous. >> >>It speaks for itself, as it applies to CRL Issuers as well. Some parts > > of > >>it should indeed be copied and pasted in the security considerations >>section >>of the current proposed draft. >> >>When the certification path used to validate the target certificate is >>also used to validate the CRL Issuer certificate, then there is no >>security >>issue: this should be said in the security considerations section. >> >>What about the other cases ? The other cases belong to the category of >>indirect CRLs. Depending on the local validation policy checks done or > > not > >>done there may be security issues. >> >>Denis >> >> > Russ >> > >> > At 02:59 AM 5/10/2005, Denis Pinkas wrote: >> > >> >> Russ, >> >> >> >> Your statement below is correct, but does not answer to any of my >> >> questions/issues. In particular, the last one. I am still > > awaiting > >> >> your responses. >> >> >> >> Denis >> >> >> >>> Denis: >> >>> RFC 3280 does not tell an implementor how for locate > > certificates > >>for >> >>> any certification path construction. There are several > > extensions > >> >>> that provide pointers that may help an implementation, but other >> >>> approaches to obtaining the same certificates are always > > permitted. > >> >>> I would fully expect an implementation to check any local cache >> >>> before accessing a repository. >> >>> The CRL AIA extension fits this pattern. A method for locating > > a > >> >>> certificate is provided, but any other mechanism for locating > > the > >> >>> same certificate is acceptable. >> >>> Russ >> >>> >> >>>> Stefan, >> >>>> >> >>>> I made the e-mail shorter. Your main arguments are the > > following: > >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> [Stefan] But it has to provide a warning to something that is >> >>>> introduced >> >>>> by the standard. This standard does not introduce the concept > > of > >>CRL >> >>>> signature checking or CRL issuer certificate validation, so > > that is > >> >>>> clearly out of scope. More about that below; >> >>>> >> >>>> [Denis] See below the last answer and also my arguments in the >> >>>> soon-to-be-posted answer to Russ. >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> >> >>>> > > RFC 3280 [PKIX1] specifies the validation of certification >>paths. >> >>>> > > One aspect involves the determination that a certificate > > has > >>not >> >>>> been >> >>>> > > revoked, and one revocation checking mechanism is the >>Certificate >> >>>> > > Revocation List (CRL). CRL validation is also specified in > > RFC > >> >>>> 3280, >> >>>> >> >>>> > I would love this last sentence to be true but the reality is >>that: >> >>>> > "CRL validation is NOT specified in RFC 3280". :-( >> >>>> >> >>>> [Stefan] In fact it is. >> >>>> >> >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: >> >>>> >> >>>> (f) Obtain and validate the certification path for the > > complete > >>CRL >> >>>> issuer. If a key usage extension is present in the CRL > > issuer's > >> >>>> certificate, verify that the cRLSign bit is set. >> >>>> >> >>>> (g) Validate the signature on the complete CRL using the > > public > >>key >> >>>> validated in step (f). >> >>>> >> >>>> [Denis] The text does not say how to obtain and validate the >> >>>> certification path for the complete (???) CRL issuer. The text > > is > >> >>>> not clear enough so that two implementors only looking at this >> >>>> sentence will provide interoperable implementations. >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> [Stefan] It is my hope that the provided responses here can > > help > >> >>>> convince you to change your mind about that. If it doesn't I > > still > >> >>>> argue >> >>>> that the place to specify requirements and security > > considerations > >>for >> >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL >>draft. >> >>>> >> >>>> [Denis] I can agree with your last sentence, ... which means > > that > >>it >> >>>> should not be in the main body of the document. In the security >> >>>> considerations section, text is free and we shall at the very >> >>>> minimum warn implementers and we should provide some guidance. > > When > >> >>>> the same certification path (i.e. the path used to validate the >> >>>> target certificate) is used, then there is no security issue: > > this > >> >>>> should be said. For all other cases, there MAY be problems: > > this > >> >>>> should also be said. It is as simple as that. >> >>>> >> >>>> Denis >> >>> >> >> >> >> >> > >> > >> >> >> > > From owner-ietf-pkix@mail.imc.org Fri May 13 04:53:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21798 for ; Fri, 13 May 2005 04:53:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7wY6e028320; Fri, 13 May 2005 00:58:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D7wYTp028319; Fri, 13 May 2005 00:58:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7wVaZ028276 for ; Fri, 13 May 2005 00:58:32 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA60702; Fri, 13 May 2005 10:13:21 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051309582197:1318 ; Fri, 13 May 2005 09:58:21 +0200 Message-ID: <42845E58.6010502@bull.net> Date: Fri, 13 May 2005 09:59:20 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org Subject: Re: Comments on References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> <42832509.5020001@bull.net> <6.2.1.2.2.20050512105428.060f0210@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:58:22, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:58:24, Serialize complete at 13/05/2005 09:58:24 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, > Denis: >> >>> You say that it is not clear what validation policy needs to be used, >> >>> but this is completely irrelevant to the discussion of the CRL AIA >> >>> extension. This extension aid in certification path construction, >> >>> not the validation of the path once it is constructed. >> >> Not exactly, it could "help" finding a wrong path ! >> > Not likely. The signer of the CRL is providing a pointer to their own >> > certificate. Path construction to locate a parent of that certificate >> > through a complex PKI might include paths that are acceptable and paths >> > that are unacceptable, but the certificate that contains the public key >> > needed to validate the signature on the CRL is clearly needed. >> The problem is to know if a CRL that has been fetched "somewhere" is >> adequate for the target certificate. It is not to validate a CRL that >> has been fetched "somewhere". > You continue to miss the whole point of this document. I do not think so. > The certificate user has already obtained the CRL, but needs the ^^^^ it is not "the" CRL since it is only "a" CRL. If you got a network attack when fetching the CRL from the CRL DP you may get something wrong. So at this time you still do not know what is *the* right CRL. > certificate of the CRL issuer in order to validate the signature on the > CRL. That is the scope of this document. Not exacly. You are not sure to get "the" CA certificate of the CRL issuer, but only "a" certificate that bears the appropriate DN in the subject DN. but collisions in subject DNs may happen accidently or deliberately. > You keep trying to make it something else. The distinction between "the" and "a" is pretty important. Denis > Russ From owner-ietf-pkix@mail.imc.org Fri May 13 05:17:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23312 for ; Fri, 13 May 2005 05:17:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D8d2tg042716; Fri, 13 May 2005 01:39:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D8d2mh042714; Fri, 13 May 2005 01:39:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D8d0IB042693 for ; Fri, 13 May 2005 01:39:01 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft5.fr.colt.net with ESMTP id j4D8cx523356 for ; Fri, 13 May 2005 10:38:59 +0200 Message-ID: <428467A3.6030109@free.fr> Date: Fri, 13 May 2005 10:38:59 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050512 MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Comments on References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> <42832153.8000802@bull.net> <6.2.1.2.2.20050512104257.0608b450@mail.binhost.com> <42845DF4.8020405@bull.net> In-Reply-To: <42845DF4.8020405@bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Denis Pinkas wrote: > > When policies, procedures, and practices are followed, I do not believe > > that two different CRL issuers that are subordinate to the same trust > > anchor can legitimately have the same name. > > You have certainly heard of the name "Eurostar". That name was originally > used by a French truck company, and the French-British railways anyway > made accidentally a name collision with it. Isn't the source of this problem the fact that as long as nothing cryptographically binds to it, it's very hard to be completely sure we got the right certificate ? So why not solve that and expand the way we link to the CRL issuer to allow the use a ESSCertID ? From owner-ietf-pkix@mail.imc.org Fri May 13 06:01:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28481 for ; Fri, 13 May 2005 06:01:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D9A1HF053570; Fri, 13 May 2005 02:10:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D9A11O053569; Fri, 13 May 2005 02:10:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D9A0Ih053525 for ; Fri, 13 May 2005 02:10:00 -0700 (PDT) (envelope-from diegofv@eresmas.com) Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 1DWWB3-0003jJ-00; Fri, 13 May 2005 11:09:49 +0200 From: To: housley@vigilsec.com Cc: ietf-pkix@vpnc.org Message-ID: Date: Fri, 13 May 2005 09:09:50 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: RE: Re: key usage - key encipherment or data encipherment X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit IMO password or PIN is also considered as a secret key, then which applications or protocols are demanding the dataEncipherment bit? Thanks Diego ----- Mensaje Original ----- Remitente: Russ Housley housley@vigilsec.com Destinatario: ietf-pkix@vpnc.org Fecha: Jueves, Mayo 12, 2005 9:21pm Asunto: Re: key usage - key encipherment or data encipherment > > The keyEncipherment bit is asserted when the subject public >key is > used for enciphering private or secret keys, i.e., for key >transport. For example, this bit shall be set when a RSA public >key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate symmetric cipher. Note that the use of this > bit is extremely uncommon; almost all applications use > key transport or key agreement to establish a symmetric key. > From owner-ietf-pkix@mail.imc.org Fri May 13 06:35:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02086 for ; Fri, 13 May 2005 06:35:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D9mcs8067693; Fri, 13 May 2005 02:48:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D9mchC067691; Fri, 13 May 2005 02:48:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D9maMP067670 for ; Fri, 13 May 2005 02:48:36 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4D9mYAH024493 for ; Fri, 13 May 2005 17:48:34 +0800 Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4D9mXYu008220 for ; Fri, 13 May 2005 17:48:33 +0800 Message-ID: <01bf01c557a0$ec060ad0$4f85900a@wcwang> From: "Wen-Cheng Wang" To: References: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> <4284213C.8070000@strongauth.com> Subject: Re: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 17:48:30 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I also hesitate to accept the term "key transport", which will result in over-narrowing down the usage scope of the keyEncipherment bit. As Arshad pointed out, sometimes the intention is not to transport the encrypted symmetric key to anywhere. Besides, it is often that the handshake protocol is not simply a "key transport" process; it is more often be a more complex "key exchange" process. For example, the SSL handshake protocol names it as "key exchange" instead of "key transport". Would it be valid for a SSL server cert to be asserted with that keyEncipherment bit? To avoid the possible dispute on the definition of similar terms, I would like to suggest to drop the term "key transport" from the definition of the key usage bit. (However, I think it is OK to use "key transport" as an example to explain the the definition of the key usage bit. I also think it is strange to positively list "private keys" and "secret keys" as the only two possible types of keys that can be encrypted by the subject public key? What if someday another type of keys is invented and need to be encrypted by the subject public key? Why not simply use the term "cryptographic keys"? I believe the term "cryptographic keys" is general enough to cover any types of keys. My other concern is that the current definition of the key usage bit seems to only allow the subject public key be used for enciphering "keys". However, we must note that it is more often that modern handshake protocols actually use the subject public key for enciphering "keying materials" instead of the "real keys". For example, the pre-master-secret in the SSL hadnshake protocol is not yet a "real key"; it is actually be a "keying material" that can be used to derive "real shared secret keys" between the client and the server. Therefore, I suggest that we should take the possibility of enciphering "keying materials" instead of the "real keys" into account. Here I propose to revise the definitions of this two key usage bits as follows: The keyEncipherment bit is asserted when the subject public key is used for enciphering cryptographic keys or keying materials. For example, this bit shall be set when a RSA public key is to be used for key transport that involves encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data, other than cryptographic keys or keying materials, without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish shared cryptographic keys. Wen-Cheng Wang Arshad Noor wrote: > > I am afraid, this still does not provide sufficient clarity. > > Some questions that I cannot answer, based on reading the text > below (although I know the answers from practice) are: > > 1) Whose private key am I encrypting with the public key? Mine? > Hopefully not, because if this were the only copy of my private > key, what am I going to use to decrypt the cipher-text with? > While this may appear as a ridiculous notion, the point is that > the text does not clarify this question. > > 2) What if I'm not using the certificate for key transport? I may > have issued a certificate to a database that generates symmetric > keys to encrypt database content, and then stores the encrypted > symmetric key within the same database with the cipher-text. I'm > not transporting the symmetric key anywhere, so should I be using > the keyEncipherment bit or the dataEncirpherment bit? > > In my opinion, the confusion arises because the two bits perform > the same function: encipherment (as Simon McMahon pointed out in > an earlier posting), but for different purposes. > > There is a certain simplicity to having just one encipherment bit, > letting applications decide what they want to encrypt with the > certificate's public-key and letting them codify it in *their* > protocols - as S/MIME does - or through EKU's. > > Arshad Noor > StrongAuth, Inc. > > > Russ Housley wrote: >> >> There has been a whole lot of discussion about these paragraphs. Since >> some of the discussion has not been CCed to the PKIX mail list, I am >> posting the resulting words. >> >> The keyEncipherment bit is asserted when the subject public key is >> used for enciphering private or secret keys, i.e., for key transport. >> For example, this bit shall be set when a RSA public key is to be >> used for encrypting a symmetric content-decryption key or an >> asymmetric private key. >> >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate symmetric cipher. Note that the use of this >> bit is extremely uncommon; almost all applications use >> key transport or key agreement to establish a symmetric key. >> >> I hope we a re close to closure on this one.... >> >> Russ >> > From owner-ietf-pkix@mail.imc.org Fri May 13 07:22:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05083 for ; Fri, 13 May 2005 07:22:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DASulJ082324; Fri, 13 May 2005 03:28:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DASu1e082323; Fri, 13 May 2005 03:28:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DASsGk082278 for ; Fri, 13 May 2005 03:28:54 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 11:28:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Structuring Denis issues RE: Comments on Date: Fri, 13 May 2005 11:28:44 +0100 Message-ID: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVXkGrXh4L68PMITiGhBZiWP1sEXwAE8o8A From: "Stefan Santesson" To: "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 13 May 2005 10:28:48.0933 (UTC) FILETIME=[8CDBCD50:01C557A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4DAStGk082314 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, Thanks for the clarification. Yes, we agree on issue number 1 (remove SHOULD and MUST) So the remaining issue is: Problem: The security considerations talk about "mitigation" of the name collision problem but gives inadequate advice. Your proposed resolution a) warn the user that the CRL where this extension was found may not be the right one. b) warn the user that the CRL issuer certificate he might obtain using this extension may not be the right one. c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed the one nominated by the CA that has issued the target certificate (i.e. when the CRL Issuer certification path and the target certificate certification path are identical). d) say that other possibilities exists, but need additional trust conditions (there are zillions of such possible trust conditions). To complete the picture it would now be very helpful if you, for each of these statements, could confirm or explain how these issues are a result of using the AIA extension in CRLs. Or in other words, which of these security considerations could you ignore (would go away) if you were NOT using the AIA extension in a CRL to locate the CRL Issuer certificate. Stefan Santesson Program Manager, Standards Liaison Windows Security From owner-ietf-pkix@mail.imc.org Fri May 13 07:39:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06086 for ; Fri, 13 May 2005 07:39:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DAqEeT091321; Fri, 13 May 2005 03:52:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DAqEZH091320; Fri, 13 May 2005 03:52:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DAqDVw091283 for ; Fri, 13 May 2005 03:52:13 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 11:52:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 11:52:02 +0100 Message-ID: Thread-Topic: key usage - key encipherment or data encipherment Thread-Index: AcVXYamK19IQ9UoOTv+YwThTUKtlWwARyOQg From: "Stefan Santesson" To: "Simon McMahon" , , , Cc: X-OriginalArrivalTime: 13 May 2005 10:52:07.0587 (UTC) FILETIME=[CE857730:01C557A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4DAqEVw091314 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit How about calling the bits "The encryption bit" and "The other encryption bit" :-) Jokes aside, can anyone recall the justification for having 2 different bits for key and data encryption? Is there any realistic security threat involved with allowing both purposes for the same bit? Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Simon McMahon > Sent: den 13 maj 2005 03:19 > To: Denis.Pinkas@bull.net; sharon.boeyen@entrust.com; housley@vigilsec.com > Cc: ietf-pkix@vpnc.org > Subject: RE: key usage - key encipherment or data encipherment > > > Sorry but I think this new text is just more jargon and does not address > the problem. The problem is that there are 2 bits for encryption instead > of 1 so people can make a choice and need direction in that choice, but > will still get it wrong anyway, just because they can (Murphy). The > misunderstanding is that "keyEncipherment" is nearly always the correct > choice but sometimes people use "dataEncipherment" because the transport > keys are not explicit. > > Note that a new definition of a public key cipher RSA' that internally > used "RSA+AES" but didn't publish that fact could have RSA' public keys > (not RSA keys but internally identical to them) that directly encrypt > large amounts of data. The transport key just blends into the cipher text. > "dataEncipherment" is then the correct bit for the RSA' key but I'll bet > people who know its really RSA+AES will use "keyEncipherment" because that > is what is really happening. > > The bottom line is that this problem will never go away as long as you > have two bits whose meanings overlap like these ones do. The bits should > be merged because CA's that know about interoperability issues just set > both anyway. I would prefer a consolidation these flags and to deprecate > "dataEncipherment". That would leave "keyEncipherment" that could be > renamed to "encipherment". Then there is no confusion because there is no > choice anymore. > > Anyway, back to the text... > > Why did the "private" key creep into this description? "Private" keys are > also "secret". By the way, how does a public key encrypt a private key? It > is impossible, at least with RSA without a symmetric key in there, unless > the private key is a lot smaller. The latest proposed text example > specifies "content-decryption" now but symmetric keys exchanged this way > can also be for encryption too. Also, the symmetric key encrypted by the > public key was in fact an encryption key when the originator used it. > > Proposed rewording preserving both bits: > " > The keyEncipherment bit is asserted when the subject public key is used > for transport of a secret key or data encryption using an intermediate > secret key. For example, when a public key is to be used to encrypt a > secret cipher key that will encrypt some data or key, then this bit shall > asserted. > > The dataEncipherment bit is asserted when the subject public key is used > for directly enciphering user data other than cryptographic keys. > " > > Proposed rewording with only one bit: > " > The dataEncipherment bit is deprecated. If asserted then this bit now has > the same meaning as keyEncipherment. The keyEncipherment bit is renamed to > "encipherment" and is asserted when either of the previous bits were > asserted. Whenever a public key is used to encrypt data or keys then this > bit shall be asserted. > " > > Regards, > > Simon McMahon. > > > > Simon McMahon > > Work: (07) 31311420 > Mobile: (043) 2294180 > > > >>> Sharon Boeyen 05/13/05 05:44am >>> > I like the proposed text also. My only suggestion is could we add > "symmetric" in the sentence for dataEncipherment, so it would read "... > without the use of an intermediate symmetric key." I don't feel strongly > about this but do think it helps with the clarity. > > Cheers, > Sharon > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Russ Housley > Sent: Thursday, May 12, 2005 11:22 AM > To: Denis Pinkas > Cc: ietf-pkix@vpnc.org > Subject: Re: key usage - key encipherment or data encipherment > > > > Denis: > > Thanks. I think you suggestion improves the text. > > Russ > > At 10:44 AM 5/12/2005, Denis Pinkas wrote: > >Russ, > > > >>Since we are working on an update to RFC 3280, I propose the following > >>revisions to these descritions. > > > >> The keyEncipherment bit is asserted when the subject public key is > >> used for key transport. For example, when an RSA key is to be > >> used for key management by encrypting a symmetric content- > encryption > >> key, then this bit shall asserted. > >> The dataEncipherment bit is asserted when the subject public key > >> is used for directly enciphering raw user data without the use of > >> an intermediate symmetric cipher. > > > >Thank you for this strawman proposal. I would rather propose: > > > > The keyEncipherment bit is asserted when the subject public key is > > used for enciphering private or secret keys, i.e. for key > transport. > > For example, this bit shall be set when a public RSA key is to be > > used for encrypting a symmetric content-decryption key or an > > asymmetric private key. > > > > The dataEncipherment bit is asserted when the subject public key > > is used for directly enciphering raw user data without the use of > > an intermediate key. > > > >Reasons: > > > >a) "Key transport" is not explicit enough. The purpose is to encipher > >either a private key or a secret key. > > > >b) The example is not clear enough: "RSA key" can be a private key or a > >public key, hence why "public" has been added. > > > >c) The key that is communicated is a decryption key rather than an > >encryption key, hence why "content-encryption" has been changed into > >"content-decryption". > > > >d) The example has been extended to cover the case of an asymmetric > >cipher > >as well. > > > >e) In the last statement, the intermediate key would not necessarily be > >a > >symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" > >has been replaced by "key'. > > > >Note that the current text from X.509 is: > > > > c) keyEncipherment: for enciphering keys or other security > information, > > e.g. for key transport; > > > > d) dataEncipherment: for enciphering user data, but not keys or other > > security information as in c) above; > > > >Denis > > > ************************************************************************ ** > ********* > This email, including any attachments sent with it, is confidential and > for the sole use of the intended recipient(s). This confidentiality is > not waived or lost, if you receive it and you are not the intended > recipient(s), or if it is transmitted/received in error. > > Any unauthorised use, alteration, disclosure, distribution or review of > this email is prohibited. It may be subject to a statutory duty of > confidentiality if it relates to health service matters. > > If you are not the intended recipient(s), or if you have received this > email in error, you are asked to immediately notify the sender by > telephone or by return email. You should also delete this email and > destroy any hard copies produced. > ************************************************************************ ** > ********* > > From owner-ietf-pkix@mail.imc.org Fri May 13 11:08:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23310 for ; Fri, 13 May 2005 11:08:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEFP4w046194; Fri, 13 May 2005 07:15:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DEFPSN046193; Fri, 13 May 2005 07:15:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEFMoZ046146 for ; Fri, 13 May 2005 07:15:22 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4DEF52u004183; Fri, 13 May 2005 10:15:11 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <01bf01c557a0$ec060ad0$4f85900a@wcwang> References: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> <4284213C.8070000@strongauth.com> <01bf01c557a0$ec060ad0$4f85900a@wcwang> Date: Fri, 13 May 2005 10:15:07 -0400 To: "Wen-Cheng Wang" From: Stephen Kent Subject: Re: key usage - key encipherment or data encipherment Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:48 PM +0800 5/13/05, Wen-Cheng Wang wrote: >I also hesitate to accept the term "key transport", which will >result in over-narrowing down the usage scope of the >keyEncipherment bit. As Arshad pointed out, sometimes >the intention is not to transport the encrypted symmetric key >to anywhere. Besides, it is often that the handshake protocol >is not simply a "key transport" process; it is more often be >a more complex "key exchange" process. For example, >the SSL handshake protocol names it as "key exchange" >instead of "key transport". Would it be valid for a SSL server >cert to be asserted with that keyEncipherment bit? >To avoid the possible dispute on the definition of >similar terms, I would like to suggest to drop the term "key >transport" from the definition of the key usage bit. (However, >I think it is OK to use "key transport" as an example to >explain the the definition of the key usage bit. As commonly employed, a client uses an RSA public key associated with a server to encrypt and transport key bits that will later be used to create encryption and integrity keys for protecting the session. That is an example of key transport. If one used the Diffie-Hellman key agreement option for SSL, that would be accurately be described as a key exchange, but that is rarely the case, in practice. So I am puzzled by the characterization above. Steve From owner-ietf-pkix@mail.imc.org Fri May 13 11:09:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23349 for ; Fri, 13 May 2005 11:09:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEG18w046306; Fri, 13 May 2005 07:16:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DEG1AC046305; Fri, 13 May 2005 07:16:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEFxYi046293 for ; Fri, 13 May 2005 07:16:00 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4DEF52s004183; Fri, 13 May 2005 10:15:08 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 13 May 2005 09:33:16 -0400 To: "Stefan Santesson" From: Stephen Kent Subject: RE: key usage - key encipherment or data encipherment Cc: "Simon McMahon" , , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:52 AM +0100 5/13/05, Stefan Santesson wrote: >How about calling the bits "The encryption bit" and "The other >encryption bit" :-) > >Jokes aside, can anyone recall the justification for having 2 different >bits for key and data encryption? Despite the observation that many folks setting these bits, or applications using these bits, don't really know the difference, there is a difference. From a security perspective, it can be important to know whether the bits being decrypted are data to be handed to a user or app, or keys to be kept within the key management subsystem. Hence there is a legitimate, security benefit that could be obtained IF people set the bits properly. I am hesitant to have us remove this potentially useful distinction merely because folks have not been smart enough to make good use of it so far. Steve From owner-ietf-pkix@mail.imc.org Fri May 13 11:26:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24470 for ; Fri, 13 May 2005 11:26:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEgB1s049141; Fri, 13 May 2005 07:42:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DEgBLK049140; Fri, 13 May 2005 07:42:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEgAbK049130 for ; Fri, 13 May 2005 07:42:10 -0700 (PDT) (envelope-from rtbell@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 May 2005 07:42:05 -0700 X-IronPort-AV: i="3.93,107,1115017200"; d="scan'208"; a="264860157:sNHT30528536" Received: from whoami.cisco.com (IDENT:mirapoint@whoami.cisco.com [64.101.128.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4DEg1Po018198; Fri, 13 May 2005 07:42:02 -0700 (PDT) Received: from rtbellwxp (rcdn-rtbell-3002-2.cisco.com [10.89.25.211]) by whoami.cisco.com (MOS 3.4.5-GR) with ESMTP id AHZ76956; Fri, 13 May 2005 09:42:00 -0500 (CDT) Message-Id: <200505131442.AHZ76956@whoami.cisco.com> From: "Bob Bell" To: "'Stephen Kent'" , "'Stefan Santesson'" Cc: "'Simon McMahon'" , , , , Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 08:41:59 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVXyQoiRToVpBCJR82tTt837yoH+wAAGRzw Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stephen - Just a question for clarification. Since these bits are located in the certificate. How does that translate into knowing without knowledge based on the actual data structure itself that the data encrypted is keying material or data. It would seem to me that the contextual information based on the information exchange is more the determiner of what is intended. The bits in the certificate are to indicate if it is acceptable to use the public key for the stated purpose. At least that is my understanding. If I am wrong, please educate me. Bob Bell > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent > Sent: Friday, May 13, 2005 07:33 > To: Stefan Santesson > Cc: Simon McMahon; Denis.Pinkas@bull.net; > sharon.boeyen@entrust.com; housley@vigilsec.com; ietf-pkix@vpnc.org > Subject: RE: key usage - key encipherment or data encipherment > > > At 11:52 AM +0100 5/13/05, Stefan Santesson wrote: > >How about calling the bits "The encryption bit" and "The other > >encryption bit" :-) > > > >Jokes aside, can anyone recall the justification for having > 2 different > >bits for key and data encryption? > > Despite the observation that many folks setting these bits, > or applications using these bits, don't really know the > difference, there is a difference. From a security > perspective, it can be important to know whether the bits > being decrypted are data to be handed to a user or app, or > keys to be kept within the key management subsystem. Hence > there is a legitimate, security benefit that could be > obtained IF people set the bits properly. > > I am hesitant to have us remove this potentially useful > distinction merely because folks have not been smart enough > to make good use of it so far. > > Steve > From owner-ietf-pkix@mail.imc.org Fri May 13 12:08:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27292 for ; Fri, 13 May 2005 12:08:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DFLxfh052616; Fri, 13 May 2005 08:21:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DFLxSl052615; Fri, 13 May 2005 08:21:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DFLw5K052605 for ; Fri, 13 May 2005 08:21:58 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4DFL42o008303; Fri, 13 May 2005 11:21:06 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505131442.AHZ76956@whoami.cisco.com> References: <200505131442.AHZ76956@whoami.cisco.com> Date: Fri, 13 May 2005 11:20:46 -0400 To: "Bob Bell" From: Stephen Kent Subject: RE: key usage - key encipherment or data encipherment Cc: "'Stefan Santesson'" , "'Simon McMahon'" , , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:41 AM -0600 5/13/05, Bob Bell wrote: >Stephen - > >Just a question for clarification. Since these bits are located in the >certificate. How does that translate into knowing without knowledge based on >the actual data structure itself that the data encrypted is keying material >or data. It would seem to me that the contextual information based on the >information exchange is more the determiner of what is intended. The bits in >the certificate are to indicate if it is acceptable to use the public key >for the stated purpose. At least that is my understanding. If I am wrong, >please educate me. > >Bob Bell > Bob, I can implement crypto software that never releases the bytes decrypted with a private key that appears in a cert which has enabled the "keyEncipherment" but not "dataEncipherment" key usage bits. The intent is that a peer should never have used the public key to encrypt anything but key (or key and associated control info) bits, given the marking. In contrast, if the bytes I receive and decrypt were encrypted using a public key from a cert that has enabled the "dataEncipherment" key usage bit but not the "keyEncipherment" bit, then I would expect to hand these bits to an app, and that would be bad if they were really key bits. Steve From owner-ietf-pkix@mail.imc.org Fri May 13 12:35:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29456 for ; Fri, 13 May 2005 12:35:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DFhcpK054180; Fri, 13 May 2005 08:43:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DFhcdo054179; Fri, 13 May 2005 08:43:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DFhbjV054157 for ; Fri, 13 May 2005 08:43:37 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 16:43:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 16:43:27 +0100 Message-ID: Thread-Topic: key usage - key encipherment or data encipherment Thread-Index: AcVXxk6ZAwVRNk9OR6mrWR0vz+HjEwACx7qw From: "Stefan Santesson" To: "Stephen Kent" Cc: "Simon McMahon" , , , , X-OriginalArrivalTime: 13 May 2005 15:43:32.0051 (UTC) FILETIME=[8412F230:01C557D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4DFhcjV054174 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Steve, Even though I'm not really convinced about the benefits, maybe I should clarify that I don't want to change the bits either for legacy reasons and in order to stay in sync with X.509. I'm fine with the earlier provided wordings. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: den 13 maj 2005 15:33 > To: Stefan Santesson > Cc: Simon McMahon; Denis.Pinkas@bull.net; sharon.boeyen@entrust.com; > housley@vigilsec.com; ietf-pkix@vpnc.org > Subject: RE: key usage - key encipherment or data encipherment > > At 11:52 AM +0100 5/13/05, Stefan Santesson wrote: > >How about calling the bits "The encryption bit" and "The other > >encryption bit" :-) > > > >Jokes aside, can anyone recall the justification for having 2 different > >bits for key and data encryption? > > Despite the observation that many folks setting these bits, or > applications using these bits, don't really know the difference, > there is a difference. From a security perspective, it can be > important to know whether the bits being decrypted are data to be > handed to a user or app, or keys to be kept within the key management > subsystem. Hence there is a legitimate, security benefit that could > be obtained IF people set the bits properly. > > I am hesitant to have us remove this potentially useful distinction > merely because folks have not been smart enough to make good use of > it so far. > > Steve From owner-ietf-pkix@mail.imc.org Fri May 13 13:09:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06025 for ; Fri, 13 May 2005 13:08:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DGLFiV058202; Fri, 13 May 2005 09:21:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DGLFDe058200; Fri, 13 May 2005 09:21:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DGLDOc058173 for ; Fri, 13 May 2005 09:21:14 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA12474; Fri, 13 May 2005 18:35:59 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051318210137:1730 ; Fri, 13 May 2005 18:21:01 +0200 Message-ID: <4284D424.7050509@bull.net> Date: Fri, 13 May 2005 18:21:56 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: <200505131442.AHZ76956@whoami.cisco.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 18:21:01, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 18:21:02, Serialize complete at 13/05/2005 18:21:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve, I wished that what you say would be true, however it isn't. See below. > At 8:41 AM -0600 5/13/05, Bob Bell wrote: >> Stephen - >> Just a question for clarification. Since these bits are located in the >> certificate. How does that translate into knowing without knowledge >> based on >> the actual data structure itself that the data encrypted is keying >> material >> or data. It would seem to me that the contextual information based on the >> information exchange is more the determiner of what is intended. The >> bits in >> the certificate are to indicate if it is acceptable to use the public key >> for the stated purpose. At least that is my understanding. If I am wrong, >> please educate me. >> Bob Bell > Bob, > I can implement crypto software that never releases the bytes decrypted > with a private key that appears in a cert which has enabled the > "keyEncipherment" but not "dataEncipherment" key usage bits. The intent > is that a peer should never have used the public key to encrypt anything > but key (or key and associated control info) bits, given the marking. In > contrast, if the bytes I receive and decrypt were encrypted using a > public key from a cert that has enabled the "dataEncipherment" key usage > bit but not the "keyEncipherment" bit, then I would expect to hand these > bits to an app, and that would be bad if they were really key bits. At this time someone who uses a certificate that has the key usage keyEncipherment set cannot know whether the "keying material" can be released or not by the receiving application (that owns the private key). Let us look what PKCS#11 states about the mapping of X.509 key usage flags to cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP: Table 35, Mapping of X.509 key usage flags to cryptoki attributes for private keys Key usage flags for public keys Corresponding cryptoki attributes in X.509 public key certificates for private keys dataEncipherment CKA_DECRYPT keyAgreement CKA_DERIVE keyEncipherment CKA_UNWRAP C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private key or secret key object. The CKA_UNWRAP attribute of the unwrapping key, which indicates whether the key supports unwrapping, must be TRUE. The new key will have the CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the CKA_NEVER_EXTRACTABLE attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default set to TRUE. It would be "nice" to be able to distinguish between C_UnwrapKey where the secret cannot be extractable and where it can be. We would then be able to distinguish between: keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE I would thus propose to be able to support that distinction. Denis > Steve From owner-ietf-pkix@mail.imc.org Fri May 13 14:27:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11894 for ; Fri, 13 May 2005 14:27:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DHcJxR066981; Fri, 13 May 2005 10:38:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DHcJDR066980; Fri, 13 May 2005 10:38:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DHcIFk066973 for ; Fri, 13 May 2005 10:38:19 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (PPP-219.65.51.98.mum2.dialup.vsnl.net.in [219.65.51.98] (may be forged)) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4DHcEAo018299 for ; Fri, 13 May 2005 13:38:16 -0400 From: "Santosh Chokhani" To: Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 13:38:08 -0400 Message-ID: <025601c557e2$8be1bea0$6e3341db@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit To add to what Steve Kent has said in this e-mail, there is a separate bit for D-H type protocols. It is called keyAgreement. I also agree with Steve's other posting of maintaining the distinction between key encihperment and data encipherment. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Friday, May 13, 2005 10:15 AM To: Wen-Cheng Wang Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment At 5:48 PM +0800 5/13/05, Wen-Cheng Wang wrote: >I also hesitate to accept the term "key transport", which will result >in over-narrowing down the usage scope of the keyEncipherment bit. As >Arshad pointed out, sometimes the intention is not to transport the >encrypted symmetric key to anywhere. Besides, it is often that the >handshake protocol is not simply a "key transport" process; it is more >often be a more complex "key exchange" process. For example, >the SSL handshake protocol names it as "key exchange" >instead of "key transport". Would it be valid for a SSL server >cert to be asserted with that keyEncipherment bit? >To avoid the possible dispute on the definition of >similar terms, I would like to suggest to drop the term "key >transport" from the definition of the key usage bit. (However, >I think it is OK to use "key transport" as an example to >explain the the definition of the key usage bit. As commonly employed, a client uses an RSA public key associated with a server to encrypt and transport key bits that will later be used to create encryption and integrity keys for protecting the session. That is an example of key transport. If one used the Diffie-Hellman key agreement option for SSL, that would be accurately be described as a key exchange, but that is rarely the case, in practice. So I am puzzled by the characterization above. Steve From owner-ietf-pkix@mail.imc.org Fri May 13 16:20:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04778 for ; Fri, 13 May 2005 16:20:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DJZ4PX078112; Fri, 13 May 2005 12:35:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DJZ4Cv078111; Fri, 13 May 2005 12:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4DJZ0XB078103 for ; Fri, 13 May 2005 12:35:01 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 27613 invoked by uid 0); 13 May 2005 19:34:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.56) by woodstock.binhost.com with SMTP; 13 May 2005 19:34:54 -0000 Message-Id: <6.2.1.2.2.20050513152934.0610d910@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 13 May 2005 15:34:56 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: ietf-pkix@imc.org In-Reply-To: <42845E58.6010502@bull.net> References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> <42832509.5020001@bull.net> <6.2.1.2.2.20050512105428.060f0210@mail.binhost.com> <42845E58.6010502@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: >The distinction between "the CRL" and "a CRL" is pretty important. So we have identified another are where we disagree. The CRL AIA extension applies to a CRL that the certificate user has already selected. Russ From owner-ietf-pkix@mail.imc.org Fri May 13 22:55:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04466 for ; Fri, 13 May 2005 22:55:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4E1qbkq005390; Fri, 13 May 2005 18:52:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4E1qb5G005389; Fri, 13 May 2005 18:52:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from hosting2.fastq.com (hosting2.fastq.com [65.39.66.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4E1qab9005383 for ; Fri, 13 May 2005 18:52:36 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: (qmail 52788 invoked from network); 14 May 2005 01:52:35 -0000 Received: from dslstat-ppp-150.fastq.com (HELO MMyersLapTop) (65.39.92.150) by hosting2.fastq.com with SMTP; 14 May 2005 01:52:35 -0000 From: "Michael Myers" To: Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 18:49:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I concur with Steve's observation. The potential utility outweighs current deficiencies. Mike -----Original Message----- From: Stephen Kent Sent: Friday, May 13, 2005 6:33 AM > > . . . > > I am hesitant to have us remove this potentially > useful distinction merely because folks have not > been smart enough to make good use of it so far. > > Steve From owner-ietf-pkix@mail.imc.org Sun May 15 02:25:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07757 for ; Sun, 15 May 2005 02:25:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F5d77q090869; Sat, 14 May 2005 22:39:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4F5d7KV090868; Sat, 14 May 2005 22:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F5d0wP090774 for ; Sat, 14 May 2005 22:39:07 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 6629A348BA; Sun, 15 May 2005 17:38:59 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10945-17; Sun, 15 May 2005 17:38:59 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 8AE1C34421; Sun, 15 May 2005 17:38:58 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3B1A237742; Sun, 15 May 2005 17:38:58 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXBqB-0003Tr-00; Sun, 15 May 2005 17:39:03 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, mars@seguridata.com Subject: RE: key usage - key encipherment or data encipherment In-Reply-To: <000d01c5564d$c4a93060$d600a8c0@seguridata.com> Message-Id: Date: Sun, 15 May 2005 17:39:03 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Miguel A Rodriguez" writes: >Does anyone use dataEncipherment? That depends on which question you're asking. Lots of people use dataEncipherment, but I've never found anyone who uses dataEncipherment the way it's meant to be used (whenever I see it used I try and find out from the original user what they're doing with it. It's never for the X.509 definition of dataEncipherment). So the answer is both yes and no. Peter. From owner-ietf-pkix@mail.imc.org Sun May 15 04:54:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19703 for ; Sun, 15 May 2005 04:54:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F85MKb050946; Sun, 15 May 2005 01:05:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4F85M8H050938; Sun, 15 May 2005 01:05:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F85Gw7050906 for ; Sun, 15 May 2005 01:05:17 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 386D7355BB; Sun, 15 May 2005 20:05:15 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08989-29; Sun, 15 May 2005 20:05:15 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 5746D355B8; Sun, 15 May 2005 20:05:14 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 1EA1B37742; Sun, 15 May 2005 20:05:14 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXE7k-0003bt-00; Sun, 15 May 2005 20:05:20 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, Simon_McMahon@health.qld.gov.au Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: Message-Id: Date: Sun, 15 May 2005 20:05:20 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Simon McMahon" writes: >They were calling an 'encrypt' function to encrypt XML data and they gave it >an RSA key (the cert actually) to do it. Of course it internally made an AES >key but they never saw it until the interoperability issue made them look. >From what they saw at the level they were looking the interpretation was >reasonable. When I originally saw your posting I thought that what they were doing was a typical clueless-user action, but on thinking about it a bit more it's actually quite logical. Unless you're intimately familiar with the crypto involved, it's quite sensible to use dataEncryption to mean, well, data encryption (in the way you describe above). >In my opinion there are 3 cases presented as 2 in the RFC. > >1. RSA encrypts data - hardly ever used. >2. RSA implicitly encrypts keys so it can really encrypt bulk data - common > usage. >3. RSA explicitly encrypts keys for explicit key management functions - > common usage. > >The current bits separate 1 from 2/3 yet people make the interpretation that >they split the more common 2 from 3 assuming 1 and 2 are the same thing. Yup. It's like the old digitalSignature vs. nonRepudiation bits, no-one could actually clearly define what nonRepudiation did, which is why it was changed to the current contentCommitment. So now we have: digitalSignature = ephemeral signatures (e.g. for authentication to an online server). nonRepudiation = long-term signature (e.g. for document signatures). The logical corollary from this is to set: keyEncipherment = ephemeral session key establishment (e.g. SSL). dataEncipherment = content-encryption key establishment (e.g. S/MIME). Since everyone that's using dataEncipherment is using it for that anyway, it clarifies the situation and requires no change in existing apps. (As for real raw data-encipherment, if anyone is actually using that, give them a new flag contentEncapsulation or something with a name that can't be confused with anything else). >In my opinion this problem will not entirely go away by clarifying the >standard because most people dont read it before they implement something. >The two bits are there and as long as they are both there then the mistake >will be made by busy developers. Unenforceable key-usage policy, to "public" >keys, will also continue to be implemented. People will come looking for >clarification once they have an interoperability issue but by then it is >often too late - the issue usually gets decided by who has the biggest >corporate balls. In this case it wasn't too late so thanks for the >assistance. Yup, that's a perfect summary of the current situation. I don't know if I'm too happy with combining the bits, the crypto-purist in me wants to keep a distinction between SSL vs. S/MIME-type keys for access control purposes, but the practical part of me says this will never work, because there's no way for a user (even if they do know the difference in key types, which very few do) to be able to manage this in any way via a crypto API. The standard crypto API has some form of "gimme a key" function that returns a key for a particular user. Some of the more sophisticated ones extend this to "gimme a key usable for encryption" (although the best known, CryptoAPI, allows you to use an encryption-only key for signatures because so many users can't understand anything other than a one-size-fits-all key). None that I'm aware of (and I've used quite a few) allow you to specify the usage of a key for short-term but not long-term signatures, or session vs. data-encryption key management. The only thing they understand is "sign" and "encrypt". So even if you clarify keyEncipherment and dataEncipherment, there's no way to manage the usage in any known CryptoAPI. The best the crypto software vendor can do at that point is to leave it to the end user to check that when they call "encrypt" to encrypt an ephemeral key, the associated cert isn't set up to only encrypt a content-encryption key. I'll leave readers to decide what the chances are of that ever working. Peter. From owner-ietf-pkix@mail.imc.org Sun May 15 04:59:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20257 for ; Sun, 15 May 2005 04:59:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F86YYk051390; Sun, 15 May 2005 01:06:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4F86XAs051385; Sun, 15 May 2005 01:06:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F86Qd1051348 for ; Sun, 15 May 2005 01:06:27 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 1BDBB3565B; Sun, 15 May 2005 20:06:26 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08405-26; Sun, 15 May 2005 20:06:26 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 96C1635633; Sun, 15 May 2005 20:06:24 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 469F237742; Sun, 15 May 2005 20:06:24 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXE8s-0003c4-00; Sun, 15 May 2005 20:06:30 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: andrewsciberras@gmail.com, pgut001@cs.auckland.ac.nz, Simon_McMahon@health.qld.gov.au, wcwang@cht.com.tw Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <01a701c556b4$1987f650$4f85900a@wcwang> Message-Id: Date: Sun, 15 May 2005 20:06:30 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Wen-Cheng Wang" writes: >However, I worried that the statement "This (dataEncipherment) bit MUST NOT >be set when the intention is to encipher intermediate cryptographic keys >rather than raw user data" might mislead the reader to believe that the >keyEncipherment bit and the dataEncipherment bit are mutually exclusive. >Therefore, I suggest to revise the statement as "The dataEncipherment bit >should not be use to represent the intention of allowing enciphering >intermediate cryptographic keys. In that case, the keyEncipherment bit should >be set." Thanks, that change helps clarify the text. Peter. From owner-ietf-pkix@mail.imc.org Sun May 15 05:09:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21229 for ; Sun, 15 May 2005 05:09:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F8RopU058183; Sun, 15 May 2005 01:27:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4F8RonZ058182; Sun, 15 May 2005 01:27:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F8RnE0058171 for ; Sun, 15 May 2005 01:27:49 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 03CA234BA1; Sun, 15 May 2005 20:27:49 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17106-20; Sun, 15 May 2005 20:27:48 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id C690134000; Sun, 15 May 2005 20:27:47 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 63A3A37742; Sun, 15 May 2005 20:27:47 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXETZ-0003eY-00; Sun, 15 May 2005 20:27:53 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, kent@bbn.com Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <4284D424.7050509@bull.net> Message-Id: Date: Sun, 15 May 2005 20:27:53 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas writes: >Let us look what PKCS#11 states about the mapping of X.509 key usage flags to >cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP: Note that this usage is entirely dependent on the user. PKCS #11 sets no constraints based on the cert contents. Experience has shown that the PKCS #11 flags set by the user often bear no relation to the key flags in the cert, with keys with signature-only certs being usable for encryption and vice versa. It's not small-scale stuff either, this sort of thing goes all the way up to the European national-CA level (this isn't a purely European disease, but smart cards seem to be a lot more widely used over there, so it's more noticeable). >Key usage flags for public keys Corresponding cryptoki attributes in X.509 >public key certificates for private keys > >dataEncipherment CKA_DECRYPT >keyAgreement CKA_DERIVE >keyEncipherment CKA_UNWRAP Even that is merely theoretical guidance, since there's a lot of confusion between decryption and unwrapping keys - some apps mark keys as being for decryption and some for unwrapping. What you do is you try a decrypt first, and if that fails you try an unwrap with a CKO_SECRET_KEY of type CKK_GENERIC_SECRET, which returns the entire decrypted value, making the unwrap equivalent to a straight decrypt. So even here where you've got provision for key-wrap vs. data-encrypt, (a) it's frequently not mapped from the certificate to the PKCS #11 level and (b) even if it were, it's common practice to apply both operations in a manner that makes them equivalent, in order to handle with the way existing apps do things. Peter. From owner-ietf-pkix@mail.imc.org Sun May 15 16:03:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03826 for ; Sun, 15 May 2005 16:03:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FJGJm4075191; Sun, 15 May 2005 12:16:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4FJGJGj075190; Sun, 15 May 2005 12:16:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4FJGHe0075181 for ; Sun, 15 May 2005 12:16:17 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8039 invoked by uid 0); 15 May 2005 19:16:09 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.92.68) by woodstock.binhost.com with SMTP; 15 May 2005 19:16:09 -0000 Message-Id: <6.2.1.2.2.20050515151459.05940600@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 15 May 2005 15:16:12 -0400 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), Simon_McMahon@health.qld.gov.au From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter: This would be quite a change from the current meaning of the bits, not a clarification. I do not support such a change. Russ At 04:05 AM 5/15/2005, Peter Gutmann wrote: >"Simon McMahon" writes: > > >They were calling an 'encrypt' function to encrypt XML data and they gave it > >an RSA key (the cert actually) to do it. Of course it internally made an AES > >key but they never saw it until the interoperability issue made them look. > >From what they saw at the level they were looking the interpretation was > >reasonable. > >When I originally saw your posting I thought that what they were doing was a >typical clueless-user action, but on thinking about it a bit more it's >actually quite logical. Unless you're intimately familiar with the crypto >involved, it's quite sensible to use dataEncryption to mean, well, data >encryption (in the way you describe above). > > >In my opinion there are 3 cases presented as 2 in the RFC. > > > >1. RSA encrypts data - hardly ever used. > >2. RSA implicitly encrypts keys so it can really encrypt bulk data - common > > usage. > >3. RSA explicitly encrypts keys for explicit key management functions - > > common usage. > > > >The current bits separate 1 from 2/3 yet people make the interpretation that > >they split the more common 2 from 3 assuming 1 and 2 are the same thing. > >Yup. It's like the old digitalSignature vs. nonRepudiation bits, no-one could >actually clearly define what nonRepudiation did, which is why it was changed >to the current contentCommitment. So now we have: > > digitalSignature = ephemeral signatures (e.g. for authentication to an > online server). > > nonRepudiation = long-term signature (e.g. for document signatures). > >The logical corollary from this is to set: > > keyEncipherment = ephemeral session key establishment (e.g. SSL). > > dataEncipherment = content-encryption key establishment (e.g. S/MIME). > >Since everyone that's using dataEncipherment is using it for that anyway, it >clarifies the situation and requires no change in existing apps. > >(As for real raw data-encipherment, if anyone is actually using that, give > them a new flag contentEncapsulation or something with a name that can't be > confused with anything else). > > >In my opinion this problem will not entirely go away by clarifying the > >standard because most people dont read it before they implement something. > >The two bits are there and as long as they are both there then the mistake > >will be made by busy developers. Unenforceable key-usage policy, to "public" > >keys, will also continue to be implemented. People will come looking for > >clarification once they have an interoperability issue but by then it is > >often too late - the issue usually gets decided by who has the biggest > >corporate balls. In this case it wasn't too late so thanks for the > >assistance. > >Yup, that's a perfect summary of the current situation. I don't know if I'm >too happy with combining the bits, the crypto-purist in me wants to keep a >distinction between SSL vs. S/MIME-type keys for access control purposes, but >the practical part of me says this will never work, because there's no way for >a user (even if they do know the difference in key types, which very few do) >to be able to manage this in any way via a crypto API. > >The standard crypto API has some form of "gimme a key" function that returns a >key for a particular user. Some of the more sophisticated ones extend this to >"gimme a key usable for encryption" (although the best known, CryptoAPI, >allows you to use an encryption-only key for signatures because so many users >can't understand anything other than a one-size-fits-all key). None that I'm >aware of (and I've used quite a few) allow you to specify the usage of a key >for short-term but not long-term signatures, or session vs. data-encryption >key management. The only thing they understand is "sign" and "encrypt". So >even if you clarify keyEncipherment and dataEncipherment, there's no way to >manage the usage in any known CryptoAPI. > >The best the crypto software vendor can do at that point is to leave it to the >end user to check that when they call "encrypt" to encrypt an ephemeral key, >the associated cert isn't set up to only encrypt a content-encryption key. >I'll leave readers to decide what the chances are of that ever working. > >Peter. From owner-ietf-pkix@mail.imc.org Sun May 15 21:20:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08844 for ; Sun, 15 May 2005 21:20:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G0Rqhu095648; Sun, 15 May 2005 17:27:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4G0Rq57095647; Sun, 15 May 2005 17:27:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G0RlTh095638 for ; Sun, 15 May 2005 17:27:48 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Mon, 16 May 2005 10:25:11 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Mon, 16 May 2005 10:25:11 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Mon, 16 May 2005 10:25:01 +1000 From: "Simon McMahon" To: "<\"Wen-Cheng Wang\"" Cc: "<" Subject: RE: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4G0RmTh095640 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Wen-Cheng Wang's last post looks OK to me but I would drop "RSA" and "content-decryption" from the example. I still don't see how an RSA public key can directly encrypt a private key, unless its heaps smaller, so I dropped that from the example too. 'Private' keys are also 'secret' keys anyway. I didn't change 'dataEncipherment' from Wang's post. proposed text: The keyEncipherment bit is asserted when the subject public key is used for enciphering cryptographic keys or keying materials. For example, this bit shall be set when a RSA public key is to be used for key transport that involves encrypting a secret key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data, other than cryptographic keys or keying materials, without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish shared cryptographic keys. The 'note' at the end of dataEncipherment effectively deprecates this bit but I'm sure it will continue to see many more interoperability issues in the future. I think that Peter's observation: keyEncipherment = ephemeral session key establishment (e.g. SSL). dataEncipherment = content-encryption key establishment (e.g. S/MIME). Is what industry will continue to do regardless of the RFC text since a bit that is there with no obvious use may as well get used for something. The 'PIN' reference from another post was another good grey area that can justify the use of either bit however the RFC gets worded. The overloading of the bits to imply security policy for the private key's decryption op is the riskiest use of these bits but will obviously continue too. The bits, as defined by the RFC, obviously don't matter very much to PKI security which is why no-one could nail down what they actually mean and industry usage varies so widely. They are just an interoperability issue waiting to happen (again). Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** From owner-ietf-pkix@mail.imc.org Mon May 16 04:08:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08391 for ; Mon, 16 May 2005 04:08:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G6tEjR059688; Sun, 15 May 2005 23:55:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4G6tEpS059687; Sun, 15 May 2005 23:55:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G6tC6N059668 for ; Sun, 15 May 2005 23:55:12 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 0AF6C3460A; Mon, 16 May 2005 18:55:11 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13795-16; Mon, 16 May 2005 18:55:10 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 9A5CE33F52; Mon, 16 May 2005 18:55:10 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 679C43774A; Mon, 16 May 2005 18:55:10 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXZVU-0005gZ-00; Mon, 16 May 2005 18:55:16 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, pgut001@cs.auckland.ac.nz, Simon_McMahon@health.qld.gov.au Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <6.2.1.2.2.20050515151459.05940600@mail.binhost.com> Message-Id: Date: Mon, 16 May 2005 18:55:16 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >This would be quite a change from the current meaning of the bits, not a >clarification. Well, it would change the current text describing the bits, but not the way the bits are being used in practice. In other words the changed text would then match the way the bits are actually being used. It'd resolve the ambiguity and fix the current problem in a single step. Peter. From owner-ietf-pkix@mail.imc.org Mon May 16 10:25:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18284 for ; Mon, 16 May 2005 10:25:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GDQqFT091400; Mon, 16 May 2005 06:26:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GDQqM6091399; Mon, 16 May 2005 06:26:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from 21cn.com (send.forptr.21cn.com [202.105.45.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4GDQFq7091352 for ; Mon, 16 May 2005 06:26:48 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6 P2) with SMTP id jm94288d637; Mon, 16 May 2005 21:28:11 +0800 Received: from 21cn.com([10.2.1.9]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Mon, 16 May 2005 21:28:11 +0800 Received: from above.proper.com([10.2.100.8]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm904283ba6f; Fri, 13 May 2005 03:27:30 +0800 Received: from above.proper.com([208.184.76.39]) by 21cn.com(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 13 May 2005 03:20:21 +0800 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJL7jP010841; Thu, 12 May 2005 12:21:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CJL7DZ010840; Thu, 12 May 2005 12:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CJL6Gt010834 for ; Thu, 12 May 2005 12:21:06 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8024 invoked by uid 0); 12 May 2005 19:20:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.201) by woodstock.binhost.com with SMTP; 12 May 2005 19:20:59 -0000 Message-Id: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 15:21:02 -0400 To: ietf-pkix@vpnc.org From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Archive: List-ID: List-Unsubscribe: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-pkix@mail.imc.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: housley@vigilsec.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ From owner-ietf-pkix@mail.imc.org Mon May 16 12:12:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03782 for ; Mon, 16 May 2005 12:12:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GFDoYD005379; Mon, 16 May 2005 08:13:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GFDot1005378; Mon, 16 May 2005 08:13:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GFDnvS005372 for ; Mon, 16 May 2005 08:13:50 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-127-143.res.east.verizon.net [70.21.127.143]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4GFDkff018520; Mon, 16 May 2005 11:13:47 -0400 From: "Santosh Chokhani" To: "'Russ Housley'" , Subject: RE: key usage - key encipherment or data encipherment Date: Mon, 16 May 2005 11:13:41 -0400 Message-ID: <008501c55a29$db9b3c70$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GFDovS005373 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Russ, Looks good except the "intermediate symmetric cipher" in the last paragraph should be "symmetric cipher" since the symmetric cipher in most cases in not "intermediate". Another alternative is to use the term "intermediate asymmetric cipher", but that might be confusing. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 3:21 PM To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ From owner-ietf-pkix@mail.imc.org Mon May 16 14:10:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19069 for ; Mon, 16 May 2005 14:10:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GHQgqh016776; Mon, 16 May 2005 10:26:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GHQgF1016775; Mon, 16 May 2005 10:26:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GHQfLG016766 for ; Mon, 16 May 2005 10:26:41 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4GHQZRi014530 for ; Mon, 16 May 2005 13:26:35 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4GHQWXn108540 for ; Mon, 16 May 2005 13:26:35 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4GHQVpR030800 for ; Mon, 16 May 2005 13:26:31 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4GHQVJG030762; Mon, 16 May 2005 13:26:31 -0400 In-Reply-To: <008501c55a29$db9b3c70$9a00a8c0@hq.orionsec.com> To: "Santosh Chokhani" Cc: "'Russ Housley'" , ietf-pkix@vpnc.org MIME-Version: 1.0 Subject: RE: key usage - key encipherment or data encipherment X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Mon, 16 May 2005 13:26:26 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/16/2005 13:26:29, Serialize complete at 05/16/2005 13:26:30, Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/16/2005 13:26:30 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It should probably just be "without the use of any symmetric cipher", instead of wondering whether it's intermediate or not. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/16/2005 11:13 AM To: "'Russ Housley'" , cc: Subject: RE: key usage - key encipherment or data encipherment Russ, Looks good except the "intermediate symmetric cipher" in the last paragraph should be "symmetric cipher" since the symmetric cipher in most cases in not "intermediate". Another alternative is to use the term "intermediate asymmetric cipher", but that might be confusing. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 3:21 PM To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ From owner-ietf-pkix@mail.imc.org Mon May 16 18:51:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10516 for ; Mon, 16 May 2005 18:51:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GLwiXW039317; Mon, 16 May 2005 14:58:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GLwika039316; Mon, 16 May 2005 14:58:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GLwglj039305 for ; Mon, 16 May 2005 14:58:42 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [10.84.131.244] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4GLw12o010739; Mon, 16 May 2005 17:58:04 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4284D424.7050509@bull.net> References: <200505131442.AHZ76956@whoami.cisco.com> <4284D424.7050509@bull.net> Date: Mon, 16 May 2005 17:58:00 -0400 To: Denis Pinkas From: Stephen Kent Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 6:21 PM +0200 5/13/05, Denis Pinkas wrote: >Steve, > >I wished that what you say would be true, however it isn't. See below. > >>At 8:41 AM -0600 5/13/05, Bob Bell wrote: > >>>Stephen - > >>>Just a question for clarification. Since these bits are located in the >>>certificate. How does that translate into knowing without knowledge based on >>>the actual data structure itself that the data encrypted is keying material >>>or data. It would seem to me that the contextual information based on the >>>information exchange is more the determiner of what is intended. The bits in >>>the certificate are to indicate if it is acceptable to use the public key >>>for the stated purpose. At least that is my understanding. If I am wrong, >>>please educate me. > >>>Bob Bell > >>Bob, > >>I can implement crypto software that never releases the bytes >>decrypted with a private key that appears in a cert which has >>enabled the "keyEncipherment" but not "dataEncipherment" key usage >>bits. The intent is that a peer should never have used the public >>key to encrypt anything but key (or key and associated control >>info) bits, given the marking. In contrast, if the bytes I receive >>and decrypt were encrypted using a public key from a cert that has >>enabled the "dataEncipherment" key usage bit but not the >>"keyEncipherment" bit, then I would expect to hand these bits to an >>app, and that would be bad if they were really key bits. > >At this time someone who uses a certificate that has the key usage >keyEncipherment set cannot know whether the "keying material" can be >released or not by the receiving application (that owns the private >key). that's true. >Let us look what PKCS#11 states about the mapping of X.509 key usage >flags to cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP: > >Table 35, Mapping of X.509 key usage flags to cryptoki attributes >for private keys > >Key usage flags for public keys Corresponding cryptoki attributes >in X.509 public key certificates for private keys > >dataEncipherment CKA_DECRYPT >keyAgreement CKA_DERIVE >keyEncipherment CKA_UNWRAP > >C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private >key or secret key object. > >The CKA_UNWRAP attribute of the unwrapping key, which indicates whether >the key supports unwrapping, must be TRUE. The new key will have the >CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the CKA_NEVER_EXTRACTABLE >attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default set to >TRUE. > > It would be "nice" to be able to distinguish between C_UnwrapKey where > the secret cannot be extractable and where it can be. > > We would then be able to distinguish between: > > keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE > keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE > > I would thus propose to be able to support that distinction. yes, this distinction would be nice, but Peter's messages suggests that PKCS #11 code does not really pay much attention to the key usage bits anyway. so, it does not seem worht pursuing. Steve From owner-ietf-pkix@mail.imc.org Mon May 16 19:54:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17648 for ; Mon, 16 May 2005 19:54:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GN4WMp043798; Mon, 16 May 2005 16:04:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GN4V4U043797; Mon, 16 May 2005 16:04:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GN4TKG043785 for ; Mon, 16 May 2005 16:04:30 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Tue, 17 May 2005 09:03:17 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Tue, 17 May 2005 09:03:16 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Tue, 17 May 2005 09:03:05 +1000 From: "Simon McMahon" To: , Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GN4VKG043792 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The example for 'keyEncipherment' should not include an "RSA public key encrypting an asymmetric private key", which, if it is also RSA is too big to encrypt with the public key. Surely, an RFC shouldn't list impossible cases as examples. Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Russ Housley 05/13/05 05:21am >>> There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** From owner-ietf-pkix@mail.imc.org Tue May 17 04:34:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23162 for ; Tue, 17 May 2005 04:34:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H7gixE041254; Tue, 17 May 2005 00:42:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4H7giq7041253; Tue, 17 May 2005 00:42:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H7gfE6041229 for ; Tue, 17 May 2005 00:42:42 -0700 (PDT) (envelope-from diegofv@eresmas.com) Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 1DXwid-0005jL-00; Tue, 17 May 2005 09:42:23 +0200 From: To: Simon_McMahon@health.qld.gov.au Cc: housley@vigilsec.com, ietf-pkix@vpnc.org Message-ID: Date: Tue, 17 May 2005 07:42:24 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: RE: Re: key usage - key encipherment or data encipherment X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit ----- Mensaje Original ----- Remitente: "Simon McMahon" Simon_McMahon@health.qld.gov.au Destinatario: housley@vigilsec.com, ietf-pkix@vpnc.org Fecha: Martes, Mayo 17, 2005 1:03am Asunto: Re: key usage - key encipherment or data encipherment > >The example for 'keyEncipherment' should not include an "RSA public >key encrypting an asymmetric private key", which, if it is also RSA >is too big to encrypt with the public key. Surely, an RFC shouldn't >list impossible cases as examples. > From owner-ietf-pkix@mail.imc.org Tue May 17 05:36:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28147 for ; Tue, 17 May 2005 05:36:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H8jZCY062218; Tue, 17 May 2005 01:45:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4H8jZ7b062217; Tue, 17 May 2005 01:45:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H8jXNq062163 for ; Tue, 17 May 2005 01:45:34 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA36660; Tue, 17 May 2005 11:00:20 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051710451824:70 ; Tue, 17 May 2005 10:45:18 +0200 Message-ID: <4289AF59.4030500@bull.net> Date: Tue, 17 May 2005 10:46:17 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@vpnc.org, Burt Kaliski Subject: Improving PKCS#11 References: <200505131442.AHZ76956@whoami.cisco.com> <4284D424.7050509@bull.net> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/05/2005 10:45:18, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/05/2005 10:45:20, Serialize complete at 17/05/2005 10:45:20 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve (and Burt), I concur with you and Peter that PKCS#11 is not currently enforcing an appropriate key protection against key extraction, but this could be easily improved. Maybe RSA Security would like to improve PKCS#11 ? If PKCS#11 gets improved, then we could distinguish between: keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE Denis > At 6:21 PM +0200 5/13/05, Denis Pinkas wrote: > >> Steve, >> >> I wished that what you say would be true, however it isn't. See below. >> >>> At 8:41 AM -0600 5/13/05, Bob Bell wrote: >> >> >>>> Stephen - >>> >> >>>> Just a question for clarification. Since these bits are located in the >>>> certificate. How does that translate into knowing without knowledge >>>> based on >>>> the actual data structure itself that the data encrypted is keying >>>> material >>>> or data. It would seem to me that the contextual information based >>>> on the >>>> information exchange is more the determiner of what is intended. The >>>> bits in >>>> the certificate are to indicate if it is acceptable to use the >>>> public key >>>> for the stated purpose. At least that is my understanding. If I am >>>> wrong, >>>> please educate me. >>> >> >>>> Bob Bell >>> >> >>> Bob, >> >> >>> I can implement crypto software that never releases the bytes >>> decrypted with a private key that appears in a cert which has enabled >>> the "keyEncipherment" but not "dataEncipherment" key usage bits. The >>> intent is that a peer should never have used the public key to >>> encrypt anything but key (or key and associated control info) bits, >>> given the marking. In contrast, if the bytes I receive and decrypt >>> were encrypted using a public key from a cert that has enabled the >>> "dataEncipherment" key usage bit but not the "keyEncipherment" bit, >>> then I would expect to hand these bits to an app, and that would be >>> bad if they were really key bits. >> >> >> At this time someone who uses a certificate that has the key usage >> keyEncipherment set cannot know whether the "keying material" can be >> released or not by the receiving application (that owns the private key). > > > that's true. > >> Let us look what PKCS#11 states about the mapping of X.509 key usage >> flags to cryptoki attributes for private keys for CKA_DECRYPT and >> CKA_UNWRAP: >> >> Table 35, Mapping of X.509 key usage flags to cryptoki attributes >> for private keys >> >> Key usage flags for public keys Corresponding cryptoki attributes >> in X.509 public key certificates for private keys >> >> dataEncipherment CKA_DECRYPT >> keyAgreement CKA_DERIVE >> keyEncipherment CKA_UNWRAP >> >> C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private >> key or secret key object. >> >> The CKA_UNWRAP attribute of the unwrapping key, which indicates whether >> the key supports unwrapping, must be TRUE. The new key will have the >> CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the >> CKA_NEVER_EXTRACTABLE >> attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default >> set to >> TRUE. >> >> It would be "nice" to be able to distinguish between C_UnwrapKey where >> the secret cannot be extractable and where it can be. >> >> We would then be able to distinguish between: >> >> keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE >> keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE >> >> I would thus propose to be able to support that distinction. > > > yes, this distinction would be nice, but Peter's messages suggests that > PKCS #11 code does not really pay much attention to the key usage bits > anyway. so, it does not seem worht pursuing. > > Steve > > > From owner-ietf-pkix@mail.imc.org Tue May 17 06:16:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03048 for ; Tue, 17 May 2005 06:16:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H9W4bI078482; Tue, 17 May 2005 02:32:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4H9W4JR078481; Tue, 17 May 2005 02:32:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H9W2Ru078467 for ; Tue, 17 May 2005 02:32:03 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id CE8383551E; Tue, 17 May 2005 21:32:01 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08014-22; Tue, 17 May 2005 21:32:01 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id C25B2355BA; Tue, 17 May 2005 21:31:59 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 677F137746; Tue, 17 May 2005 21:31:59 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXyQo-00077W-00; Tue, 17 May 2005 21:32:06 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, kent@bbn.com Subject: Re: Improving PKCS#11 Cc: BKaliski@rsasecurity.com, ietf-pkix@vpnc.org In-Reply-To: <4289AF59.4030500@bull.net> Message-Id: Date: Tue, 17 May 2005 21:32:06 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas writes: >If PKCS#11 gets improved, then we could distinguish between: > > keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE > keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE I can't see that ever being added. If you want to make it unextractable in the user app, set the CKA_EXTRACTABLE flag in the key template to false (this is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE). If the hardware makes it unextractable (e.g. in Fortezza cards), it'll implicitly set CKA_EXTRACTABLE for you. There are also practical considerations. The reason for the common use of DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage, what'd you'd be asking there is for app developers to break compatibility with all existing drivers in exchange for a gain so abstruse that most of them won't even understand why it's there. An addition, given the longevity of crypto hardware devices, even if vendors (for some reason) decided to do this, it'd take years for everything to implement it. Finally, some hardware (e.g. many smart cards) can't support this, since all the card can usefully do is the private-key op. As a result the unwrapped key is always extractable from the card, either because it doesn't do symmetric crypto at all, because it does it in a crippled manner that makes it useless (e.g. it zeroes all but 40 bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or even if it does do symmetric crypto, it's so slow that it's unusable. So CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be overridden by the hardware. Peter. From owner-ietf-pkix@mail.imc.org Tue May 17 09:19:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21196 for ; Tue, 17 May 2005 09:19:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HCQRWD040025; Tue, 17 May 2005 05:26:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4HCQRIg040024; Tue, 17 May 2005 05:26:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HCQPVt039978 for ; Tue, 17 May 2005 05:26:26 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA44950; Tue, 17 May 2005 14:41:00 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051714255652:181 ; Tue, 17 May 2005 14:25:56 +0200 Message-ID: <4289E310.9020407@bull.net> Date: Tue, 17 May 2005 14:26:56 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Gutmann CC: kent@bbn.com, BKaliski@rsasecurity.com, ietf-pkix@vpnc.org Subject: Re: Improving PKCS#11 References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/05/2005 14:25:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/05/2005 14:26:04, Serialize complete at 17/05/2005 14:26:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, >>If PKCS#11 gets improved, then we could distinguish between: >> keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE >> keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE > I can't see that ever being added. If you want to make it unextractable in > the user app, No. The purpose is to make impossible, whatever the user application asks, to extract the private key in the clear. > set the CKA_EXTRACTABLE flag in the key template to false (this > is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE). If the hardware makes > it unextractable (e.g. in Fortezza cards), it'll implicitly set > CKA_EXTRACTABLE for you. The hardware cannot do anything since currently the setting of the flag CKA_EXTRACTABLE is left to the application. > There are also practical considerations. The reason for the common use of > DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage, > what'd you'd be asking there is for app developers to break compatibility with > all existing drivers in exchange for a gain so abstruse that most of them > won't even understand why it's there. I do not think so: the purpose is not to modify any existing command, but to add only ONE new one which might be called something like: C_UnwrapKeyCkaExtractableFalse where the certificate used to perform the operation would have a key usage like: keyEnciphermentNoExtract. This means that the "cryptographic material", once decrypted, cannot be extracted. So there would be no backward compatibility problem. > An addition, given the longevity of > crypto hardware devices, even if vendors (for some reason) decided to do this, > it'd take years for everything to implement it. Yes, this may take years, but since this is fairly simple, it might only take only a couple of years. :-) > Finally, some hardware (e.g. > many smart cards) can't support this, since all the card can usefully do is > the private-key op. This would apply to new smart cards only. > As a result the unwrapped key is always extractable from the card, Yes, this is the current situation, and hence why we should change it. Denis > either because it doesn't do symmetric crypto at all, because it > does it in a crippled manner that makes it useless (e.g. it zeroes all but 40 > bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or > even if it does do symmetric crypto, it's so slow that it's unusable. So > CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be > overridden by the hardware. > > Peter. > > From owner-ietf-pkix@mail.imc.org Tue May 17 14:11:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22520 for ; Tue, 17 May 2005 14:11:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HHSKmY006776; Tue, 17 May 2005 10:28:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4HHSKuY006775; Tue, 17 May 2005 10:28:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nb2.stroeder.com (d33-84.dip.isp-service.de [83.121.33.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HHSJdA006744 for ; Tue, 17 May 2005 10:28:19 -0700 (PDT) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id CE6D74AB0; Tue, 17 May 2005 18:23:06 +0200 (CEST) Received: from nb2.stroeder.com ([127.0.0.1]) by localhost (nb2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15066-03; Tue, 17 May 2005 18:22:53 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 389A37FE6F; Tue, 17 May 2005 18:22:47 +0200 (CEST) Message-ID: <428A1A56.9070006@stroeder.com> Date: Tue, 17 May 2005 18:22:46 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> In-Reply-To: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at stroeder.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ Housley wrote: > > There has been a whole lot of discussion about these paragraphs. Since > some of the discussion has not been CCed to the PKIX mail list, I am > posting the resulting words. Since this discussions started by providing examples how about adding a short example section for demonstrating the appropriate usage of these bits? Ciao, Michael. From owner-ietf-pkix@mail.imc.org Tue May 17 15:59:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04806 for ; Tue, 17 May 2005 15:59:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HH5uWC002855; Tue, 17 May 2005 10:05:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4HH5ucO002854; Tue, 17 May 2005 10:05:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HH5tjZ002839 for ; Tue, 17 May 2005 10:05:55 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4HH4oaN019899; Tue, 17 May 2005 13:05:25 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4HH4P6v000416; Tue, 17 May 2005 13:04:25 -0400 (EDT) Message-Id: <5.1.0.14.2.20050517125916.0303b1e8@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 17 May 2005 13:06:17 -0400 To: Sam Hartman From: Tim Polk Subject: Progressing 3770bis Cc: ietf-pkix@imc.org, housley@vigilsec.com, timmoore@microsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam, The PKIX WG has achieved rough consensus on 3770bis, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)". This document is ready for progression, and upon approval will obsolete RFC 3770. As with its predecessor, we are recommending progression as standards track document. (The document should cycle at Proposed Standard.) The current draft is available at http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-02.txt Thanks, Tim Polk From owner-ietf-pkix@mail.imc.org Tue May 17 21:09:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10987 for ; Tue, 17 May 2005 21:08:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I0Gepv090924; Tue, 17 May 2005 17:16:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4I0GeRA090923; Tue, 17 May 2005 17:16:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I0GYfq090885 for ; Tue, 17 May 2005 17:16:35 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Wed, 18 May 2005 09:57:00 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Wed, 18 May 2005 09:57:00 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Wed, 18 May 2005 09:56:46 +1000 From: "Simon McMahon" To: , Cc: , , Subject: Re: Improving PKCS#11 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4I0Gafq090899 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, This discussion belongs on the PKCS11 list. > C_UnwrapKeyCkaExtractableFalse This adds nothing that isn't already in PKCS11 since the app still has to choose to call this function. Having spent many years in that working group I also know that adding top level functions is usually a last resort for any new feature. The intent appears to be to map certificate key-usage attributes, for the public key, into PKCS11 key attributes of the private key and make the PKCS11 library do it. Regardless of whether it is appropriate to do that, this is just a new C_Unwrap mechanism and they can be defined in the 'vendor defined' space so this problem already has a solution - or at least a way to do it. If no-one has written such a mechanism then they probably already solved this problem another way. If they have then that mechanism can be promoted to one of the standard mechanisms. Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Denis Pinkas 05/17/05 10:26pm >>> Peter, >>If PKCS#11 gets improved, then we could distinguish between: >> keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE >> keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE > I can't see that ever being added. If you want to make it unextractable in > the user app, No. The purpose is to make impossible, whatever the user application asks, to extract the private key in the clear. > set the CKA_EXTRACTABLE flag in the key template to false (this > is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE). If the hardware makes > it unextractable (e.g. in Fortezza cards), it'll implicitly set > CKA_EXTRACTABLE for you. The hardware cannot do anything since currently the setting of the flag CKA_EXTRACTABLE is left to the application. > There are also practical considerations. The reason for the common use of > DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage, > what'd you'd be asking there is for app developers to break compatibility with > all existing drivers in exchange for a gain so abstruse that most of them > won't even understand why it's there. I do not think so: the purpose is not to modify any existing command, but to add only ONE new one which might be called something like: C_UnwrapKeyCkaExtractableFalse where the certificate used to perform the operation would have a key usage like: keyEnciphermentNoExtract. This means that the "cryptographic material", once decrypted, cannot be extracted. So there would be no backward compatibility problem. > An addition, given the longevity of > crypto hardware devices, even if vendors (for some reason) decided to do this, > it'd take years for everything to implement it. Yes, this may take years, but since this is fairly simple, it might only take only a couple of years. :-) > Finally, some hardware (e.g. > many smart cards) can't support this, since all the card can usefully do is > the private-key op. This would apply to new smart cards only. > As a result the unwrapped key is always extractable from the card, Yes, this is the current situation, and hence why we should change it. Denis > either because it doesn't do symmetric crypto at all, because it > does it in a crippled manner that makes it useless (e.g. it zeroes all but 40 > bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or > even if it does do symmetric crypto, it's so slow that it's unusable. So > CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be > overridden by the hardware. > > Peter. > > *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** From owner-ietf-pkix@mail.imc.org Wed May 18 03:10:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12613 for ; Wed, 18 May 2005 03:10:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I6CrUp093705; Tue, 17 May 2005 23:12:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4I6CrXu093704; Tue, 17 May 2005 23:12:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I6CpxD093683 for ; Tue, 17 May 2005 23:12:52 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 2B0C935B08; Wed, 18 May 2005 18:12:50 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17798-12; Wed, 18 May 2005 18:12:50 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id D0B5835B1F; Wed, 18 May 2005 18:12:46 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4970E3774B; Wed, 18 May 2005 18:12:46 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DYHnX-0005Gc-00; Wed, 18 May 2005 18:12:51 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, pgut001@cs.auckland.ac.nz Subject: Re: Improving PKCS#11 Cc: ietf-pkix@vpnc.org, kent@bbn.com In-Reply-To: <4289E310.9020407@bull.net> Message-Id: Date: Wed, 18 May 2005 18:12:51 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas writes: >The purpose is to make impossible, whatever the user application asks, to >extract the private key in the clear. Since the flags are ultimately controlled by the user app (no matter what you call them or where you put them), the user app is *always* going to get the key if it really wants it. The only thing that'll stop it is if the hardware prevents this (see below). >> If the hardware makes >> it unextractable (e.g. in Fortezza cards), it'll implicitly set >> CKA_EXTRACTABLE for you. > >The hardware cannot do anything since currently the setting of the flag >CKA_EXTRACTABLE is left to the application. That's merely a request from the software side. A Fortezza card isn't going to give you the key, no matter what you set CKA_EXTRACTABLE to. Conversely, a Cryptoflex (at least the older ones) will always give you the key because it only contains a private-key engine (you can't even do public-key encryption with it). So if you try and set the flag in a way that isn't supported by the hardware, you'll get a template-inconsistent error (or you may get the object created but with the template modified according to the hardware capabilities, depending on the implementation). Ultimately, the crypto hardware gets the last word, not an application-set flag. Unlike PKIX, the PKCS #11 folks are somewhat reluctant to set standards requirements that violate the laws of physics. >I do not think so: the purpose is not to modify any existing command, but to >add only ONE new one which might be called something like: > >C_UnwrapKeyCkaExtractableFalse > >where the certificate used to perform the operation would have a key usage >like: keyEnciphermentNoExtract. This means that the "cryptographic material", >once decrypted, cannot be extracted. But again, this depends *entirely* on the calling software. It doesn't matter how you dress this up, if the calling app wants the key, all it has to do is call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse, or set CKA_EXTRACTABLE to true in the template for C_UnwrapKey, or whatever. If the calling app wants to it can look at the cert, see that keyEncipherment is set to true and dataEncipherment false, and then go ahead and set CKA_EXTRACTABLE to true or call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse. There is therefore no difference between C_UnwrapKeyCkaExtractableFalse and C_UnwrapKey with CKA_EXTRACTABLE set to false. Peter. From owner-ietf-pkix@mail.imc.org Wed May 18 12:03:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05733 for ; Wed, 18 May 2005 12:03:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IF26Fq093069; Wed, 18 May 2005 08:02:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4IF26BL093068; Wed, 18 May 2005 08:02:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from lon1-mail-2.visp.demon.net (IDENT:mirapoint@lon1-mail-2.visp.demon.net [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IF25jP093061 for ; Wed, 18 May 2005 08:02:06 -0700 (PDT) (envelope-from d.w.chadwick@salford.ac.uk) Received: from [195.158.102.164] (as9p164.access.maltanet.net [195.158.102.164]) by lon1-mail-2.visp.demon.net (MOS 3.4.6-GR) with ESMTP id CHL63992 (AUTH maggiewilliams@beeb.net); Wed, 18 May 2005 15:14:44 +0100 (BST) Message-ID: <428B4DCE.3040005@salford.ac.uk> Date: Wed, 18 May 2005 15:14:38 +0100 From: David Chadwick Organization: University of Salford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: PKIX Subject: EuroPKI 2005 - Call for Participation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit CALL FOR PARTICIPATION The EuroPKI 2005 Conference will be held in Canterbury, England, 30 June - 1 July 2005. Registration is now open. See http://sec.cs.kent.ac.uk/europki2005/registration.shtml Early registration closes on 1 June, so book now to secure your place. The Keynote Speech will be given by Dr Carlise Adams, and is entitled "PKI: Views from the Dispassionate "I", in which he will present his thoughts on why PKI has been available as an authentication technology for many years now, but has only enjoyed large-scale success in fairly limited contexts to date. He will also present his thoughts on the possible future(s) of this technology, with emphasis on the major factors hindering adoption and some potential directions for future research in these areas. The Programme will have sessions on: authorization, risks/attacks to PKI systems, interoperability between systems, evaluating a CA, ID ring based signatures, new protocols, practical implementations and long term archiving. The full programme can be seen at http://sec.cs.kent.ac.uk/europki2005/programme.shtml The Conference Banquet will take place in the historic Dover Castle and will be preceeded by a trip around the labyrinth of tunnels holding World War Two archives where Winston Churchill did must of his war time planning http://www.plus44.com/heritage/dover/dovercast.htm I look forward to meeting you there David Chadwick -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 1484 532930 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Web site: http://sec.isi.salford.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** From owner-ietf-pkix@mail.imc.org Wed May 18 15:33:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27671 for ; Wed, 18 May 2005 15:33:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IIfBlG035250; Wed, 18 May 2005 11:41:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4IIfBSk035249; Wed, 18 May 2005 11:41:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail3.firstdata.com (mail3.firstdata.com [198.184.5.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IIf9HM035223 for ; Wed, 18 May 2005 11:41:10 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Received: from ([198.184.5.26]) by mail3.firstdata.com with SMTP id KP-AXLZC.11341770; Wed, 18 May 2005 14:40:46 -0400 Received: from mdhagsmtp01.firstdata.com (198.184.5.21) by MDSIGABA01.firstadata.com (Sigaba Gateway v3.8) with ESMTP id 2040605; Wed, 18 May 2005 14:47:18 -0400 Subject: Re: EuroPKI 2005 - Call for Participation To: David Chadwick Cc: PKIX X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Wed, 18 May 2005 12:40:23 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP01/MD/FDMS/FDC(Release 6.5.2|June 01, 2004) at 05/18/2005 02:46:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: at 8:14 am 5/18/05, d.w.chadwick@salford.ac.uk wrote: > > CALL FOR PARTICIPATION > > The EuroPKI 2005 Conference will be held in Canterbury, England, 30 June > - 1 July 2005. > > Registration is now open. See > > http://sec.cs.kent.ac.uk/europki2005/registration.shtml > > Early registration closes on 1 June, so book now to secure your place. > > The Keynote Speech will be given by Dr Carlise Adams, and is entitled > "PKI: Views from the Dispassionate "I", in which he will present his > thoughts on why PKI has been available as an authentication technology > for many years now, but has only enjoyed large-scale success in fairly > limited contexts to date. He will also present his thoughts on the > possible future(s) of this technology, with emphasis on the major > factors hindering adoption and some potential directions for future > research in these areas. from 3-factor authentication paradigm http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are that verification of a digital signature with a public key is a form of "something you have" authentication ... i.e. the subject has access and use of the corresponding private key. note, however, it has seemed that the majority of certification authorities (mainstay of most formal PKIs) are embroiled in identification issues, not authentication ... aka the certification binding of some information to a public key (and the production of the resulting certificate). i've frequently claimed that this paradigm was disigned to address the offline email scenario from the early 80s ... where the recipient had absolutely no recourse to information about an otherwise anomomous sender that the recipient never had any previous communication with (aka the letters of credit model from the sailing ship days). the recipient, dialed their local electronic postoffice, exchanged email, and then hungup. the recipient then found themself with an email from a total stranger, there had never been any prior communication, and the recipient lack any means for discoverying any information about the stanger. the early 90s saw x.509 identification certificates. however, there was some tendency by certification authorities looking at significantly overload such certificates with enormous amounts of personal information (not really being able to predict the future about what relying parties and/or what business processes might be targets for such certificates, and therefor not reliably being able to predict what relying parties might expect in the way of identification information). in the mid-90s some of the institutions (like financial) industry) ... looking at such identity certificates realized that they represented enormous privacy and liability issues and you saw some retrenchment to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo these certificates frequently contained little more certified information than some form of account number bound to a public key. however, it was trivial to show that such reply-party-only certificates not only violated the original certiicate design point (total stranger communicating for the first time with a offline relying-party that had no other recourse to information about the originator), but also were redundant and superfluous (aka the relying-party having registered the public key and issued the relying-party-only certificate ... would have a superset of every bit of information contained in a certificate ... including the public key). in the financial industry situation ... where the redundant and superfluous certificates were being targeted at payment transactions ... aka a consumer would create a payment transaction, digitally signed it and transmit the transaction, the digital signature, and the reply-party-only certificate back to the issuing institution. Not only did the relying-party (destination of the payment transaction) alerady have access to a superset of the information contained in a redundant and superfluous digital certificate ... but it turns out that the nominal payment transaction size is on the order of 60-80 bytes. The typical redundant and superfluous relying-party-only certificate from the period could be on the order of 4k-12k bytes. So not only were the relying-party-only certificates redundant and superfluous, but in such situations they also represented a factor of 100 times payload bloat. It is actually possible to deploy authentication infrastructures that use digital signature verification http://www.garlic.com/~lynn/subpubkey.html#certless that avoid getting embroiled in the identification issues that seem to accompany many PKI deployments. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix@mail.imc.org Wed May 18 18:42:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01113 for ; Wed, 18 May 2005 18:42:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ILoImY076118; Wed, 18 May 2005 14:50:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4ILoIik076117; Wed, 18 May 2005 14:50:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ILoGkZ076089 for ; Wed, 18 May 2005 14:50:17 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 May 2005 22:50:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Request for new work item - Defining an SRV RR otherName Date: Wed, 18 May 2005 22:49:32 +0100 Message-ID: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVa49B3OIJ65dJPQLOybWmgvDp/swBDTguw From: "Stefan Santesson" To: X-OriginalArrivalTime: 18 May 2005 21:50:11.0221 (UTC) FILETIME=[90AAA450:01C55BF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4ILoHkZ076112 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit All, I have just submitted a new personal draft under the name: draft-santesson-pkix-srvrr-00 and I hope this draft will be available from the IETF server soon. With this mail, I request this WG to consider acceptance of this draft as a PKIX work item. The purpose of this draft is to facilitate inclusion of a service name to a X.509 certificate subject in the form of a DNS Service Resource Record (SRV RR). The primary immediate need for this draft is to resolve some of the last hard issues with Kerberos PKINIT which still lack a way to express that a certificate is issued to a host which act as a kdc server. The PKINIT draft suggested recently that a SRV RR (_kdc._tcp.realm) could be placed in a dNSName in SubjectAltName extension, but this would be incompatible with RFC 3280 definition of dNSName and would cause issues with name constraints. To fill this void, implementation of PKINIT will strongly benefit from the definition of a new otherName to express SRV RR in X.509 certificates. Since the use of SRV RR is a generic feature, not only relevant to Kerberos, the proposal is to define this otherName in PKIX. Below is the introduction and otherName definition pasted from the submitted draft. 1. Introduction RFC 2782 [N3] Defines a DNS RR (Resource Record) for specifying the location of services (SRV RR) which allows clients to ask for a specific service/protocol for a specific domain and get back the names of any available servers. Current defined dNSName GeneralName name forms only provide for DNS host names to be expressed in "preferred name syntax," as specified by RFC 1034 [N4]. This definition is not broad enough to allow expression of a SRV RR. To accommodate expression of a SRV RR in X.509 certificates this document therefore defines an otherName for SRV RR. As DNS query based on an SRV RR returns the name of the host currently available for the requested service, reasonable subsequent authentication of that host as the appropriate host for the service will require the host to demonstrate that it is an authorized to provide the requested service. The ability to associate a host with a SRV RR in an X.509 certificate therefore facilitates the binding of the host to the originally requested SRV RR in order to protect against DNS spoofing attacks where an altered DNS could return the host name of a rouge or hacked host. One example where expression of a SRV RR can be very useful is to identify a host as a legitimate Kerberos KDC server. 2. SRV RR otherName This section defines the SRVRRName as a form of otherName from the GeneralName structure in SubjectAltName. The SRVRRName if present MUST contain a Service Resource Record (SRV RR) formed according to RFC 2782 [N3]. The use of a SRVRRName is OPTIONAL. The SRVRRName is defined as follows: id-on-sRVRRName OBJECT IDENTIFIER ::= { id-on ? } SRVRRName ::= IA5String Stefan Santesson Program Manager, Standards Liaison Windows Security From owner-ietf-pkix@mail.imc.org Thu May 19 07:33:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24128 for ; Thu, 19 May 2005 07:33:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JAg34F088767; Thu, 19 May 2005 03:42:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JAg35T088766; Thu, 19 May 2005 03:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JAg1h6088734 for ; Thu, 19 May 2005 03:42:01 -0700 (PDT) (envelope-from diegofv@eresmas.com) Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 1DY2rV-0006tN-00; Tue, 17 May 2005 16:15:57 +0200 From: To: Simon_McMahon@health.qld.gov.au Cc: housley@vigilsec.com, ietf-pkix@vpnc.org Message-ID: Date: Tue, 17 May 2005 14:15:59 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: RE: Re: key usage - key encipherment or data encipherment X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit But, if the asymmetric private key is based on elliptic curves? Diego ----- Mensaje Original ----- Remitente: "Simon McMahon" Simon_McMahon@health.qld.gov.au Destinatario: housley@vigilsec.com, ietf-pkix@vpnc.org Fecha: Martes, Mayo 17, 2005 1:03am Asunto: Re: key usage - key encipherment or data encipherment > >The example for 'keyEncipherment' should not include an "RSA public >key encrypting an asymmetric private key", which, if it is also RSA >is too big to encrypt with the public key. Surely, an RFC shouldn't >list impossible cases as examples. > >Simon. > From owner-ietf-pkix@mail.imc.org Thu May 19 12:01:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19323 for ; Thu, 19 May 2005 12:01:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFGkKb091400; Thu, 19 May 2005 08:16:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JFGkqY091399; Thu, 19 May 2005 08:16:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFGixK091378 for ; Thu, 19 May 2005 08:16:45 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA03780; Thu, 19 May 2005 17:31:40 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051917163569:1872 ; Thu, 19 May 2005 17:16:35 +0200 Message-ID: <428CAE0E.8000406@bull.net> Date: Thu, 19 May 2005 17:17:34 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: Structuring Denis issues RE: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 17:16:35, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 17:16:37, Serialize complete at 19/05/2005 17:16:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan, > Denis, > Thanks for the clarification. > Yes, we agree on issue number 1 (remove SHOULD and MUST) We also agree on a typo. :-| > So the remaining issue is: > > Problem: The security considerations talk about "mitigation" of the name > collision problem but gives inadequate advice. > > Your proposed resolution > > a) warn the user that the CRL where this extension was found may not be > the right one. The AIA extension in found in a CRL that is not yet checked to be the right one. > b) warn the user that the CRL issuer certificate he might obtain using > this extension may not be the right one. The AIA extension does not provide enough information so that the CRL issuer certificate that is found there is indeed the right one, since at this time the certification path is not yet formed. There may be a man-in-the-middle attack. > c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed > the one nominated by the CA that has issued the target certificate > (i.e. when the CRL Issuer certification path and the target > certificate certification path are identical). This would indeed be a useful guidance given the two above statements. > d) say that other possibilities exists, but need additional trust > conditions (there are zillions of such possible trust conditions). This would indeed be a useful guidance given the previous statement. I am spending a *considerable* time on this issue and I believe that you have now perfectly understood what the problem is. You know that I do not consider the AIA extension useful in the "basic" case. Since the other cases (the "zillions" of other cases) rely anyway on additional local trust conditions, some local configuration values may be used to know where to fetch the missing CRL issuer certificates, hence why this extension is not really useful and may even be dangerous to be used if people simply use what they get from the pointer. Denis > To complete the picture it would now be very helpful if you, for each of > these statements, could confirm or explain how these issues are a result > of using the AIA extension in CRLs. Or in other words, which of these > security considerations could you ignore (would go away) if you were NOT > using the AIA extension in a CRL to locate the CRL Issuer certificate. > > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > From owner-ietf-pkix@mail.imc.org Thu May 19 12:31:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22592 for ; Thu, 19 May 2005 12:31:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFlBtG097005; Thu, 19 May 2005 08:47:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JFlBHC097004; Thu, 19 May 2005 08:47:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFlA2c096977 for ; Thu, 19 May 2005 08:47:10 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 16:47:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Structuring Denis issues RE: Comments on Date: Thu, 19 May 2005 16:46:40 +0100 Message-ID: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVchcOzseRg2KtJRVOPauPghsh8WQAASM0A From: "Stefan Santesson" To: "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 19 May 2005 15:47:04.0490 (UTC) FILETIME=[012D10A0:01C55C8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JFlB2c096998 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, I'm afraid that this e-mail from you doesn't help me understand your answer to my question (how your raised issues are related specifically to the use of the AIA extension in CRLs). The only argument I find in this context is that you fear that the CRL user would simply accept and trust the certificate they obtain through this extension. But this would be in violation to RFC 3280 path validation which specifies what you need to do to validate a certificate. These rules apply also to the certificate you obtained through the CRL AIA extension (It applies to all certificates you want to validate). Thus, an implementation that follows RFC 3280 when validating the certificate they obtained through CRL-AIA will not be subject to man-in-the-middle attacks and will not "simply use what they got from the pointer". Validation of the CRL Issuer certificate (and its path) is nothing new. The only difference introduced in this draft is an alternative way to discover/locate a certificate that can validate the CRL you already picked as a candidate CRL. To incorporate any of your proposed amendments we still need you to explain how each of your issues and proposed resolutions specifically ties to THAT particular feature introduced by this draft. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 19 maj 2005 08:18 > To: Stefan Santesson > Cc: pkix > Subject: Re: Structuring Denis issues RE: Comments on crlaia-00.txt> > > Stefan, > > > Denis, > > > Thanks for the clarification. > > Yes, we agree on issue number 1 (remove SHOULD and MUST) > > We also agree on a typo. :-| > > > So the remaining issue is: > > > > Problem: The security considerations talk about "mitigation" of the name > > collision problem but gives inadequate advice. > > > > Your proposed resolution > > > > a) warn the user that the CRL where this extension was found may not be > > the right one. > > The AIA extension in found in a CRL that is not yet checked to be the > right one. > > > b) warn the user that the CRL issuer certificate he might obtain using > > this extension may not be the right one. > > The AIA extension does not provide enough information so that the CRL > issuer > certificate that is found there is indeed the right one, since at this > time the certification path is not yet formed. There may be a > man-in-the-middle attack. > > > c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed > > the one nominated by the CA that has issued the target certificate > > (i.e. when the CRL Issuer certification path and the target > > certificate certification path are identical). > > This would indeed be a useful guidance given the two above statements. > > > d) say that other possibilities exists, but need additional trust > > conditions (there are zillions of such possible trust conditions). > > This would indeed be a useful guidance given the previous statement. > > I am spending a *considerable* time on this issue and I believe that you > have now perfectly understood what the problem is. > > You know that I do not consider the AIA extension useful in the "basic" > case. > > Since the other cases (the "zillions" of other cases) rely anyway on > additional local trust conditions, some local configuration values may be > used to know where to fetch the missing CRL issuer certificates, hence why > this extension is not really useful and may even be dangerous to be used > if > people simply use what they get from the pointer. > > Denis > > > To complete the picture it would now be very helpful if you, for each of > > these statements, could confirm or explain how these issues are a result > > of using the AIA extension in CRLs. Or in other words, which of these > > security considerations could you ignore (would go away) if you were NOT > > using the AIA extension in a CRL to locate the CRL Issuer certificate. > > > > > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 19 12:45:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23518 for ; Thu, 19 May 2005 12:45:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFu4UL097994; Thu, 19 May 2005 08:56:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JFu4fU097993; Thu, 19 May 2005 08:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFu2nW097976 for ; Thu, 19 May 2005 08:56:03 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA13042; Thu, 19 May 2005 18:10:59 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051917555444:1912 ; Thu, 19 May 2005 17:55:54 +0200 Message-ID: <428CB744.1000701@bull.net> Date: Thu, 19 May 2005 17:56:52 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: Structuring Denis issues RE: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 17:55:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 17:55:56, Serialize complete at 19/05/2005 17:55:56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan, I'm afraid that you do not want to understand. Since you and me will be in Sophia Antipolis in about one week from now, I propose that we stop to discuss on this list now and have a face to face discussion there. Denis > Denis, > > I'm afraid that this e-mail from you doesn't help me understand your > answer to my question (how your raised issues are related specifically > to the use of the AIA extension in CRLs). > > The only argument I find in this context is that you fear that the CRL > user would simply accept and trust the certificate they obtain through > this extension. > > But this would be in violation to RFC 3280 path validation which > specifies what you need to do to validate a certificate. These rules > apply also to the certificate you obtained through the CRL AIA extension > (It applies to all certificates you want to validate). Thus, an > implementation that follows RFC 3280 when validating the certificate > they obtained through CRL-AIA will not be subject to man-in-the-middle > attacks and will not "simply use what they got from the pointer". > > Validation of the CRL Issuer certificate (and its path) is nothing new. > The only difference introduced in this draft is an alternative way to > discover/locate a certificate that can validate the CRL you already > picked as a candidate CRL. > > To incorporate any of your proposed amendments we still need you to > explain how each of your issues and proposed resolutions specifically > ties to THAT particular feature introduced by this draft. > > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: den 19 maj 2005 08:18 >>To: Stefan Santesson >>Cc: pkix >>Subject: Re: Structuring Denis issues RE: Comments on > > >>crlaia-00.txt> >> >>Stefan, >> >> >>>Denis, >> >>>Thanks for the clarification. >>>Yes, we agree on issue number 1 (remove SHOULD and MUST) >> >>We also agree on a typo. :-| >> >> >>>So the remaining issue is: >>> >>>Problem: The security considerations talk about "mitigation" of the >> > name > >>>collision problem but gives inadequate advice. >>> >>>Your proposed resolution >>> >>> a) warn the user that the CRL where this extension was found may >> > not be > >>> the right one. >> >>The AIA extension in found in a CRL that is not yet checked to be the >>right one. >> >> >>> b) warn the user that the CRL issuer certificate he might obtain >> > using > >>> this extension may not be the right one. >> >>The AIA extension does not provide enough information so that the CRL >>issuer >> certificate that is found there is indeed the right one, since at > > this > >>time the certification path is not yet formed. There may be a >>man-in-the-middle attack. >> >> >>> c) provide guidance on how to GUARANTEE that the CRL Issuer is >> > indeed > >>> the one nominated by the CA that has issued the target >> > certificate > >>> (i.e. when the CRL Issuer certification path and the target >>> certificate certification path are identical). >> >>This would indeed be a useful guidance given the two above statements. >> >> >>> d) say that other possibilities exists, but need additional trust >>> conditions (there are zillions of such possible trust >> > conditions). > >>This would indeed be a useful guidance given the previous statement. >> >>I am spending a *considerable* time on this issue and I believe that > > you > >>have now perfectly understood what the problem is. >> >>You know that I do not consider the AIA extension useful in the > > "basic" > >>case. >> >>Since the other cases (the "zillions" of other cases) rely anyway on >>additional local trust conditions, some local configuration values may > > be > >>used to know where to fetch the missing CRL issuer certificates, hence > > why > >>this extension is not really useful and may even be dangerous to be > > used > >>if >>people simply use what they get from the pointer. >> >>Denis >> >> >>>To complete the picture it would now be very helpful if you, for >> > each of > >>>these statements, could confirm or explain how these issues are a >> > result > >>>of using the AIA extension in CRLs. Or in other words, which of >> > these > >>>security considerations could you ignore (would go away) if you were >> > NOT > >>>using the AIA extension in a CRL to locate the CRL Issuer >> > certificate. > >>> >>> >>>Stefan Santesson >>>Program Manager, Standards Liaison >>>Windows Security >>> >>> >>> >>> >> > > > From owner-ietf-pkix@mail.imc.org Thu May 19 12:51:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23987 for ; Thu, 19 May 2005 12:51:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JG1dN0098370; Thu, 19 May 2005 09:01:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JG1dfM098369; Thu, 19 May 2005 09:01:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JG1ZYG098358 for ; Thu, 19 May 2005 09:01:35 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 17:01:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Structuring Denis issues RE: Comments on Date: Thu, 19 May 2005 17:01:19 +0100 Message-ID: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVci0wPlQ2MVD4RSwmFNNn/d9a6+QAAEw0Q From: "Stefan Santesson" To: "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 19 May 2005 16:01:29.0760 (UTC) FILETIME=[04EACA00:01C55C8C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JG1aYG098364 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I do want to understand! Yes, let's talk in Sophia Antipolis and save some bandwidth on this list. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 19 maj 2005 08:57 > To: Stefan Santesson > Cc: pkix > Subject: Re: Structuring Denis issues RE: Comments on crlaia-00.txt> > > Stefan, > > I'm afraid that you do not want to understand. Since you and me will be in > Sophia Antipolis in about one week from now, I propose that we stop to > discuss on this list now and have a face to face discussion there. > > Denis > > > Denis, > > > > I'm afraid that this e-mail from you doesn't help me understand your > > answer to my question (how your raised issues are related specifically > > to the use of the AIA extension in CRLs). > > > > The only argument I find in this context is that you fear that the CRL > > user would simply accept and trust the certificate they obtain through > > this extension. > > > > But this would be in violation to RFC 3280 path validation which > > specifies what you need to do to validate a certificate. These rules > > apply also to the certificate you obtained through the CRL AIA extension > > (It applies to all certificates you want to validate). Thus, an > > implementation that follows RFC 3280 when validating the certificate > > they obtained through CRL-AIA will not be subject to man-in-the-middle > > attacks and will not "simply use what they got from the pointer". > > > > Validation of the CRL Issuer certificate (and its path) is nothing new. > > The only difference introduced in this draft is an alternative way to > > discover/locate a certificate that can validate the CRL you already > > picked as a candidate CRL. > > > > To incorporate any of your proposed amendments we still need you to > > explain how each of your issues and proposed resolutions specifically > > ties to THAT particular feature introduced by this draft. > > > > > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > >>-----Original Message----- > >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >>Sent: den 19 maj 2005 08:18 > >>To: Stefan Santesson > >>Cc: pkix > >>Subject: Re: Structuring Denis issues RE: Comments on > > > > > > >>crlaia-00.txt> > >> > >>Stefan, > >> > >> > >>>Denis, > >> > >>>Thanks for the clarification. > >>>Yes, we agree on issue number 1 (remove SHOULD and MUST) > >> > >>We also agree on a typo. :-| > >> > >> > >>>So the remaining issue is: > >>> > >>>Problem: The security considerations talk about "mitigation" of the > >> > > name > > > >>>collision problem but gives inadequate advice. > >>> > >>>Your proposed resolution > >>> > >>> a) warn the user that the CRL where this extension was found may > >> > > not be > > > >>> the right one. > >> > >>The AIA extension in found in a CRL that is not yet checked to be the > >>right one. > >> > >> > >>> b) warn the user that the CRL issuer certificate he might obtain > >> > > using > > > >>> this extension may not be the right one. > >> > >>The AIA extension does not provide enough information so that the CRL > >>issuer > >> certificate that is found there is indeed the right one, since at > > > > this > > > >>time the certification path is not yet formed. There may be a > >>man-in-the-middle attack. > >> > >> > >>> c) provide guidance on how to GUARANTEE that the CRL Issuer is > >> > > indeed > > > >>> the one nominated by the CA that has issued the target > >> > > certificate > > > >>> (i.e. when the CRL Issuer certification path and the target > >>> certificate certification path are identical). > >> > >>This would indeed be a useful guidance given the two above statements. > >> > >> > >>> d) say that other possibilities exists, but need additional trust > >>> conditions (there are zillions of such possible trust > >> > > conditions). > > > >>This would indeed be a useful guidance given the previous statement. > >> > >>I am spending a *considerable* time on this issue and I believe that > > > > you > > > >>have now perfectly understood what the problem is. > >> > >>You know that I do not consider the AIA extension useful in the > > > > "basic" > > > >>case. > >> > >>Since the other cases (the "zillions" of other cases) rely anyway on > >>additional local trust conditions, some local configuration values may > > > > be > > > >>used to know where to fetch the missing CRL issuer certificates, hence > > > > why > > > >>this extension is not really useful and may even be dangerous to be > > > > used > > > >>if > >>people simply use what they get from the pointer. > >> > >>Denis > >> > >> > >>>To complete the picture it would now be very helpful if you, for > >> > > each of > > > >>>these statements, could confirm or explain how these issues are a > >> > > result > > > >>>of using the AIA extension in CRLs. Or in other words, which of > >> > > these > > > >>>security considerations could you ignore (would go away) if you were > >> > > NOT > > > >>>using the AIA extension in a CRL to locate the CRL Issuer > >> > > certificate. > > > >>> > >>> > >>>Stefan Santesson > >>>Program Manager, Standards Liaison > >>>Windows Security > >>> > >>> > >>> > >>> > >> > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 19 13:08:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25621 for ; Thu, 19 May 2005 13:08:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JGJx0E099673; Thu, 19 May 2005 09:19:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JGJxLw099672; Thu, 19 May 2005 09:19:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.firstdata.com (mail2.firstdata.com [198.184.5.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JGJvDq099663 for ; Thu, 19 May 2005 09:19:58 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Received: from ([198.184.5.26]) by mail2.firstdata.com with SMTP id KP-TRRA2.23332520; Thu, 19 May 2005 12:19:26 -0400 Received: from mdhagsmtp01.firstdata.com (198.184.5.21) by MDSIGABA01.firstadata.com (Sigaba Gateway v3.8) with ESMTP id 2068871; Thu, 19 May 2005 12:25:59 -0400 Subject: Re: EuroPKI 2005 - Call for Participation To: "Anders Rundgren" Cc: "David Chadwick" , PKIX X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Thu, 19 May 2005 10:19:09 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP01/MD/FDMS/FDC(Release 6.5.2|June 01, 2004) at 05/19/2005 12:25:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: at 3:25pm 5/18/05, anders rundgen wrote: > The problem is that none these systems are supported by PCs as this industry > have shown to be incapable of defining a mobile, secure container. > Esoteric explanations may be more fun to talk about but they have little > validity as ID TTP liability etc.has not been put to test in any major way yet. > "non-repudiation", has probably not happened once! > > BTW, maybe you guys should begin to look on the next ID "revolution" > Microsoft's InfoCard stuff? slightly related thread in http://www.garlic.com/~lynn/2005h.html#36 Security via hardware? includes some reference to patent activity on authentication token integrity. and a press release from today http://www.gamesindustry.biz/press_release.php?aid=9008 an aads offering http://www.garlic.com/~lynn/index.html#aads a couple minor other postings in somewhat related threads: http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm From owner-ietf-pkix@mail.imc.org Thu May 19 13:25:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27024 for ; Thu, 19 May 2005 13:24:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JGXu2f001892; Thu, 19 May 2005 09:33:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JGXuNU001891; Thu, 19 May 2005 09:33:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JGXs1o001863 for ; Thu, 19 May 2005 09:33:55 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA43054; Thu, 19 May 2005 18:48:38 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051918333354:1933 ; Thu, 19 May 2005 18:33:33 +0200 Message-ID: <428CC017.4050707@bull.net> Date: Thu, 19 May 2005 18:34:31 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Gutmann CC: ietf-pkix@vpnc.org Subject: Re: Improving PKCS#11 References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 18:33:33, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 18:33:40, Serialize complete at 19/05/2005 18:33:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, See my comment at the bottom of this e-mail. >>The purpose is to make impossible, whatever the user application asks, to >>extract the private key in the clear. > Since the flags are ultimately controlled by the user app (no matter what you > call them or where you put them), the user app is *always* going to get the > key if it really wants it. The only thing that'll stop it is if the hardware > prevents this (see below). >>>If the hardware makes >>>it unextractable (e.g. in Fortezza cards), it'll implicitly set >>>CKA_EXTRACTABLE for you. >>The hardware cannot do anything since currently the setting of the flag >>CKA_EXTRACTABLE is left to the application. > That's merely a request from the software side. A Fortezza card isn't going > to give you the key, no matter what you set CKA_EXTRACTABLE to. Conversely, a > Cryptoflex (at least the older ones) will always give you the key because it > only contains a private-key engine (you can't even do public-key encryption > with it). So if you try and set the flag in a way that isn't supported by the > hardware, you'll get a template-inconsistent error (or you may get the object > created but with the template modified according to the hardware capabilities, > depending on the implementation). Ultimately, the crypto hardware gets the > last word, not an application-set flag. Unlike PKIX, the PKCS #11 folks are > somewhat reluctant to set standards requirements that violate the laws of > physics. >>I do not think so: the purpose is not to modify any existing command, but to >>add only ONE new one which might be called something like: >>C_UnwrapKeyCkaExtractableFalse >>where the certificate used to perform the operation would have a key usage >>like: keyEnciphermentNoExtract. This means that the "cryptographic material", >>once decrypted, cannot be extracted. > But again, this depends *entirely* on the calling software. It doesn't matter > how you dress this up, if the calling app wants the key, all it has to do is > call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse, or set > CKA_EXTRACTABLE to true in the template for C_UnwrapKey, or whatever. I did not made my explanations clear enough. A private key, when generated within the token, would be marked to be usable only with C_UnwrapKeyCkaExtractableFalse. So if the application attempts to use it with C_UnwrapKey this will fail. This would mean that the certificate corresponding to that private key would then be marked with keyEncipherment-no-extract. Denis > If the > calling app wants to it can look at the cert, see that keyEncipherment is set > to true and dataEncipherment false, and then go ahead and set CKA_EXTRACTABLE > to true or call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse. There > is therefore no difference between C_UnwrapKeyCkaExtractableFalse and > C_UnwrapKey with CKA_EXTRACTABLE set to false. > > Peter. From owner-ietf-pkix@mail.imc.org Thu May 19 15:43:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14154 for ; Thu, 19 May 2005 15:43:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JIXAHS021349; Thu, 19 May 2005 11:33:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JIXA86021348; Thu, 19 May 2005 11:33:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JIX7vn021339 for ; Thu, 19 May 2005 11:33:07 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j4JIX5FJ005341; Thu, 19 May 2005 11:33:05 -0700 (PDT) Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 11:33:04 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: key usage - key encipherment or data encipherment Date: Thu, 19 May 2005 11:33:04 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD372502B3@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: key usage - key encipherment or data encipherment Thread-Index: AcVZG8i79X1vB1dGQRqztW/jU2Re7QDhJMjg From: "Hallam-Baker, Phillip" To: "Peter Gutmann" , , X-OriginalArrivalTime: 19 May 2005 18:33:05.0032 (UTC) FILETIME=[321F2880:01C55CA1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JIX7vn021340 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I have been following the thread, I think the cures proposed may be worse than the problem. I think that the sentences can be adequately clarified by stating that dataEncipherment is to be set if the key is to be used to directly encipher data, i.e. without the use of an intermediate session key. I accept that this is not a particularly interesting use of dataEncipherment, the only protocols I can think of in which data is directly enciphered with a public key is Chaumian cash schemes and similar where blinding is used. Everywhere else you want to use a packaging scheme because the strength of bit 0 in RSA is pretty good but the strength of bit 1024 with a 1024 bit key is pretty bad. From owner-ietf-pkix@mail.imc.org Thu May 19 18:15:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07544 for ; Thu, 19 May 2005 18:15:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLGlAn056196; Thu, 19 May 2005 14:16:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JLGl9w056195; Thu, 19 May 2005 14:16:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp7.wiscmail.wisc.edu (hagen.doit.wisc.edu [144.92.197.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLGkac056169 for ; Thu, 19 May 2005 14:16:46 -0700 (PDT) (envelope-from ejnorman@doit.wisc.edu) Received: from avs-daemon.smtp7.wiscmail.wisc.edu by smtp7.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) id <0IGR00I4R9RQAB@smtp7.wiscmail.wisc.edu> for ietf-pkix@imc.org; Thu, 19 May 2005 16:16:38 -0500 (CDT) Received: from [128.104.4.39] (dyn-4-39.doit.wisc.edu [128.104.4.39]) by smtp7.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTPSA id <0IGR008NU9RND2@smtp7.wiscmail.wisc.edu> for ietf-pkix@imc.org; Thu, 19 May 2005 16:16:36 -0500 (CDT) Date: Thu, 19 May 2005 16:16:28 -0500 From: Eric Norman Subject: Re: key usage - key encipherment or data encipherment In-reply-to: <198A730C2044DE4A96749D13E167AD372502B3@MOU1WNEXMB04.vcorp.ad.vrsn.com> To: ietf-pkix@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.4.39 X-Spam-PmxInfo: Server=avs-3, Version=4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.5.19.26, SenderIP=128.104.4.39 References: <198A730C2044DE4A96749D13E167AD372502B3@MOU1WNEXMB04.vcorp.ad.vrsn.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7BIT On May 19, 2005, at 1:33 PM, Hallam-Baker, Phillip wrote: > I have been following the thread, I think the cures proposed may be > worse than the problem. > > I think that the sentences can be adequately clarified by stating that > dataEncipherment is to be set if the key is to be used to directly > encipher data, i.e. without the use of an intermediate session key. I might as well chime in with my take, which is different yet. And since those two bits have already appeared in standards documents, probably not worth anything. I think that from a user's point of view, all the user cares about is that the data is protected in transit and perhaps at rest. The user doesn't really care or even want to know whether an intermediate symmetric key in involved or not. From that point of view, the distinction seems rather silly. Now, if someone came up with a key escrow scheme that would escrow the symmetric key, then that might be interesting. But that's yet another thread. Eric Norman University of WIsconsin From owner-ietf-pkix@mail.imc.org Thu May 19 18:31:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09781 for ; Thu, 19 May 2005 18:31:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLpVkY063804; Thu, 19 May 2005 14:51:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JLpVkf063803; Thu, 19 May 2005 14:51:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLpTef063774 for ; Thu, 19 May 2005 14:51:30 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Fri, 20 May 2005 07:50:22 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Fri, 20 May 2005 07:50:22 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Fri, 20 May 2005 07:50:03 +1000 From: "Simon McMahon" To: Cc: "<" Subject: RE: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JLpUef063790 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sure, but the rewording mentions "RSA" for the public key and doesn't specify anything for the private. Do asymmetric ciphers often get combined this way in practice? A device would need full implementations of both RSA and elliptic curve to support this. The example should match typical usage and doesn't have to cover every possibility. The current wording implies RSA. Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> 05/18/05 12:15am >>> But, if the asymmetric private key is based on elliptic curves? Diego ----- Mensaje Original ----- Remitente: "Simon McMahon" Simon_McMahon@health.qld.gov.au Destinatario: housley@vigilsec.com, ietf-pkix@vpnc.org Fecha: Martes, Mayo 17, 2005 1:03am Asunto: Re: key usage - key encipherment or data encipherment > >The example for 'keyEncipherment' should not include an "RSA public >key encrypting an asymmetric private key", which, if it is also RSA >is too big to encrypt with the public key. Surely, an RFC shouldn't >list impossible cases as examples. > >Simon. > *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** From owner-ietf-pkix@mail.imc.org Thu May 19 22:07:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29867 for ; Thu, 19 May 2005 22:07:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K1Enu7001202; Thu, 19 May 2005 18:14:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4K1Envg001201; Thu, 19 May 2005 18:14:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K1Elew001170 for ; Thu, 19 May 2005 18:14:48 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Fri, 20 May 2005 11:13:39 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Fri, 20 May 2005 11:13:40 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Fri, 20 May 2005 11:13:24 +1000 From: "Simon McMahon" To: , Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4K1Emew001196 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Eric, > The user doesn't really care or even want to know whether an intermediate symmetric key in involved or not. I agree. The increased complexity of the rewording for 'keyEncipherment' is even more information that the user, or implementer, doesn't need to know. Having two bits for encryption just makes room for interoperability problems like those already mentioned. Where exactly is the benefit? Earlier remarks that it should be preserved until people are "smart enough" to make good use of it dont help much. If the use of 'dataEncipherment' is deprecated, but not reused for another purpose, we would have only 1 bit 'keyEncipherment' that could be renamed 'encipherment'. The proposed rewording discourages use of 'dataEncipherment' anyway. This would have little impact on implementations that use 'keyEncipherment' already, or implementations that set both bits because the distinction is so unclear and irrelevant. Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Eric Norman 05/20/05 07:16am >>> On May 19, 2005, at 1:33 PM, Hallam-Baker, Phillip wrote: > I have been following the thread, I think the cures proposed may be > worse than the problem. > > I think that the sentences can be adequately clarified by stating that > dataEncipherment is to be set if the key is to be used to directly > encipher data, i.e. without the use of an intermediate session key. I might as well chime in with my take, which is different yet. And since those two bits have already appeared in standards documents, probably not worth anything. I think that from a user's point of view, all the user cares about is that the data is protected in transit and perhaps at rest. The user doesn't really care or even want to know whether an intermediate symmetric key in involved or not. From that point of view, the distinction seems rather silly. Now, if someone came up with a key escrow scheme that would escrow the symmetric key, then that might be interesting. But that's yet another thread. Eric Norman University of WIsconsin *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** From owner-ietf-pkix@mail.imc.org Thu May 19 22:21:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00980 for ; Thu, 19 May 2005 22:21:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K1WtmD004776; Thu, 19 May 2005 18:32:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4K1WtxS004775; Thu, 19 May 2005 18:32:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K1Ws8D004763 for ; Thu, 19 May 2005 18:32:54 -0700 (PDT) (envelope-from James.H.Manger@team.telstra.com) Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 4793822AEC for ; Fri, 20 May 2005 11:32:53 +1000 (EST) Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id A273E1DA85 for ; Fri, 20 May 2005 11:32:52 +1000 (EST) Received: from WSMSG0005.srv.dir.telstra.com (wsmsg0005.srv.dir.telstra.com [192.74.168.134]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 31B06424E5 for ; Fri, 20 May 2005 11:32:52 +1000 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Fri, 20 May 2005 11:26:23 +1000 Message-ID: <73388857A695D31197EF00508B08F29816B38C88@ntmsg0131.corpmail.telstra.com.au> Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVa49B3OIJ65dJPQLOybWmgvDp/swBDTguwAAWxwyAAHHGHwAAVf99Q From: "Manger, James H" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j4K1Wt8D004765 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit RE: draft-santesson-pkix-srvrr-00 How about using UTF8String, instead of IA5String? The latter does not gain much (it can still include chars such as 0x00, newline, bell that are presumably not valid in SRV RR names), while the former should be more future-proof. SRVRRName ::= UTF8String -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Thursday, 19 May 2005 11:53 PM To: Manger, James H When I talked to Russ we thought that IA5String would be sufficient so I did put that in as a start, but I'm completely open to a change to UTF8String. Could you post the suggestion to the pkix list to see if there are any other reactions? From owner-ietf-pkix@mail.imc.org Fri May 20 05:52:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25566 for ; Fri, 20 May 2005 05:52:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K8gVwm020980; Fri, 20 May 2005 01:42:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4K8gVt1020979; Fri, 20 May 2005 01:42:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K8gU2A020954 for ; Fri, 20 May 2005 01:42:30 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft3.fr.colt.net with ESMTP id j4K8gSF05914 for ; Fri, 20 May 2005 10:42:28 +0200 Message-ID: <428DA2F4.4080401@free.fr> Date: Fri, 20 May 2005 10:42:28 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050517 MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Request for new work item - Defining an SRV RR otherName References: <73388857A695D31197EF00508B08F29816B38C88@ntmsg0131.corpmail.telstra.com.au> In-Reply-To: <73388857A695D31197EF00508B08F29816B38C88@ntmsg0131.corpmail.telstra.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Manger, James H wrote: >How about using UTF8String, instead of IA5String? The latter does not gain much (it can still include chars such as 0x00, newline, bell that are presumably not valid in SRV RR names), while the former should be more future-proof. > > SRVRRName ::= UTF8String > > >Could you post the suggestion to the pkix list to see if there are any >other reactions? > > It's already really a pity that dNSName forces us to store SAN in ACE encoding, instead of being able to put the real unicode value, so I'm all for not doing the mistake again. From owner-ietf-pkix@mail.imc.org Fri May 20 11:19:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27834 for ; Fri, 20 May 2005 11:19:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KEK88l060870; Fri, 20 May 2005 07:20:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KEK8Vx060869; Fri, 20 May 2005 07:20:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4KEK7I5060855 for ; Fri, 20 May 2005 07:20:07 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id C7A44100D0 for ; Fri, 20 May 2005 10:20:06 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07929-36 for ; Fri, 20 May 2005 10:19:52 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 8A101100C5 for ; Fri, 20 May 2005 10:19:52 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005052010191665-31076 ; Fri, 20 May 2005 10:19:16 -0400 Date: Fri, 20 May 2005 10:19:51 -0400 From: Sam Roberts To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Message-ID: <20050520141951.GD26985@certicom.com> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/20/2005 10:19:16 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/20/2005 10:19:17 AM, Serialize complete at 05/20/2005 10:19:17 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Simon McMahon , on Fri, May 20, 2005 at 07:50:03AM +1000: > The example should match typical usage and doesn't have to cover every > possibility. It probably isn't "typical", but the TCG uses RSA private keys encrypted with RSA public keys of the same strength. IIRC, instead of encrypting d,p-1,q-1,... (which would be too large), they only encrypt p. The decryptor can recreate the rest of the private key from the public key and knowledge of p. Cheers, Sam > > Simon. > > > Simon McMahon > > Work: (07) 31311420 > Mobile: (043) 2294180 > > > >>> 05/18/05 12:15am >>> > But, if the asymmetric private key is based on elliptic curves? > > Diego > > ----- Mensaje Original ----- > Remitente: "Simon McMahon" Simon_McMahon@health.qld.gov.au > Destinatario: housley@vigilsec.com, ietf-pkix@vpnc.org > Fecha: Martes, Mayo 17, 2005 1:03am > Asunto: Re: key usage - key encipherment or data encipherment > > > > >The example for 'keyEncipherment' should not include an "RSA public > >key encrypting an asymmetric private key", which, if it is also RSA > >is too big to encrypt with the public key. Surely, an RFC shouldn't > >list impossible cases as examples. > > > >Simon. > > > > > > > > *********************************************************************************** > This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. > > Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. > > If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. > *********************************************************************************** > -- http://www.certicom.com From owner-ietf-pkix@mail.imc.org Fri May 20 14:24:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20135 for ; Fri, 20 May 2005 14:24:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KHSH0B018644; Fri, 20 May 2005 10:28:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KHSHIN018643; Fri, 20 May 2005 10:28:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KHSFc3018631 for ; Fri, 20 May 2005 10:28:16 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 18:28:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Fri, 20 May 2005 18:28:08 +0100 Message-ID: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVdIqykBgO6iCzbRSSh2o3yA/2QBwAPfF5Q From: "Stefan Santesson" To: "Jean-Marc Desperrier" , X-OriginalArrivalTime: 20 May 2005 17:28:09.0872 (UTC) FILETIME=[4AD6A900:01C55D61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KHSGc3018637 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yes, The initial background thought was that more demanding encodings would be more of an issue for host labels rather than service resource records and thus IA5String would be sufficient, but I agree at this point to the suggestions to specify UTF8String instead. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Jean-Marc Desperrier > Sent: den 20 maj 2005 01:42 > To: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > Manger, James H wrote: > > >How about using UTF8String, instead of IA5String? The latter does not > gain much (it can still include chars such as 0x00, newline, bell that are > presumably not valid in SRV RR names), while the former should be more > future-proof. > > > > SRVRRName ::= UTF8String > > > > > > >Could you post the suggestion to the pkix list to see if there are any > >other reactions? > > > > > It's already really a pity that dNSName forces us to store SAN in ACE > encoding, instead of being able to put the real unicode value, so I'm > all for not doing the mistake again. From owner-ietf-pkix@mail.imc.org Fri May 20 16:20:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11020 for ; Fri, 20 May 2005 16:20:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KJdY4a046608; Fri, 20 May 2005 12:39:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KJdYfY046607; Fri, 20 May 2005 12:39:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KJdYSk046598 for ; Fri, 20 May 2005 12:39:34 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A401FE0063; Fri, 20 May 2005 15:39:14 -0400 (EDT) To: ietf-pkix@imc.org Subject: Re: Request for new work item - Defining an SRV RR otherName From: Sam Hartman Date: Fri, 20 May 2005 15:39:14 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. I'm speaking as an individual not as an AD. This proposal was originally introduced as a use of dnsname in the Kerberos working group for pkinit. The authors of the proposal would like to name services as they are identified by users. For example a user types foo.bar.example.com into some program. The program looks up a SRV record for some service and then connects to that service. If insecure DNS is used then the dns lookup should not be part of the name against which a certificate is checkde. We're seeing a similar situation in the kitten working group ; see draft-ietf-kitten-gssapi-domain-based-names-00.txt. The idea of this proposal is that the certificate contain the name that the client system would look up in the same form as the client uses to look in DNS. I'm not sure how this proposal has evolved since it was first presented to me. Originally the goal was so that application libraries could use some sort of automatic mechanism to: * Look up SRV records * Bind to TLS certificates * Find the Kerberos principal name * Bind to pkinit certificates. All the application author would do would be to pass the service protocol and name into some magic function. That bothers me. There is no guarantee that the SRV record tag will match the GSS/Kerberos principal name. There is no guarantee that the service in question doesn't have some better choice for certificate binding like one of the IMPP-specific solutions. I'm also not quite sure that SRV tags are real/really the right thing to be binding to. If the PKIX working group does adopt this proposal I would recommend being very careful. Make sure to scope it only to be used for applications/services where it is appropriate. Make sure to discuss applications that already have a mechanism for binding their certificates. It might also be important to find out if there is actually a use case for this name type before standardizing it. There wasn't really that much support in krb-wg for the earlier version of this. --Sam From owner-ietf-pkix@mail.imc.org Fri May 20 19:34:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27013 for ; Fri, 20 May 2005 19:34:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KMiq07098243; Fri, 20 May 2005 15:44:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KMiqTl098242; Fri, 20 May 2005 15:44:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KMipUm098197 for ; Fri, 20 May 2005 15:44:51 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 23:44:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Fri, 20 May 2005 23:44:38 +0100 Message-ID: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVdeiEOK9B4RpTtSGeuNKNrSv6I4QABkYaQ From: "Stefan Santesson" To: "Sam Hartman" , X-OriginalArrivalTime: 20 May 2005 22:44:45.0746 (UTC) FILETIME=[85430120:01C55D8D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KMipUm098237 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sam, My recollection of this issue is a bit different from yours. The central need here is to enable the KDC to express in a certificate the fact that it is a KDC in a way that male sense to clients. In a traditional Kerberos environment the KDC can be known as a KDC since it can demonstrate knowledge of the user's key. In PKI initiated Kerberos, this property is lost. If the client knows the host name, IP address or any other identity of the KDC, which can be mapped to information in the KDC certificate, then we are good and appropriate binding is possible. However, from what I have learned, we may face situations where a client only know the name of the domain it wants to access and the fact that it looks for a PKINIT enabled KDC. In this case it is assumed that the client would do a SRV RR query to the DNS to get the host name of the currently available KDC. If the SRV RR is NOT the appropriate name to bind to in this case, then my question is what the alternative is. Finally, the reason to do this in PKIX is since this in principle is a generic way of service discovery that may be useful also for other services where the client only know service name, protocol and domain. I have indications that it is becoming more and more interesting to dynamically search for services in this manner for other services but I'm very interested of other opinions here. I don't however understand in what way we need to be careful to limit this only to some specific services. Could you clarify this concern? /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Sam Hartman > Sent: den 20 maj 2005 12:39 > To: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > > Hi. I'm speaking as an individual not as an AD. > > This proposal was originally introduced as a use of dnsname in the > Kerberos working group for pkinit. > > The authors of the proposal would like to name services as they are > identified by users. For example a user types foo.bar.example.com > into some program. The program looks up a SRV record for some service > and then connects to that service. If insecure DNS is used then the > dns lookup should not be part of the name against which a certificate > is checkde. > > We're seeing a similar situation in the kitten working group ; see > draft-ietf-kitten-gssapi-domain-based-names-00.txt. > > > The idea of this proposal is that the certificate contain the name > that the client system would look up in the same form as the client > uses to look in DNS. > > I'm not sure how this proposal has evolved since it was first > presented to me. Originally the goal was so that application > libraries could use some sort of automatic mechanism to: > > * Look up SRV records > > * Bind to TLS certificates > > * Find the Kerberos principal name > > * Bind to pkinit certificates. > > All the application author would do would be to pass the service > protocol and name into some magic function. > > That bothers me. There is no guarantee that the SRV record tag will > match the GSS/Kerberos principal name. There is no guarantee that the > service in question doesn't have some better choice for certificate > binding like one of the IMPP-specific solutions. > > > I'm also not quite sure that SRV tags are real/really the right thing > to be binding to. > > If the PKIX working group does adopt this proposal I would recommend > being very careful. Make sure to scope it only to be used for > applications/services where it is appropriate. Make sure to discuss > applications that already have a mechanism for binding their > certificates. > > It might also be important to find out if there is actually a use case > for this name type before standardizing it. There wasn't really that > much support in krb-wg for the earlier version of this. > > --Sam From owner-ietf-pkix@mail.imc.org Sat May 21 08:29:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14791 for ; Sat, 21 May 2005 08:29:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L57SeH016810; Fri, 20 May 2005 22:07:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4L57SZH016809; Fri, 20 May 2005 22:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L57Qx5016764 for ; Fri, 20 May 2005 22:07:27 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 May 2005 06:07:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Sat, 21 May 2005 06:07:16 +0100 Message-ID: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVdqjlzGfeXzgRTRJ69gx2kPtxlOgAFRDNA From: "Stefan Santesson" To: "Sam Hartman" Cc: X-OriginalArrivalTime: 21 May 2005 05:07:20.0487 (UTC) FILETIME=[F75A8370:01C55DC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4L57Rx5016800 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sorry for being a bit unclear. Yes, you could use the Kerberos principal name specifically for Kerberos but not for other service types. The benefit from the proposed SRV RR other name is that you could deploy a generic approach, which maps 1:1 to service lookup via DNS for a wider range of services and avoid different solutions for each service type. Yes, this means that we need to go through the pain to recognize a new otherName, but now when we have to go there, the thought is that we then may be better served with a more generic approach for client side service validation rather than doing it just for Kerberos. /Stefan > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: den 20 maj 2005 19:10 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > >>>>> "Stefan" == Stefan Santesson writes: > > Stefan> Sam, My recollection of this issue is a bit different from > Stefan> yours. > > Stefan> The central need here is to enable the KDC to express in a > Stefan> certificate the fact that it is a KDC in a way that male > Stefan> sense to clients. > > > If this is all you want, bind the KDC certificate to the TGS principal > for the realm. That's what Larry's pkinit 26 text does. > > The original problem with that solution is that it required CAs to > implement the kerberos OtherName. However this approach also requires > the CA to implement a new OtherName. From owner-ietf-pkix@mail.imc.org Sat May 21 08:29:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14857 for ; Sat, 21 May 2005 08:29:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L2A6sP066727; Fri, 20 May 2005 19:10:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4L2A6qb066726; Fri, 20 May 2005 19:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L2A4Uo066719 for ; Fri, 20 May 2005 19:10:05 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7065AE0063; Fri, 20 May 2005 22:09:47 -0400 (EDT) To: "Stefan Santesson" Cc: Subject: Re: Request for new work item - Defining an SRV RR otherName References: From: Sam Hartman Date: Fri, 20 May 2005 22:09:47 -0400 In-Reply-To: (Stefan Santesson's message of "Fri, 20 May 2005 23:44:38 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Stefan" == Stefan Santesson writes: Stefan> Sam, My recollection of this issue is a bit different from Stefan> yours. Stefan> The central need here is to enable the KDC to express in a Stefan> certificate the fact that it is a KDC in a way that male Stefan> sense to clients. If this is all you want, bind the KDC certificate to the TGS principal for the realm. That's what Larry's pkinit 26 text does. The original problem with that solution is that it required CAs to implement the kerberos OtherName. However this approach also requires the CA to implement a new OtherName. From owner-ietf-pkix@mail.imc.org Mon May 23 13:31:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16835 for ; Mon, 23 May 2005 13:31:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NGLMGV060385; Mon, 23 May 2005 09:21:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4NGLM39060384; Mon, 23 May 2005 09:21:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NGLKp1060363 for ; Mon, 23 May 2005 09:21:21 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 17:21:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Mon, 23 May 2005 17:21:08 +0100 Message-ID: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVdqjlzGfeXzgRTRJ69gx2kPtxlOgAFRDNAAHz7flA= From: "Stefan Santesson" To: "Sam Hartman" Cc: X-OriginalArrivalTime: 23 May 2005 16:21:15.0140 (UTC) FILETIME=[711C6C40:01C55FB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NGLLp1060379 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit FYI The SRV RR draft is now available from internet-drafts. http://www.ietf.org/internet-drafts/draft-santesson-pkix-srvrr-00.txt /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Stefan Santesson > Sent: den 20 maj 2005 22:07 > To: Sam Hartman > Cc: ietf-pkix@imc.org > Subject: RE: Request for new work item - Defining an SRV RR otherName > > > Sorry for being a bit unclear. > Yes, you could use the Kerberos principal name specifically for Kerberos > but not for other service types. > > The benefit from the proposed SRV RR other name is that you could deploy > a generic approach, which maps 1:1 to service lookup via DNS for a wider > range of services and avoid different solutions for each service type. > > Yes, this means that we need to go through the pain to recognize a new > otherName, but now when we have to go there, the thought is that we then > may be better served with a more generic approach for client side > service validation rather than doing it just for Kerberos. > > /Stefan > > > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: den 20 maj 2005 19:10 > > To: Stefan Santesson > > Cc: ietf-pkix@imc.org > > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > >>>>> "Stefan" == Stefan Santesson writes: > > > > Stefan> Sam, My recollection of this issue is a bit different from > > Stefan> yours. > > > > Stefan> The central need here is to enable the KDC to express in a > > Stefan> certificate the fact that it is a KDC in a way that male > > Stefan> sense to clients. > > > > > > If this is all you want, bind the KDC certificate to the TGS principal > > for the realm. That's what Larry's pkinit 26 text does. > > > > The original problem with that solution is that it required CAs to > > implement the kerberos OtherName. However this approach also requires > > the CA to implement a new OtherName. From owner-ietf-pkix@mail.imc.org Mon May 23 16:39:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18667 for ; Mon, 23 May 2005 16:39:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NJkBZd024137; Mon, 23 May 2005 12:46:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4NJkBfC024136; Mon, 23 May 2005 12:46:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NJkA7e024128 for ; Mon, 23 May 2005 12:46:10 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03424; Mon, 23 May 2005 15:46:08 -0400 (EDT) Message-Id: <200505231946.PAA03424@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-sim-04.txt Date: Mon, 23 May 2005 15:46:07 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) Author(s) : J. Park, et al. Filename : draft-ietf-pkix-sim-04.txt Pages : 16 Date : 2005-5-23 This document defines Privacy-Enhanced Protected Subject Identifier (PEPSI) format for including a privacy sensitive identifier in the subjectAltName extension of a certificate. The PEPSI is an optional feature that may be used by a relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-sim-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-sim-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-23145024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-sim-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-sim-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-23145024.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Mon May 23 18:06:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02630 for ; Mon, 23 May 2005 18:06:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NLFu1c050710; Mon, 23 May 2005 14:15:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4NLFujQ050708; Mon, 23 May 2005 14:15:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NLFt9u050682 for ; Mon, 23 May 2005 14:15:55 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4NLCS305214; Mon, 23 May 2005 14:12:28 -0700 (PDT) Message-Id: <200505232112.j4NLCS305214@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4043 on Internet X.509 Public Key Infrastructure Permanent Identifier Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 23 May 2005 14:12:28 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4043 Title: Internet X.509 Public Key Infrastructure Permanent Identifier Author(s): D. Pinkas, T. Gindin Status: Standards Track Date: May 2005 Mailbox: Denis.Pinkas@bull.net, tgindin@us.ibm.com Pages: 15 Characters: 30092 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-pi-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4043.txt This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050523141023.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4043 --OtherAccess Content-Type: Message/External-body; name="rfc4043.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050523141023.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-ietf-pkix@mail.imc.org Mon May 23 19:27:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13574 for ; Mon, 23 May 2005 19:27:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NMWH1T064202; Mon, 23 May 2005 15:32:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4NMWHjm064201; Mon, 23 May 2005 15:32:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ci.sugar-land.tx.us (mail.ci.sugar-land.tx.us [66.150.129.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NMWGJg064151 for ; Mon, 23 May 2005 15:32:17 -0700 (PDT) (envelope-from rfc-editor@rfc-editor.org) Received: from svrpd14 ([192.168.2.137]) by mail.ci.sugar-land.tx.us; Mon, 23 May 2005 17:31:44 -0500 MIME-Version: 1.0 Date: Mon, 23 May 2005 17:31:44 -0500 X-Priority: 3 (Normal) To: ietf-announce@ietf.org, ietf-pkix@imc.org, rfc-editor@rfc-editor.org Subject: RFC 4043 on Internet X.509 Public Key Infrastructure PermanentIdentifier From: rfc-editor@rfc-editor.org X-Mailer: GWAVA Archive Mailer Content-Type: multipart/mixed; boundary="----=_NextPart_bad_1948_5bfb4720.c4009003_.MIX" Message-ID: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new Request for Comments is now available in online RFC libraries. RFC 4043 Title: Internet X.509 Public Key Infrastructure Permanent Identifier Author(s): D. Pinkas, T. Gindin Status: Standards Track Date: May 2005 Mailbox: Denis.Pinkas@bull.net, tgindin@us.ibm.com Pages: 15 Characters: 30092 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-pi-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4043.txt This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute =2E.. Below is the data which will enable a MIME compliant Mail Reader=20 implementation to automatically retrieve the ASCII version of the RFCs. ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: application/octet-stream; name="2#Part.001" Content-Disposition: attachment; filename="2#Part.001" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxMDIzLlJG Q0BSRkMtRURJVE9SLk9SRz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDQzDQo= ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: text/plain; name="3#rfc4043.txt" Content-Disposition: attachment; filename="3#rfc4043.txt" Content-Transfer-Encoding: quoted-printable Content-Type: text/plain Content-ID: <050523141023.RFC@RFC-EDITOR.ORG> ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: application/octet-stream; name="4#Part.003" Content-Disposition: attachment; filename="4#Part.003" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQo= ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: application/octet-stream; name="5#Mime.822" Content-Disposition: attachment; filename="5#Mime.822" Content-Transfer-Encoding: base64 UmVjZWl2ZWQ6IGZyb20gbWVnYXRyb24uaWV0Zi5vcmcgWzEzMi4xNTEuNi43MV0NCglieSBt YWlsLmNpLnN1Z2FyLWxhbmQudHgudXM7IE1vbiwgMjMgTWF5IDIwMDUgMTY6MzU6MTYgLTA1 MDANClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdC5sb2NhbGRvbWFpbiAoWzEyNy4wLjAuMV0g aGVsbz1tZWdhdHJvbi5pZXRmLm9yZykNCglieSBtZWdhdHJvbi5pZXRmLm9yZyB3aXRoIGVz bXRwIChFeGltIDQuMzIpDQoJaWQgMURhS0hDLTAwMDNNRC05NzsgTW9uLCAyMyBNYXkgMjAw NSAxNzoxNTo1NCAtMDQwMA0KUmVjZWl2ZWQ6IGZyb20gb2Rpbi5pZXRmLm9yZyAoWzEzMi4x NTEuMS4xNzZdIGhlbG89aWV0Zi5vcmcpDQoJYnkgbWVnYXRyb24uaWV0Zi5vcmcgd2l0aCBl c210cCAoRXhpbSA0LjMyKSBpZCAxRGFLSDgtMDAwM000LTVCDQoJZm9yIGlldGYtYW5ub3Vu Y2VAbWVnYXRyb24uaWV0Zi5vcmc7IE1vbiwgMjMgTWF5IDIwMDUgMTc6MTU6NTAgLTA0MDAN ClJlY2VpdmVkOiBmcm9tIGlldGYtbXguaWV0Zi5vcmcgKGlldGYtbXguaWV0Zi5vcmcgWzEz Mi4xNTEuNi4xXSkNCglieSBpZXRmLm9yZyAoOC45LjFhLzguOS4xYSkgd2l0aCBFU01UUCBp ZCBSQUEyMTc2Ng0KCWZvciA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz47IE1vbiwgMjMgTWF5 IDIwMDUgMTc6MTU6NDggLTA0MDAgKEVEVCkNClJlY2VpdmVkOiBmcm9tIGJvcmVhcy5pc2ku ZWR1IChbMTI4LjkuMTYwLjE2MV0pDQoJYnkgaWV0Zi1teC5pZXRmLm9yZyB3aXRoIGVzbXRw IChFeGltIDQuMzMpIGlkIDFEYUtaQi0wMDAxSDEtOXcNCglmb3IgaWV0Zi1hbm5vdW5jZUBp ZXRmLm9yZzsgTW9uLCAyMyBNYXkgMjAwNSAxNzozNDoyOSAtMDQwMA0KUmVjZWl2ZWQ6IGZy b20gSVNJLkVEVSAoYWRtYS5pc2kuZWR1IFsxMjguOS4xNjAuMjM5XSkNCglieSBib3JlYXMu aXNpLmVkdSAoOC4xMS42cDIrMDkxNy84LjExLjIpIHdpdGggRVNNVFAgaWQgajROTENTMzA1 MjE0Ow0KCU1vbiwgMjMgTWF5IDIwMDUgMTQ6MTI6MjggLTA3MDAgKFBEVCkNCk1lc3NhZ2Ut SWQ6IDwyMDA1MDUyMzIxMTIuajROTENTMzA1MjE0QGJvcmVhcy5pc2kuZWR1Pg0KVG86IGll dGYtYW5ub3VuY2VAaWV0Zi5vcmcNCkZyb206IHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcN Ck1pbWUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6IE11bHRpcGFydC9NaXhlZDsgQm91 bmRhcnk9TmV4dFBhcnQNCkRhdGU6IE1vbiwgMjMgTWF5IDIwMDUgMTQ6MTI6MjggLTA3MDAN ClgtSVNJLTQtMzktNi1NYWlsU2Nhbm5lcjogRm91bmQgdG8gYmUgY2xlYW4NClgtTWFpbFNj YW5uZXItRnJvbTogcmZjLWVkQGlzaS5lZHUNClgtU3BhbS1TY29yZTogLTE0LjYgKC0tLS0t LS0tLS0tLS0tKQ0KWC1TY2FuLVNpZ25hdHVyZTogYzgzY2NiNWNjMTBlNzUxNDk2Mzk4ZjEy MzNjYTljM2ENCkNjOiBpZXRmLXBraXhAaW1jLm9yZywgcmZjLWVkaXRvckByZmMtZWRpdG9y Lm9yZw0KU3ViamVjdDogUkZDIDQwNDMgb24gSW50ZXJuZXQgWC41MDkgUHVibGljIEtleSBJ bmZyYXN0cnVjdHVyZSBQZXJtYW5lbnQNCglJZGVudGlmaWVyDQpYLUJlZW5UaGVyZTogaWV0 Zi1hbm5vdW5jZUBpZXRmLm9yZw0KWC1NYWlsbWFuLVZlcnNpb246IDIuMS41DQpQcmVjZWRl bmNlOiBsaXN0DQpMaXN0LUlkOiBpZXRmLWFubm91bmNlLmlldGYub3JnDQpMaXN0LVVuc3Vi c2NyaWJlOiA8aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1h bm5vdW5jZT4sDQoJPG1haWx0bzppZXRmLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3Vi amVjdD11bnN1YnNjcmliZT4NCkxpc3QtUG9zdDogPG1haWx0bzppZXRmLWFubm91bmNlQGll dGYub3JnPg0KTGlzdC1IZWxwOiA8bWFpbHRvOmlldGYtYW5ub3VuY2UtcmVxdWVzdEBpZXRm Lm9yZz9zdWJqZWN0PWhlbHA+DQpMaXN0LVN1YnNjcmliZTogPGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2U+LA0KCTxtYWlsdG86aWV0Zi1h bm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9c3Vic2NyaWJlPg0KU2VuZGVyOiBp ZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCkVycm9ycy1UbzogaWV0Zi1hbm5vdW5j ZS1ib3VuY2VzQGlldGYub3JnDQoNCg0KLS1OZXh0UGFydA0KDQoNCkEgbmV3IFJlcXVlc3Qg Zm9yIENvbW1lbnRzIGlzIG5vdyBhdmFpbGFibGUgaW4gb25saW5lIFJGQyBsaWJyYXJpZXMu DQoNCg0KICAgICAgICBSRkMgNDA0Mw0KDQogICAgICAgIFRpdGxlOiAgICAgIEludGVybmV0 IFguNTA5IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUNCiAgICAgICAgICAgICAgICAgICAg UGVybWFuZW50IElkZW50aWZpZXINCiAgICAgICAgQXV0aG9yKHMpOiAgRC4gUGlua2FzLCBU LiBHaW5kaW4NCiAgICAgICAgU3RhdHVzOiAgICAgU3RhbmRhcmRzIFRyYWNrDQogICAgICAg IERhdGU6ICAgICAgIE1heSAyMDA1DQogICAgICAgIE1haWxib3g6ICAgIERlbmlzLlBpbmth c0BidWxsLm5ldCwgdGdpbmRpbkB1cy5pYm0uY29tDQogICAgICAgIFBhZ2VzOiAgICAgIDE1 DQogICAgICAgIENoYXJhY3RlcnM6IDMwMDkyDQogICAgICAgIFVwZGF0ZXMvT2Jzb2xldGVz L1NlZUFsc286ICAgIE5vbmUNCg0KICAgICAgICBJLUQgVGFnOiAgICBkcmFmdC1pZXRmLXBr aXgtcGktMTEudHh0DQoNCiAgICAgICAgVVJMOiAgICAgICAgZnRwOi8vZnRwLnJmYy1lZGl0 b3Iub3JnL2luLW5vdGVzL3JmYzQwNDMudHh0DQoNCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgbmV3IGZvcm0gb2YgbmFtZSwgY2FsbGVkIHBlcm1hbmVudA0KaWRlbnRpZmllciwgdGhh dCBtYXkgYmUgaW5jbHVkZWQgaW4gdGhlIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbg0Kb2Yg YSBwdWJsaWMga2V5IGNlcnRpZmljYXRlIGlzc3VlZCB0byBhbiBlbnRpdHkuDQoNClRoZSBw ZXJtYW5lbnQgaWRlbnRpZmllciBpcyBhbiBvcHRpb25hbCBmZWF0dXJlIHRoYXQgbWF5IGJl IHVzZWQNCmJ5IGEgQ0EgdG8gaW5kaWNhdGUgdGhhdCB0d28gb3IgbW9yZSBjZXJ0aWZpY2F0 ZXMgcmVsYXRlIHRvIHRoZQ0Kc2FtZSBlbnRpdHksIGV2ZW4gaWYgdGhleSBjb250YWluIGRp ZmZlcmVudCBzdWJqZWN0IG5hbWUgKEROcykgb3INCmRpZmZlcmVudCBuYW1lcyBpbiB0aGUg c3ViamVjdEFsdE5hbWUgZXh0ZW5zaW9uLCBvciBpZiB0aGUgbmFtZQ0Kb3IgdGhlIGFmZmls aWF0aW9uIG9mIHRoYXQgZW50aXR5IHN0b3JlZCBpbiB0aGUgc3ViamVjdCBvciBhbm90aGVy DQpuYW1lIGZvcm0gaW4gdGhlIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbiBoYXMgY2hhbmdl ZC4NCg0KVGhlIHN1YmplY3QgbmFtZSwgY2FycmllZCBpbiB0aGUgc3ViamVjdCBmaWVsZCwg aXMgb25seSB1bmlxdWUNCmZvciBlYWNoIHN1YmplY3QgZW50aXR5IGNlcnRpZmllZCBieSB0 aGUgb25lIENBIGFzIGRlZmluZWQgYnkgdGhlDQppc3N1ZXIgbmFtZSBmaWVsZC4gIEhvd2V2 ZXIsIHRoZSBuZXcgbmFtZSBmb3JtIGNhbiBjYXJyeSBhDQpuYW1lIHRoYXQgaXMgdW5pcXVl IGZvciBlYWNoIHN1YmplY3QgZW50aXR5IGNlcnRpZmllZCBieSBhIENBLg0KDQpUaGlzIGRv Y3VtZW50IGlzIGEgcHJvZHVjdCBvZiB0aGUgUHVibGljLUtleSBJbmZyYXN0cnVjdHVyZSAo WC41MDkpDQpXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQpUaGlzIGlzIG5vdyBhIFBy b3Bvc2VkIFN0YW5kYXJkIFByb3RvY29sLg0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBh biBJbnRlcm5ldCBzdGFuZGFyZHMgdHJhY2sgcHJvdG9jb2wgZm9yDQp0aGUgSW50ZXJuZXQg Y29tbXVuaXR5LCBhbmQgcmVxdWVzdHMgZGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMNCmZv ciBpbXByb3ZlbWVudHMuICBQbGVhc2UgcmVmZXIgdG8gdGhlIGN1cnJlbnQgZWRpdGlvbiBv ZiB0aGUNCiJJbnRlcm5ldCBPZmZpY2lhbCBQcm90b2NvbCBTdGFuZGFyZHMiIChTVEQgMSkg Zm9yIHRoZQ0Kc3RhbmRhcmRpemF0aW9uIHN0YXRlIGFuZCBzdGF0dXMgb2YgdGhpcyBwcm90 b2NvbC4gIERpc3RyaWJ1dGlvbg0Kb2YgdGhpcyBtZW1vIGlzIHVubGltaXRlZC4NCg0KVGhp cyBhbm5vdW5jZW1lbnQgaXMgc2VudCB0byB0aGUgSUVURiBsaXN0IGFuZCB0aGUgUkZDLURJ U1QgbGlzdC4NClJlcXVlc3RzIHRvIGJlIGFkZGVkIHRvIG9yIGRlbGV0ZWQgZnJvbSB0aGUg SUVURiBkaXN0cmlidXRpb24gbGlzdA0Kc2hvdWxkIGJlIHNlbnQgdG8gSUVURi1SRVFVRVNU QElFVEYuT1JHLiAgUmVxdWVzdHMgdG8gYmUNCmFkZGVkIHRvIG9yIGRlbGV0ZWQgZnJvbSB0 aGUgUkZDLURJU1QgZGlzdHJpYnV0aW9uIGxpc3Qgc2hvdWxkDQpiZSBzZW50IHRvIFJGQy1E SVNULVJFUVVFU1RAUkZDLUVESVRPUi5PUkcuDQoNCkRldGFpbHMgb24gb2J0YWluaW5nIFJG Q3MgdmlhIEZUUCBvciBFTUFJTCBtYXkgYmUgb2J0YWluZWQgYnkgc2VuZGluZw0KYW4gRU1B SUwgbWVzc2FnZSB0byByZmMtaW5mb0BSRkMtRURJVE9SLk9SRyB3aXRoIHRoZSBtZXNzYWdl IGJvZHkgDQpoZWxwOiB3YXlzX3RvX2dldF9yZmNzLiAgRm9yIGV4YW1wbGU6DQoNCiAgICAg ICAgVG86IHJmYy1pbmZvQFJGQy1FRElUT1IuT1JHDQogICAgICAgIFN1YmplY3Q6IGdldHRp bmcgcmZjcw0KDQogICAgICAgIGhlbHA6IHdheXNfdG9fZ2V0X3JmY3MNCg0KUmVxdWVzdHMg Zm9yIHNwZWNpYWwgZGlzdHJpYnV0aW9uIHNob3VsZCBiZSBhZGRyZXNzZWQgdG8gZWl0aGVy IHRoZQ0KYXV0aG9yIG9mIHRoZSBSRkMgaW4gcXVlc3Rpb24sIG9yIHRvIFJGQy1NYW5hZ2Vy QFJGQy1FRElUT1IuT1JHLiAgVW5sZXNzDQpzcGVjaWZpY2FsbHkgbm90ZWQgb3RoZXJ3aXNl IG9uIHRoZSBSRkMgaXRzZWxmLCBhbGwgUkZDcyBhcmUgZm9yDQp1bmxpbWl0ZWQgZGlzdHJp YnV0aW9uLg0KDQpTdWJtaXNzaW9ucyBmb3IgUmVxdWVzdHMgZm9yIENvbW1lbnRzIHNob3Vs ZCBiZSBzZW50IHRvDQpSRkMtRURJVE9SQFJGQy1FRElUT1IuT1JHLiAgUGxlYXNlIGNvbnN1 bHQgUkZDIDIyMjMsIEluc3RydWN0aW9ucyB0byBSRkMNCkF1dGhvcnMsIGZvciBmdXJ0aGVy IGluZm9ybWF0aW9uLg0KDQoNCkpveWNlIEsuIFJleW5vbGRzIGFuZCBTYW5keSBHaW5vemEN ClVTQy9JbmZvcm1hdGlvbiBTY2llbmNlcyBJbnN0aXR1dGUNCg0KLi4uDQoNCkJlbG93IGlz IHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgTWFpbCBSZWFk ZXIgDQppbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJ SSB2ZXJzaW9uDQpvZiB0aGUgUkZDcy4NCg0KLS1OZXh0UGFydA0KQ29udGVudC1UeXBlOiBN dWx0aXBhcnQvQWx0ZXJuYXRpdmU7IEJvdW5kYXJ5PSJPdGhlckFjY2VzcyINCg0KLS1PdGhl ckFjY2Vzcw0KQ29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10 eXBlPSJtYWlsLXNlcnZlciI7DQoJc2VydmVyPSJSRkMtSU5GT0BSRkMtRURJVE9SLk9SRyIN Cg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxMDIz LlJGQ0BSRkMtRURJVE9SLk9SRz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDQz DQoNCi0tT3RoZXJBY2Nlc3MNCkNvbnRlbnQtVHlwZTogTWVzc2FnZS9FeHRlcm5hbC1ib2R5 OyBuYW1lPSJyZmM0MDQzLnR4dCI7IHNpdGU9ImZ0cC5pc2kuZWR1IjsNCglhY2Nlc3MtdHlw ZT0iYW5vbi1mdHAiOyBkaXJlY3Rvcnk9ImluLW5vdGVzIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6IDwwNTA1MjMxNDEwMjMuUkZDQFJGQy1FRElUT1IuT1JH Pg0KDQoNCi0tT3RoZXJBY2Nlc3MtLQ0KLS1OZXh0UGFydA0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50 LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBpbmxpbmUN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklF VEYtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQoNCi0t TmV4dFBhcnQtLQ0KDQo= ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: text/plain; name="GWAVADAT.TXT" Content-Disposition: attachment; filename="GWAVADAT.TXT" Content-Transfer-Encoding: quoted-printable AdmID:217BFB629F3CF22BFC888D9128A2CB31 ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX-- From owner-ietf-pkix@mail.imc.org Mon May 23 23:41:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28164 for ; Mon, 23 May 2005 23:41:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O2kwgE033041; Mon, 23 May 2005 19:46:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4O2kwBC033040; Mon, 23 May 2005 19:46:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O2kuXE033022 for ; Mon, 23 May 2005 19:46:57 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4O2koRk013793 for ; Mon, 23 May 2005 22:46:51 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4O2ko2H122012 for ; Mon, 23 May 2005 22:46:50 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4O2kooC017782 for ; Mon, 23 May 2005 22:46:50 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4O2kokZ017778; Mon, 23 May 2005 22:46:50 -0400 In-Reply-To: <5.1.0.14.2.20050510170022.02cc5b08@email.nist.gov> To: wpolk@nist.gov Cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, stefans@microsoft.com MIME-Version: 1.0 Subject: Re: WG Last Call: AIA CRL extension X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Mon, 23 May 2005 22:46:48 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/23/2005 22:46:50, Serialize complete at 05/23/2005 22:46:50 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim: I should probably have brought this up earlier, but are we certain that "same trust anchor" is a strong enough check that the CRL signer is the one expected by the issuing CA? While I was not in San Diego when this wording was included in the 3280 series, I do not really think that that check is strong enough. I would suggest instead that the CRL signer's certificate needs to be directly issued by one of the CA's in the certification path back to the trust anchor used for the certificate's verification, or by that anchor itself, unless people have practical experience with CA structures which that rule would prohibit. Forcing the CRL to be issued by the CA itself (as I understand Denis to have suggested) prohibits the reasonable case where the CRL is issued by a hierarchical superior, so it is IMHO too strict. I am personally not sure, FWIW, that a CRL should be permitted to be signed by a second-cousin certificate of the issuer's certificate. By analogy to the use of the terms in families, "sibling" certificates would have the same issuer, "first-cousin" certificates would be issued by siblings, and "second-cousin" certificates would be issued by first cousins - so they are both three levels down from the same trust anchor, or from the last common CA in their paths. This issue is not newly caused by CRL AIA, since the same issue can arise with CRL's containing only AKID. AIA only allows RP's to build a path (whether right or wrong) more quickly. In any case, nothing more than a note in Security Considerations is appropriate in any of our RFC's other than 3280 and its successor. Tom Gindin P.S. - The above views are mine, and not necessarily those of my employer Tim Polk Sent by: owner-ietf-pkix@mail.imc.org 05/10/2005 05:27 PM To: ietf-pkix@imc.org cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com Subject: WG Last Call: AIA CRL extension This message initiates working group Last Call for the specification "Internet X.509 Public Key Infrastructure: Authority Information Access CRL Extension". While some issues raised in the working group are unresolved, the editors believe that rough consensus supports the current specification. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt Last Call will run for (at least) two weeks. That is, Last Call will not close before May 24. Thanks, Tim Polk From owner-ietf-pkix@mail.imc.org Tue May 24 00:10:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29845 for ; Tue, 24 May 2005 00:10:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O3BvNZ037886; Mon, 23 May 2005 20:11:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4O3BvB6037885; Mon, 23 May 2005 20:11:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O3BtcV037851 for ; Mon, 23 May 2005 20:11:56 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4O3Bomr001257 for ; Mon, 23 May 2005 23:11:50 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4O3Bo2H055824 for ; Mon, 23 May 2005 23:11:50 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4O3Bo6F014877 for ; Mon, 23 May 2005 23:11:50 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4O3BnFw014803; Mon, 23 May 2005 23:11:50 -0400 In-Reply-To: To: "Stefan Santesson" Cc: "Sam Hartman" , ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: Request for new work item - Defining an SRV RR otherName X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Mon, 23 May 2005 23:10:38 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/23/2005 23:11:50, Serialize complete at 05/23/2005 23:11:50 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: Maybe I'm being a bit thick here, but do you really intend to include the entire RR contents, including the weight, target and port, in this otherName? Or do you intend to include only the lookup key (_service._protocol.DNSName) instead? Some of your wording makes IMHO more sense in that case, and the assertion you're conveying is "the CA issuer has authorized this entity to provide this service for this domain". Whatever may be the case for Kerberos, I don't see why this feature is problematic for (say) LDAP, except insofar as it's an argument for name constraints. I do think that you'd need to state that the use of this field in a certificate is governed by DNSName name constraints. Tom Gindin "Stefan Santesson" Sent by: owner-ietf-pkix@mail.imc.org 05/20/2005 06:44 PM To: "Sam Hartman" , cc: Subject: RE: Request for new work item - Defining an SRV RR otherName Sam, My recollection of this issue is a bit different from yours. The central need here is to enable the KDC to express in a certificate the fact that it is a KDC in a way that male sense to clients. In a traditional Kerberos environment the KDC can be known as a KDC since it can demonstrate knowledge of the user's key. In PKI initiated Kerberos, this property is lost. If the client knows the host name, IP address or any other identity of the KDC, which can be mapped to information in the KDC certificate, then we are good and appropriate binding is possible. However, from what I have learned, we may face situations where a client only know the name of the domain it wants to access and the fact that it looks for a PKINIT enabled KDC. In this case it is assumed that the client would do a SRV RR query to the DNS to get the host name of the currently available KDC. If the SRV RR is NOT the appropriate name to bind to in this case, then my question is what the alternative is. Finally, the reason to do this in PKIX is since this in principle is a generic way of service discovery that may be useful also for other services where the client only know service name, protocol and domain. I have indications that it is becoming more and more interesting to dynamically search for services in this manner for other services but I'm very interested of other opinions here. I don't however understand in what way we need to be careful to limit this only to some specific services. Could you clarify this concern? /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Sam Hartman > Sent: den 20 maj 2005 12:39 > To: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > > Hi. I'm speaking as an individual not as an AD. > > This proposal was originally introduced as a use of dnsname in the > Kerberos working group for pkinit. > > The authors of the proposal would like to name services as they are > identified by users. For example a user types foo.bar.example.com > into some program. The program looks up a SRV record for some service > and then connects to that service. If insecure DNS is used then the > dns lookup should not be part of the name against which a certificate > is checkde. > > We're seeing a similar situation in the kitten working group ; see > draft-ietf-kitten-gssapi-domain-based-names-00.txt. > > > The idea of this proposal is that the certificate contain the name > that the client system would look up in the same form as the client > uses to look in DNS. > > I'm not sure how this proposal has evolved since it was first > presented to me. Originally the goal was so that application > libraries could use some sort of automatic mechanism to: > > * Look up SRV records > > * Bind to TLS certificates > > * Find the Kerberos principal name > > * Bind to pkinit certificates. > > All the application author would do would be to pass the service > protocol and name into some magic function. > > That bothers me. There is no guarantee that the SRV record tag will > match the GSS/Kerberos principal name. There is no guarantee that the > service in question doesn't have some better choice for certificate > binding like one of the IMPP-specific solutions. > > > I'm also not quite sure that SRV tags are real/really the right thing > to be binding to. > > If the PKIX working group does adopt this proposal I would recommend > being very careful. Make sure to scope it only to be used for > applications/services where it is appropriate. Make sure to discuss > applications that already have a mechanism for binding their > certificates. > > It might also be important to find out if there is actually a use case > for this name type before standardizing it. There wasn't really that > much support in krb-wg for the earlier version of this. > > --Sam From owner-ietf-pkix@mail.imc.org Tue May 24 00:21:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00418 for ; Tue, 24 May 2005 00:21:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O3BuYX037876; Mon, 23 May 2005 20:11:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4O3Bu8s037875; Mon, 23 May 2005 20:11:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O3BsVO037834 for ; Mon, 23 May 2005 20:11:55 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4O3BnmO030459 for ; Mon, 23 May 2005 23:11:49 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4O3Bn2H117414 for ; Mon, 23 May 2005 23:11:49 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4O3BmcA012182 for ; Mon, 23 May 2005 23:11:49 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4O3BmfM012135; Mon, 23 May 2005 23:11:48 -0400 In-Reply-To: To: "Stefan Santesson" Cc: "Sam Hartman" , ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: Request for new work item - Defining an SRV RR otherName X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Mon, 23 May 2005 23:10:38 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/23/2005 23:11:48, Serialize complete at 05/23/2005 23:11:48 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: Maybe I'm being a bit thick here, but do you really intend to include the entire RR contents, including the weight, target and port, in this otherName? Or do you intend to include only the lookup key (_service._protocol.DNSName) instead? Some of your wording makes IMHO more sense in that case, and the assertion you're conveying is "the CA issuer has authorized this entity to provide this service for this domain". Whatever may be the case for Kerberos, I don't see why this feature is problematic for (say) LDAP, except insofar as it's an argument for name constraints. I do think that you'd need to state that the use of this field in a certificate is governed by DNSName name constraints. Tom Gindin "Stefan Santesson" Sent by: owner-ietf-pkix@mail.imc.org 05/20/2005 06:44 PM To: "Sam Hartman" , cc: Subject: RE: Request for new work item - Defining an SRV RR otherName Sam, My recollection of this issue is a bit different from yours. The central need here is to enable the KDC to express in a certificate the fact that it is a KDC in a way that male sense to clients. In a traditional Kerberos environment the KDC can be known as a KDC since it can demonstrate knowledge of the user's key. In PKI initiated Kerberos, this property is lost. If the client knows the host name, IP address or any other identity of the KDC, which can be mapped to information in the KDC certificate, then we are good and appropriate binding is possible. However, from what I have learned, we may face situations where a client only know the name of the domain it wants to access and the fact that it looks for a PKINIT enabled KDC. In this case it is assumed that the client would do a SRV RR query to the DNS to get the host name of the currently available KDC. If the SRV RR is NOT the appropriate name to bind to in this case, then my question is what the alternative is. Finally, the reason to do this in PKIX is since this in principle is a generic way of service discovery that may be useful also for other services where the client only know service name, protocol and domain. I have indications that it is becoming more and more interesting to dynamically search for services in this manner for other services but I'm very interested of other opinions here. I don't however understand in what way we need to be careful to limit this only to some specific services. Could you clarify this concern? /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Sam Hartman > Sent: den 20 maj 2005 12:39 > To: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > > Hi. I'm speaking as an individual not as an AD. > > This proposal was originally introduced as a use of dnsname in the > Kerberos working group for pkinit. > > The authors of the proposal would like to name services as they are > identified by users. For example a user types foo.bar.example.com > into some program. The program looks up a SRV record for some service > and then connects to that service. If insecure DNS is used then the > dns lookup should not be part of the name against which a certificate > is checkde. > > We're seeing a similar situation in the kitten working group ; see > draft-ietf-kitten-gssapi-domain-based-names-00.txt. > > > The idea of this proposal is that the certificate contain the name > that the client system would look up in the same form as the client > uses to look in DNS. > > I'm not sure how this proposal has evolved since it was first > presented to me. Originally the goal was so that application > libraries could use some sort of automatic mechanism to: > > * Look up SRV records > > * Bind to TLS certificates > > * Find the Kerberos principal name > > * Bind to pkinit certificates. > > All the application author would do would be to pass the service > protocol and name into some magic function. > > That bothers me. There is no guarantee that the SRV record tag will > match the GSS/Kerberos principal name. There is no guarantee that the > service in question doesn't have some better choice for certificate > binding like one of the IMPP-specific solutions. > > > I'm also not quite sure that SRV tags are real/really the right thing > to be binding to. > > If the PKIX working group does adopt this proposal I would recommend > being very careful. Make sure to scope it only to be used for > applications/services where it is appropriate. Make sure to discuss > applications that already have a mechanism for binding their > certificates. > > It might also be important to find out if there is actually a use case > for this name type before standardizing it. There wasn't really that > much support in krb-wg for the earlier version of this. > > --Sam From owner-ietf-pkix@mail.imc.org Tue May 24 00:58:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02382 for ; Tue, 24 May 2005 00:58:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O408Ph053502; Mon, 23 May 2005 21:00:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4O4089c053501; Mon, 23 May 2005 21:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O4067U053442 for ; Mon, 23 May 2005 21:00:07 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 05:00:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Tue, 24 May 2005 04:59:54 +0100 Message-ID: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVgDlSoP4TVHzHCRAOP3e5pHb6BCgABiZ6g From: "Stefan Santesson" To: "Tom Gindin" Cc: "Sam Hartman" , X-OriginalArrivalTime: 24 May 2005 04:00:00.0481 (UTC) FILETIME=[0E8FC510:01C56015] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4O4077U053493 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Yes, The intention was actually primary to include the lookup key. Yes there are some clarifications needed in this aspect but I waited with trying to formulate the limitations until we have got a bit further towards accepting the work item. Thanks for noticing the issue. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com] > Sent: den 23 maj 2005 20:11 > To: Stefan Santesson > Cc: Sam Hartman; ietf-pkix@imc.org > Subject: RE: Request for new work item - Defining an SRV RR otherName > > Stefan: > > Maybe I'm being a bit thick here, but do you really intend to > include the entire RR contents, including the weight, target and port, in > this otherName? Or do you intend to include only the lookup key > (_service._protocol.DNSName) instead? Some of your wording makes IMHO > more sense in that case, and the assertion you're conveying is "the CA > issuer has authorized this entity to provide this service for this > domain". > Whatever may be the case for Kerberos, I don't see why this > feature is problematic for (say) LDAP, except insofar as it's an argument > for name constraints. I do think that you'd need to state that the use of > this field in a certificate is governed by DNSName name constraints. > > Tom Gindin > > > > > > > "Stefan Santesson" > Sent by: owner-ietf-pkix@mail.imc.org > 05/20/2005 06:44 PM > > To: "Sam Hartman" , > cc: > Subject: RE: Request for new work item - Defining an SRV RR > otherName > > > Sam, > > My recollection of this issue is a bit different from yours. > > The central need here is to enable the KDC to express in a certificate > the fact that it is a KDC in a way that male sense to clients. > > In a traditional Kerberos environment the KDC can be known as a KDC > since it can demonstrate knowledge of the user's key. > > In PKI initiated Kerberos, this property is lost. > > If the client knows the host name, IP address or any other identity of > the KDC, which can be mapped to information in the KDC certificate, then > we are good and appropriate binding is possible. > > However, from what I have learned, we may face situations where a client > only know the name of the domain it wants to access and the fact that it > looks for a PKINIT enabled KDC. In this case it is assumed that the > client would do a SRV RR query to the DNS to get the host name of the > currently available KDC. > > If the SRV RR is NOT the appropriate name to bind to in this case, then > my question is what the alternative is. > > > Finally, the reason to do this in PKIX is since this in principle is a > generic way of service discovery that may be useful also for other > services where the client only know service name, protocol and domain. I > have indications that it is becoming more and more interesting to > dynamically search for services in this manner for other services but > I'm very interested of other opinions here. > > I don't however understand in what way we need to be careful to limit > this only to some specific services. Could you clarify this concern? > > /Stefan > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Sam Hartman > > Sent: den 20 maj 2005 12:39 > > To: ietf-pkix@imc.org > > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > > > > > > > Hi. I'm speaking as an individual not as an AD. > > > > This proposal was originally introduced as a use of dnsname in the > > Kerberos working group for pkinit. > > > > The authors of the proposal would like to name services as they are > > identified by users. For example a user types foo.bar.example.com > > into some program. The program looks up a SRV record for some service > > and then connects to that service. If insecure DNS is used then the > > dns lookup should not be part of the name against which a certificate > > is checkde. > > > > We're seeing a similar situation in the kitten working group ; see > > draft-ietf-kitten-gssapi-domain-based-names-00.txt. > > > > > > The idea of this proposal is that the certificate contain the name > > that the client system would look up in the same form as the client > > uses to look in DNS. > > > > I'm not sure how this proposal has evolved since it was first > > presented to me. Originally the goal was so that application > > libraries could use some sort of automatic mechanism to: > > > > * Look up SRV records > > > > * Bind to TLS certificates > > > > * Find the Kerberos principal name > > > > * Bind to pkinit certificates. > > > > All the application author would do would be to pass the service > > protocol and name into some magic function. > > > > That bothers me. There is no guarantee that the SRV record tag will > > match the GSS/Kerberos principal name. There is no guarantee that the > > service in question doesn't have some better choice for certificate > > binding like one of the IMPP-specific solutions. > > > > > > I'm also not quite sure that SRV tags are real/really the right thing > > to be binding to. > > > > If the PKIX working group does adopt this proposal I would recommend > > being very careful. Make sure to scope it only to be used for > > applications/services where it is appropriate. Make sure to discuss > > applications that already have a mechanism for binding their > > certificates. > > > > It might also be important to find out if there is actually a use case > > for this name type before standardizing it. There wasn't really that > > much support in krb-wg for the earlier version of this. > > > > --Sam > > > From owner-ietf-pkix@mail.imc.org Tue May 24 11:31:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10868 for ; Tue, 24 May 2005 11:31:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEaRbM098522; Tue, 24 May 2005 07:36:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OEaRq9098521; Tue, 24 May 2005 07:36:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEaPbW098507 for ; Tue, 24 May 2005 07:36:26 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEaKQJ028816 for ; Tue, 24 May 2005 10:36:20 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OEaKLu144790 for ; Tue, 24 May 2005 10:36:20 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4OEaJtR003099 for ; Tue, 24 May 2005 10:36:20 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEaJgZ003087 for ; Tue, 24 May 2005 10:36:19 -0400 To: ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: WG Last Call: AIA CRL extension X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Tue, 24 May 2005 10:36:16 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/24/2005 10:36:19, Serialize complete at 05/24/2005 10:36:19 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is one scenario permitted by the "same trust anchor" rule for CRL signers which seems to me to be a serious security hole. Let us assume a valid CA which is a direct subordinate of one of the RP's trust anchors. This CA issues separate CRL's and ARL's, in a quite usual way, and issues cross certificates. After months or years of operation, it revokes one of its cross certificates because the subject's operator has gone rogue. That rogue subject then issues a fraudulent CRL Signing certificate with the DN that the superior certificate has been using to sign ARL's, a public key which it has newly generated, and various extensions including an SKID. It then issues an updated copy of an old ARL under the fraudulent CRL signer's certificate and with an AKID matching the fraudulent signer's SKID. If the rogue can break into the repository where the CRL is expected, this fraudulently issued CRL will probably be validated whether it contains an AIA or not. It will certainly pass the "same trust anchor" condition. This scenario, in which a rogue CA issues an ARL certifiying that its primary certificate has not been revoked and gets the ARL accepted, is possible under "same trust anchor" but not under "signed by path member". Tom Gindin ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- Tom Gindin 05/23/2005 10:46 PM To: wpolk@nist.gov cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, stefans@microsoft.com From: Tom Gindin/Watson/IBM@IBMUS Subject: Re: WG Last Call: AIA CRL extension Tim: I should probably have brought this up earlier, but are we certain that "same trust anchor" is a strong enough check that the CRL signer is the one expected by the issuing CA? While I was not in San Diego when this wording was included in the 3280 series, I do not really think that that check is strong enough. I would suggest instead that the CRL signer's certificate needs to be directly issued by one of the CA's in the certification path back to the trust anchor used for the certificate's verification, or by that anchor itself, unless people have practical experience with CA structures which that rule would prohibit. Forcing the CRL to be issued by the CA itself (as I understand Denis to have suggested) prohibits the reasonable case where the CRL is issued by a hierarchical superior, so it is IMHO too strict. I am personally not sure, FWIW, that a CRL should be permitted to be signed by a second-cousin certificate of the issuer's certificate. By analogy to the use of the terms in families, "sibling" certificates would have the same issuer, "first-cousin" certificates would be issued by siblings, and "second-cousin" certificates would be issued by first cousins - so they are both three levels down from the same trust anchor, or from the last common CA in their paths. This issue is not newly caused by CRL AIA, since the same issue can arise with CRL's containing only AKID. AIA only allows RP's to build a path (whether right or wrong) more quickly. In any case, nothing more than a note in Security Considerations is appropriate in any of our RFC's other than 3280 and its successor. Tom Gindin P.S. - The above views are mine, and not necessarily those of my employer Tim Polk Sent by: owner-ietf-pkix@mail.imc.org 05/10/2005 05:27 PM To: ietf-pkix@imc.org cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com Subject: WG Last Call: AIA CRL extension This message initiates working group Last Call for the specification "Internet X.509 Public Key Infrastructure: Authority Information Access CRL Extension". While some issues raised in the working group are unresolved, the editors believe that rough consensus supports the current specification. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt Last Call will run for (at least) two weeks. That is, Last Call will not close before May 24. Thanks, Tim Polk From owner-ietf-pkix@mail.imc.org Tue May 24 11:38:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11973 for ; Tue, 24 May 2005 11:38:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEvLSn000610; Tue, 24 May 2005 07:57:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OEvL4i000609; Tue, 24 May 2005 07:57:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEvJPi000603 for ; Tue, 24 May 2005 07:57:20 -0700 (PDT) (envelope-from Walter.Goulet@motorola.com) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4OF59P7026815 for ; Tue, 24 May 2005 08:05:10 -0700 (MST) Received: from il02exm15.corp.mot.com (il02exm15.corp.mot.com [10.0.111.27]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4OF19kj004327 for ; Tue, 24 May 2005 10:01:09 -0500 (CDT) Received: by il02exm15.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 May 2005 09:57:17 -0500 Message-ID: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> From: Goulet Walter-CWG009 To: "'ietf-pkix@imc.org'" Subject: Trying to relate PKCS & IETF standards to encoding rules Date: Tue, 24 May 2005 09:57:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56070.C8FDA77C" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C56070.C8FDA77C Content-Type: text/plain Hi, I'm trying to grasp how certificates and associated artifacts of PKI (private keys, CRLs, CSRs etc) are encoded and how the standards are related to eachother. My understanding of the relationships is: Standards for x.509 (spec. in RFC3280 and ITU-T x.509) as well as the various PKCS standards developed primarily by RSA labs are specified as ASN.1. ASN.1 cannot be directly encoded since it consists of abstract types, so the standards specify DER (which is a more restrictive BER encoding; basically it's a binary representation of ASN.1 values). PEM (defined in RFC 1421 - 1424, but what I care about is in 1421) defines a way to encode binary cryptographically sensitive data so it can be transported in text over SMTP. However, I haven't seen standards, notably for x.509 itself, that describe how to encode data from DER -> PEM. I suspect there must be a standard since for x.509 files there is a standard 'BEGIN CERTIFICATE/END CERTIFICATE' header and footer for certificates (and similarly, private keys and CSRs). Is there a set of RFCs that describes these standards? Maybe there is a standard describing in general how to encode from DER -> PEM and describes how the headers/footers are built. Any help would be appreciated. Thanks, - Walter Goulet walter.goulet@motorola.com Nextel: (847)366-9519 Pvt. ID 9519 Desk: (847)576-7036 ------_=_NextPart_001_01C56070.C8FDA77C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTguMiI+DQo8VElUTEU+VHJ5aW5nIHRv IHJlbGF0ZSBQS0NTICZhbXA7IElFVEYgc3RhbmRhcmRzIHRvIGVuY29kaW5nIHJ1bGVzPC9USVRM RT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkhpLDwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JJ20gdHJ5aW5nIHRv IGdyYXNwIGhvdyBjZXJ0aWZpY2F0ZXMgYW5kIGFzc29jaWF0ZWQgYXJ0aWZhY3RzIG9mIFBLSTwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPihwcml2YXRlIGtleXMsIENSTHMs IENTUnMgZXRjKSBhcmUgZW5jb2RlZCBhbmQgaG93IHRoZSBzdGFuZGFyZHMgYXJlPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+cmVsYXRlZCB0byBlYWNob3RoZXIuPC9GT05U Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk15IHVuZGVyc3RhbmRpbmcg b2YgdGhlIHJlbGF0aW9uc2hpcHMgaXM6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIg RkFDRT0iQXJpYWwiPlN0YW5kYXJkcyBmb3IgeC41MDkgKHNwZWMuIGluIFJGQzMyODAgYW5kIElU VS1UIHguNTA5KSBhcyB3ZWxsIGFzIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i QXJpYWwiPnZhcmlvdXMgUEtDUyBzdGFuZGFyZHMgZGV2ZWxvcGVkIHByaW1hcmlseSBieSBSU0Eg bGFicyBhcmUgc3BlY2lmaWVkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ YXMgQVNOLjEuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkFT Ti4xIGNhbm5vdCBiZSBkaXJlY3RseSBlbmNvZGVkIHNpbmNlIGl0IGNvbnNpc3RzIG9mIGFic3Ry YWN0IHR5cGVzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnNvIHRoZSBz dGFuZGFyZHMgc3BlY2lmeSBERVIgKHdoaWNoIGlzIGEgbW9yZSByZXN0cmljdGl2ZSBCRVI8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5lbmNvZGluZzsgYmFzaWNhbGx5IGl0 J3MgYSBiaW5hcnkgcmVwcmVzZW50YXRpb24gb2YgQVNOLjEgdmFsdWVzKS48L0ZPTlQ+DQo8L1A+ DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UEVNIChkZWZpbmVkIGluIFJGQyAxNDIx IC0gMTQyNCwgYnV0IHdoYXQgSSBjYXJlIGFib3V0IGlzIGluIDE0MjEpPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZGVmaW5lcyBhIHdheSB0byBlbmNvZGUgYmluYXJ5IGNy eXB0b2dyYXBoaWNhbGx5IHNlbnNpdGl2ZSBkYXRhIHNvIGl0PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+Y2FuIGJlIHRyYW5zcG9ydGVkIGluIHRleHQgb3ZlciBTTVRQLjwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Ib3dldmVyLCBJIGhh dmVuJ3Qgc2VlbiBzdGFuZGFyZHMsIG5vdGFibHkgZm9yIHguNTA5IGl0c2VsZiwgdGhhdDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmRlc2NyaWJlIGhvdyB0byBlbmNvZGUg ZGF0YSBmcm9tIERFUiAtJmd0OyBQRU0uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIg RkFDRT0iQXJpYWwiPkkgc3VzcGVjdCB0aGVyZSBtdXN0IGJlIGEgc3RhbmRhcmQgc2luY2UgZm9y IHguNTA5IGZpbGVzIHRoZXJlIGlzIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy aWFsIj5zdGFuZGFyZCAnQkVHSU4gQ0VSVElGSUNBVEUvRU5EIENFUlRJRklDQVRFJyBoZWFkZXIg YW5kIGZvb3RlciBmb3I8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jZXJ0 aWZpY2F0ZXMgKGFuZCBzaW1pbGFybHksIHByaXZhdGUga2V5cyBhbmQgQ1NScykuPC9GT05UPg0K PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPklzIHRoZXJlIGEgc2V0IG9mIFJG Q3MgdGhhdCBkZXNjcmliZXMgdGhlc2Ugc3RhbmRhcmRzPyBNYXliZSB0aGVyZSBpczwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmEgc3RhbmRhcmQgZGVzY3JpYmluZyBpbiBn ZW5lcmFsIGhvdyB0byBlbmNvZGUgZnJvbSBERVIgLSZndDsgUEVNIGFuZDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmRlc2NyaWJlcyBob3cgdGhlIGhlYWRlcnMvZm9vdGVy cyBhcmUgYnVpbHQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi PkFueSBoZWxwIHdvdWxkIGJlIGFwcHJlY2lhdGVkLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yIEZBQ0U9IkFyaWFsIj5UaGFua3MsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF PSJBcmlhbCI+LTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPldhbHRlciBH b3VsZXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj53YWx0ZXIuZ291bGV0 QG1vdG9yb2xhLmNvbSBOZXh0ZWw6ICg4NDcpMzY2LTk1MTkgUHZ0LiBJRCA5NTE5PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RGVzazogKDg0Nyk1NzYtNzAzNjwvRk9OVD4N CjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C56070.C8FDA77C-- From owner-ietf-pkix@mail.imc.org Tue May 24 12:23:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15851 for ; Tue, 24 May 2005 12:23:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFZakE003757; Tue, 24 May 2005 08:35:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OFZaCP003756; Tue, 24 May 2005 08:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFZZrK003742 for ; Tue, 24 May 2005 08:35:35 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4OFZS2o008998; Tue, 24 May 2005 11:35:29 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> References: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> Date: Tue, 24 May 2005 11:35:27 -0400 To: Goulet Walter-CWG009 From: Stephen Kent Subject: Re: Trying to relate PKCS & IETF standards to encoding rules Cc: "'ietf-pkix@imc.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Walter, The ITU-T X.509 and the IETF PKIX specs call for binary encoding of the ASN.1 for certs and CRLs, specifically DER, as you noted. PEM, which is now historical, also called for binary encoding (DER) of the ASN.1, and then specified the base64 encoding of the binary representation for "safe" carriage over SMTP. So the two sets of specs were not in conflict. It's just that PEM specified an additional layer of encoding for content transfer purposes, which is what MIME does as well, when necessary. DER to base64 is an easy encoding, because base64 takes any binary sytring and says how to encode it as text. Steve From owner-ietf-pkix@mail.imc.org Tue May 24 12:29:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16390 for ; Tue, 24 May 2005 12:29:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFZSNW003740; Tue, 24 May 2005 08:35:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OFZS61003739; Tue, 24 May 2005 08:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4OFZRxF003733 for ; Tue, 24 May 2005 08:35:28 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 26223 invoked by uid 0); 24 May 2005 15:35:22 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.170.22) by woodstock.binhost.com with SMTP; 24 May 2005 15:35:22 -0000 Message-Id: <6.2.1.2.2.20050524104606.03fab960@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 24 May 2005 11:35:10 -0400 To: Sam Hartman From: Russ Housley Subject: Re: AD Review for draft-ietf-pkix-rfc3770bis Cc: timmoore@microsoft.com, ietf-pkix@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam: Thanks for the AD review. It has improved the document. Here is how I addressed each of your comments. I have CCed the PKIX mail list to stan any WG member can raise the alarm if they do not like the way that any comment was resolved. >The document sites RFC 2284, not RFC 3748 which supersedes 2284. In >addition the document's terminology is inconsistent with RFC 3748. >EAP defines an exchange between a peer and an EAP server. The term >client is not typically used. My preference is that you fix the >terminology but this is not a requirement. The reference does need to >be updated. Also, I wonder whether it should be normative. [EAP] changed to normative, and it references RFC 3748. The terminology was updated to use "supplicant" when talking about 802.1X and "peer" when talking about EAP. The term "EAP server" is also used. >section 1: >There are two places in an EAP protocol where it seems obvious you >might want to use a certificate: the peer might want a certificate to >prove its identity to the EAP server and a EAP server might want a >certificate to prove its identity to the peer. This document deals >with the first case but does not make that clear. >The following change helps. > >s/for/by/ >old: > Automated selection of certificates for PPP and IEEE 802.1X clients > is highly desirable. By using certificate extensions to identify the >new: > Automated selection of certificates by PPP and IEEE 802.1X clients > is highly desirable. By using certificate extensions to identify the The "client" in this sentence causes problems with your earlier comment. How about: "Automated selection of client certificates for use with PPP and IEEE 802.1X is highly desirable." >I'd like to see text like the following worked into section 1 >though to make things completely clear. > > This document defines key usage values and certificate extensions to > be used in certificates issued to clients of PPP and wireless > networks. How about a new paragraph at the end of section 1: "This document defines extended key usage values and a WLAN-specific certificate extension for use in certificates issued to clients of PPP and WLANs." >section 2: > >Do these key purpose IDs apply to EAP server certificates or to client >certificates or to both? The intent was peer certificates. I do not recall any discussion of EAP server certificates using them. Proposed revision: "Inclusion of the EAP over PPP value indicates that the certified public key is appropriate for use by a peer with EAP in the PPP environment. The inclusion of the EAPOL value indicates that the certified public key is appropriate for use by a peer with the EAP in the LAN environment. Inclusion of both values indicates that the certified public key is appropriate for use by a peer in either of the environments." >The text quotes the description of extend key usages from RFC 3280 and >points out that an application can require extended key usage and a >particular KeyPurposeId. Is the intent for this to be defined by the >EAP method, the EAP method implementation, site policy, or something >else? How should implementers handle the situation where the EAP >implementation does not know what environment it is being used in? >(I'm not sure whether this situation is actually common.) I do not think there is a problem here. EAP methods that use certificates can require the presence of a particular KeyPurposeId, but I do not think that any have done so. >The extended key usage should presumably be checked both by the EAP peer >and the EAP server. The text should probably make this more clear. I see it more as a selection criteria when more than one certificate is available. >Section 3: > >The following text seems to be trying to imply that the ssid extension >can only be used with the extended key usage extension. If that's >true the requirement needs to be stated more clearly. However I don't >understand why you would want that requirement--it seems reasonable to >use the ssid extension with an application (EAP method) that does not >require extended key usage. > > When more than one certificate includes an extended key usage > extension indicating that the certified public key is appropriate for > use with the EAP in the LAN environment, then the list of SSIDs MAY > be used to select the correct certificate for authentication in a > particular WLAN. It is not a requirement. It is trying to say that the KeyPurposeId could narrow the certificate selection, and then this extension could provide further assistance. It is perfectly fine for only one of the extensions to be used. I suggest replacing the first paragraph of setcion 3 with: The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key certificate extension is always non-critical. It contains a list of SSIDs. The list of SSIDs MAY be used to select the correct certificate for authentication in a particular WLAN. If the extended key usage extension appears in the same certificate as the SSID extension, then the extended key usage extension MUST indicate that the certified public key is appropriate for use with the EAP in the LAN environment by including the id-kp-eapOverLAN KeyPurposeId value. -- Russ From owner-ietf-pkix@mail.imc.org Tue May 24 12:47:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18039 for ; Tue, 24 May 2005 12:47:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFu6Qe004827; Tue, 24 May 2005 08:56:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OFu6fa004826; Tue, 24 May 2005 08:56:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFu4aT004819 for ; Tue, 24 May 2005 08:56:05 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA44396; Tue, 24 May 2005 18:11:06 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052417555722:408 ; Tue, 24 May 2005 17:55:57 +0200 Message-ID: <42934ECA.3020508@bull.net> Date: Tue, 24 May 2005 17:56:58 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Tom Gindin CC: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/05/2005 17:55:57, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/05/2005 17:55:58, Serialize complete at 24/05/2005 17:55:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tom, Thank you for bringing water to my mill. :-) To respond to your previous e-mail, you said: "Forcing the CRL to be issued by the CA itself (as I understand Denis to have suggested) prohibits the reasonable case where the CRL is issued by a hierarchical superior, so it is IMHO too strict". I am saying that this case is secure. Expending it to the certification tree, would need to demonstrate that it is secure, ... and this has not be yet done at the moment (in particular for the case of same DN for the CRL issuer name). Denis > There is one scenario permitted by the "same trust anchor" rule > for CRL signers which seems to me to be a serious security hole. Let us > assume a valid CA which is a direct subordinate of one of the RP's trust > anchors. This CA issues separate CRL's and ARL's, in a quite usual way, > and issues cross certificates. After months or years of operation, it > revokes one of its cross certificates because the subject's operator has > gone rogue. That rogue subject then issues a fraudulent CRL Signing > certificate with the DN that the superior certificate has been using to > sign ARL's, a public key which it has newly generated, and various > extensions including an SKID. It then issues an updated copy of an old > ARL under the fraudulent CRL signer's certificate and with an AKID > matching the fraudulent signer's SKID. If the rogue can break into the > repository where the CRL is expected, this fraudulently issued CRL will > probably be validated whether it contains an AIA or not. It will > certainly pass the "same trust anchor" condition. > This scenario, in which a rogue CA issues an ARL certifiying that > its primary certificate has not been revoked and gets the ARL accepted, is > possible under "same trust anchor" but not under "signed by path member". > > Tom Gindin > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > > > Tom Gindin > 05/23/2005 10:46 PM > > To: wpolk@nist.gov > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, > stefans@microsoft.com > From: Tom Gindin/Watson/IBM@IBMUS > Subject: Re: WG Last Call: AIA CRL extension > > Tim: > > I should probably have brought this up earlier, but are we certain > that "same trust anchor" is a strong enough check that the CRL signer is > the one expected by the issuing CA? While I was not in San Diego when > this wording was included in the 3280 series, I do not really think that > that check is strong enough. I would suggest instead that the CRL > signer's certificate needs to be directly issued by one of the CA's in the > certification path back to the trust anchor used for the certificate's > verification, or by that anchor itself, unless people have practical > experience with CA structures which that rule would prohibit. Forcing the > CRL to be issued by the CA itself (as I understand Denis to have > suggested) prohibits the reasonable case where the CRL is issued by a > hierarchical superior, so it is IMHO too strict. > I am personally not sure, FWIW, that a CRL should be permitted to > be signed by a second-cousin certificate of the issuer's certificate. By > analogy to the use of the terms in families, "sibling" certificates would > have the same issuer, "first-cousin" certificates would be issued by > siblings, and "second-cousin" certificates would be issued by first > cousins - so they are both three levels down from the same trust anchor, > or from the last common CA in their paths. This issue is not newly caused > by CRL AIA, since the same issue can arise with CRL's containing only > AKID. AIA only allows RP's to build a path (whether right or wrong) more > quickly. > In any case, nothing more than a note in Security Considerations > is appropriate in any of our RFC's other than 3280 and its successor. > > Tom Gindin > P.S. - The above views are mine, and not necessarily those of my employer > > > > > > Tim Polk > Sent by: owner-ietf-pkix@mail.imc.org > 05/10/2005 05:27 PM > > To: ietf-pkix@imc.org > cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com > Subject: WG Last Call: AIA CRL extension > > > > > This message initiates working group Last Call for the specification > "Internet X.509 Public Key Infrastructure: Authority Information Access > CRL > Extension". While some issues raised in the working group are unresolved, > > the editors believe that rough consensus supports the current > specification. > > The URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > Last Call will run for (at least) two weeks. That is, Last Call will not > close before May 24. > > Thanks, > > Tim Polk > > > > > From owner-ietf-pkix@mail.imc.org Tue May 24 12:59:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18911 for ; Tue, 24 May 2005 12:59:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGDT2o006534; Tue, 24 May 2005 09:13:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OGDTvS006533; Tue, 24 May 2005 09:13:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4OGDSQR006510 for ; Tue, 24 May 2005 09:13:28 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 3B1B2100B7 for ; Tue, 24 May 2005 12:13:24 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22742-25 for ; Tue, 24 May 2005 12:13:11 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 5612A10084 for ; Tue, 24 May 2005 12:13:11 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005052412122949-37465 ; Tue, 24 May 2005 12:12:29 -0400 Date: Tue, 24 May 2005 12:13:10 -0400 From: Sam Roberts To: "'ietf-pkix@imc.org'" Subject: Re: Trying to relate PKCS & IETF standards to encoding rules Message-ID: <20050524161310.GA31429@certicom.com> Mail-Followup-To: "'ietf-pkix@imc.org'" References: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> Mime-Version: 1.0 In-Reply-To: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/24/2005 12:12:29 PM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/24/2005 12:12:30 PM, Serialize complete at 05/24/2005 12:12:30 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Goulet Walter-CWG009 , on Tue, May 24, 2005 at 09:57:13AM -0500: > Is there a set of RFCs that describes these standards? Maybe there is > a standard describing in general how to encode from DER -> PEM and > describes how the headers/footers are built. Not that I'm aware of, the names to use in the PEM headers are "customary", you have to see whats out there (and there is a fair amount of variation), and do what others do. Maybe an informational I-D would be useful to help bring some consistency to the practice. Cheers, Sam -- http://www.certicom.com From owner-ietf-pkix@mail.imc.org Tue May 24 13:25:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20630 for ; Tue, 24 May 2005 13:25:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGd7wL019774; Tue, 24 May 2005 09:39:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OGd7W4019772; Tue, 24 May 2005 09:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGd6Q1019734 for ; Tue, 24 May 2005 09:39:06 -0700 (PDT) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id E0C8F62D07; Tue, 24 May 2005 18:39:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id CC9DA440ED; Tue, 24 May 2005 18:39:37 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19169-04; Tue, 24 May 2005 18:39:31 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id D7FB7440AF; Tue, 24 May 2005 18:39:31 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 24 May 2005 18:38:58 +0200 From: "Julien Stern" Date: Tue, 24 May 2005 18:38:58 +0200 To: Tom Gindin Cc: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension Message-ID: <20050524163852.GA13889@cryptolog.com> Mail-Followup-To: Julien Stern , Tom Gindin , ietf-pkix@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > There is one scenario permitted by the "same trust anchor" rule > for CRL signers which seems to me to be a serious security hole. Let us > assume a valid CA which is a direct subordinate of one of the RP's trust > anchors. This CA issues separate CRL's and ARL's, in a quite usual way, > and issues cross certificates. After months or years of operation, it > revokes one of its cross certificates because the subject's operator has > gone rogue. That rogue subject then issues a fraudulent CRL Signing > certificate with the DN that the superior certificate has been using to > sign ARL's, a public key which it has newly generated, and various > extensions including an SKID. It then issues an updated copy of an old > ARL under the fraudulent CRL signer's certificate and with an AKID > matching the fraudulent signer's SKID. If the rogue can break into the > repository where the CRL is expected, this fraudulently issued CRL will > probably be validated whether it contains an AIA or not. It will > certainly pass the "same trust anchor" condition. > This scenario, in which a rogue CA issues an ARL certifiying that > its primary certificate has not been revoked and gets the ARL accepted, is > possible under "same trust anchor" but not under "signed by path member". I agree with the validity of this scenario. I believe this is very close to the issue I attempted to bring on the list a short time ago. Of course, it assumes the existence of a rogue CA at some point in time. Note that the CRL could be directly inserted into a "long term" signature (according to RFC3126 for example). This does not require a repository break-in and makes the "attack" even more realistic. Regards. -- Julien Stern > > Tom Gindin > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > > > Tom Gindin > 05/23/2005 10:46 PM > > To: wpolk@nist.gov > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, > stefans@microsoft.com > From: Tom Gindin/Watson/IBM@IBMUS > Subject: Re: WG Last Call: AIA CRL extension > > Tim: > > I should probably have brought this up earlier, but are we certain > that "same trust anchor" is a strong enough check that the CRL signer is > the one expected by the issuing CA? While I was not in San Diego when > this wording was included in the 3280 series, I do not really think that > that check is strong enough. I would suggest instead that the CRL > signer's certificate needs to be directly issued by one of the CA's in the > certification path back to the trust anchor used for the certificate's > verification, or by that anchor itself, unless people have practical > experience with CA structures which that rule would prohibit. Forcing the > CRL to be issued by the CA itself (as I understand Denis to have > suggested) prohibits the reasonable case where the CRL is issued by a > hierarchical superior, so it is IMHO too strict. > I am personally not sure, FWIW, that a CRL should be permitted to > be signed by a second-cousin certificate of the issuer's certificate. By > analogy to the use of the terms in families, "sibling" certificates would > have the same issuer, "first-cousin" certificates would be issued by > siblings, and "second-cousin" certificates would be issued by first > cousins - so they are both three levels down from the same trust anchor, > or from the last common CA in their paths. This issue is not newly caused > by CRL AIA, since the same issue can arise with CRL's containing only > AKID. AIA only allows RP's to build a path (whether right or wrong) more > quickly. > In any case, nothing more than a note in Security Considerations > is appropriate in any of our RFC's other than 3280 and its successor. > > Tom Gindin > P.S. - The above views are mine, and not necessarily those of my employer > > > > > > Tim Polk > Sent by: owner-ietf-pkix@mail.imc.org > 05/10/2005 05:27 PM > > To: ietf-pkix@imc.org > cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com > Subject: WG Last Call: AIA CRL extension > > > > > This message initiates working group Last Call for the specification > "Internet X.509 Public Key Infrastructure: Authority Information Access > CRL > Extension". While some issues raised in the working group are unresolved, > > the editors believe that rough consensus supports the current > specification. > > The URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > Last Call will run for (at least) two weeks. That is, Last Call will not > close before May 24. > > Thanks, > > Tim Polk > > > From owner-ietf-pkix@mail.imc.org Tue May 24 13:29:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21889 for ; Tue, 24 May 2005 13:29:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGed3P020785; Tue, 24 May 2005 09:40:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OGedd2020784; Tue, 24 May 2005 09:40:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGecAL020719 for ; Tue, 24 May 2005 09:40:38 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 17:40:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates Date: Tue, 24 May 2005 17:40:24 +0100 Message-ID: Thread-Topic: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates Thread-Index: AcVgDSuDicrMu1CBT4uAbJVfP4XUNgAcDOAgAABndaA= From: "Stefan Santesson" To: X-OriginalArrivalTime: 24 May 2005 16:40:32.0247 (UTC) FILETIME=[4D36B070:01C5607F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OGecAL020776 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Forwarding this also to the pkix WG for those who don't follow the Kerberos list. /Stefan -----Original Message----- From: Stefan Santesson Sent: den 24 maj 2005 09:37 To: 'Sam Hartman' Cc: Nicolas Williams; Liqiang(Larry) Zhu; ietf-krb-wg@anl.gov Subject: RE: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates Sam, Reading your reply actually makes me think that we are in agreement. I agree that it is impossible to bind to a SRV record unless a symbolic name has been defined and the security considerations assigned to that definition should always be followed. However, I can't see that you need to do more than that. Once the symbolic name has been defined and it is used according to it's definition and security considerations to discover services, then I can't se any negative security effects from binding that SRV RR name to a public key certificate to enable authentication of the host's authorization to deliver that service. In summary I don't think it is reasonable for a standard defining an otherName for a SRV RR to explicitly define what services it can be used with. But I would agree to describe the principles in the security considerations. /Stefan > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: den 23 maj 2005 20:03 > To: Stefan Santesson > Cc: Nicolas Williams; Liqiang(Larry) Zhu; ietf-krb-wg@anl.gov > Subject: Re: Required binding method - Was RE: PKINIT-26 changes: > identifying the kdc certificates > > >>>>> "Stefan" == Stefan Santesson writes: > > Stefan> Sam, > > >> I hope the PKIX working group does not approve a version of the > >> SRV OtherName that would allow it to be used with an > >> application without some standard enabling such usage. So I > >> would expect some document to explicitly mention that it can be > >> used with pkinit. But I agree that if PKIX were to approve an > >> overly broad standard, the current text would allow it to be > >> used. > >> > >> > > Stefan> [Stefan] I don't think you can constrain its usage in a > Stefan> PKIX RFC or force some RFC to enable it for each service > Stefan> type. > > Stefan> RFC 2782 already makes it possible to bind to a service > Stefan> only based on service name, protocol and domain. There are > Stefan> no limitations to that. > > > Please See the following text from RFC 2782: > > > Applicability Statement > > In general, it is expected that SRV records will be used by clients > for applications where the relevant protocol specification > indicates > that clients should use the SRV record. Such specification MUST > define the symbolic name to be used in the Service field of > the SRV > record as described below. It also MUST include security > considerations. Service SRV records SHOULD NOT be used > in the absence > of such specification. > > > > So your proposal clearly should not be used for applications that do > not use SRV records in the first place. Some applications that use > SRV records (most of the IMPP protocols fall into this examlpe) > already specify how certificates should be bound to these > applications. It is undesirable to have two methods of doing the same > certificate binding without compelling reason to do so.Failing this > would lead to decreased interoperability. From this I conclude that > your name type should only be used when explicitly specified. Things > are of course more fuzzy for applications that do not have formal > published specifications. From owner-ietf-pkix@mail.imc.org Tue May 24 13:59:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26479 for ; Tue, 24 May 2005 13:58:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OH3Epr024900; Tue, 24 May 2005 10:03:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OH3EoB024899; Tue, 24 May 2005 10:03:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OH36PG024877 for ; Tue, 24 May 2005 10:03:13 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 744A0352A9; Wed, 25 May 2005 05:03:05 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17304-21; Wed, 25 May 2005 05:03:05 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 5C3ED35272; Wed, 25 May 2005 05:03:05 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 25E873774B; Wed, 25 May 2005 05:03:05 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DacoF-0004nR-00; Wed, 25 May 2005 05:03:15 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, sroberts@certicom.com Subject: Re: Trying to relate PKCS & IETF standards to encoding rules In-Reply-To: <20050524161310.GA31429@certicom.com> Message-Id: Date: Wed, 25 May 2005 05:03:15 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Roberts writes: >Maybe an informational I-D would be useful to help bring some consistency to >the practice. Given the deployed base, I doubt it'd make much difference to existing implementations. What you could do though is document current practice to help others who're coming along and want to implement something that interoperates. Peter. From owner-ietf-pkix@mail.imc.org Tue May 24 14:35:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29370 for ; Tue, 24 May 2005 14:35:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OHpleL040117; Tue, 24 May 2005 10:51:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OHplEq040116; Tue, 24 May 2005 10:51:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OHpjDJ040110 for ; Tue, 24 May 2005 10:51:46 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id j4OHpep31682 for ; Tue, 24 May 2005 19:51:45 +0200 Message-ID: <429369AA.1030502@free.fr> Date: Tue, 24 May 2005 19:51:38 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050517 MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension References: <20050524163852.GA13889@cryptolog.com> In-Reply-To: <20050524163852.GA13889@cryptolog.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Julien Stern wrote: >Note that the CRL could be directly inserted into a "long term" >signature (according to RFC3126 for example). This does not require >a repository break-in and makes the "attack" even more realistic. > > Or in a CMS messages, together with the certificates that validate it. The problem is not restricted to the AIA. From owner-ietf-pkix@mail.imc.org Tue May 24 15:16:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03225 for ; Tue, 24 May 2005 15:16:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OIWQRa046883; Tue, 24 May 2005 11:32:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OIWQML046882; Tue, 24 May 2005 11:32:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4OIWQpQ046876 for ; Tue, 24 May 2005 11:32:26 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 1758 invoked by uid 0); 24 May 2005 18:32:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.156.225) by woodstock.binhost.com with SMTP; 24 May 2005 18:32:19 -0000 Message-Id: <6.2.1.2.2.20050524142144.068279f0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 24 May 2005 14:28:42 -0400 To: "Julien Stern" , Tom Gindin From: Russ Housley Subject: Re: WG Last Call: AIA CRL extension Cc: ietf-pkix@imc.org In-Reply-To: <20050524163852.GA13889@cryptolog.com> References: <20050524163852.GA13889@cryptolog.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Julien & Tom: Two points: 1. I understand this scenario. The change that you advocate as a countermeasure will prevent Indirect CRLs from working in scenarios that are intended. 2. This observation has noting to do with the CRL AIA extension. The attacker is inserting the bogus revocation information into the repository. Any relying party that uses that repository (when using the CRL AIA extension or any other configuration information to locate it) will get the bogus revocation information. If this is a concern, then it needs to be addressed in RFC3280bis, not here. Russ At 12:38 PM 5/24/2005, Julien Stern wrote: >On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > There is one scenario permitted by the "same trust anchor" rule > > for CRL signers which seems to me to be a serious security hole. Let us > > assume a valid CA which is a direct subordinate of one of the RP's trust > > anchors. This CA issues separate CRL's and ARL's, in a quite usual way, > > and issues cross certificates. After months or years of operation, it > > revokes one of its cross certificates because the subject's operator has > > gone rogue. That rogue subject then issues a fraudulent CRL Signing > > certificate with the DN that the superior certificate has been using to > > sign ARL's, a public key which it has newly generated, and various > > extensions including an SKID. It then issues an updated copy of an old > > ARL under the fraudulent CRL signer's certificate and with an AKID > > matching the fraudulent signer's SKID. If the rogue can break into the > > repository where the CRL is expected, this fraudulently issued CRL will > > probably be validated whether it contains an AIA or not. It will > > certainly pass the "same trust anchor" condition. > > This scenario, in which a rogue CA issues an ARL certifiying that > > its primary certificate has not been revoked and gets the ARL accepted, is > > possible under "same trust anchor" but not under "signed by path member". > >I agree with the validity of this scenario. I believe this is very >close to the issue I attempted to bring on the list a short time ago. >Of course, it assumes the existence of a rogue CA at some point in time. > >Note that the CRL could be directly inserted into a "long term" >signature (according to RFC3126 for example). This does not require >a repository break-in and makes the "attack" even more realistic. > >Regards. > >-- >Julien Stern > > > > > Tom Gindin > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > > > > > > Tom Gindin > > 05/23/2005 10:46 PM > > > > To: wpolk@nist.gov > > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, > > stefans@microsoft.com > > From: Tom Gindin/Watson/IBM@IBMUS > > Subject: Re: WG Last Call: AIA CRL extension > > > > Tim: > > > > I should probably have brought this up earlier, but are we certain > > that "same trust anchor" is a strong enough check that the CRL signer is > > the one expected by the issuing CA? While I was not in San Diego when > > this wording was included in the 3280 series, I do not really think that > > that check is strong enough. I would suggest instead that the CRL > > signer's certificate needs to be directly issued by one of the CA's in the > > certification path back to the trust anchor used for the certificate's > > verification, or by that anchor itself, unless people have practical > > experience with CA structures which that rule would prohibit. Forcing the > > CRL to be issued by the CA itself (as I understand Denis to have > > suggested) prohibits the reasonable case where the CRL is issued by a > > hierarchical superior, so it is IMHO too strict. > > I am personally not sure, FWIW, that a CRL should be permitted to > > be signed by a second-cousin certificate of the issuer's certificate. By > > analogy to the use of the terms in families, "sibling" certificates would > > have the same issuer, "first-cousin" certificates would be issued by > > siblings, and "second-cousin" certificates would be issued by first > > cousins - so they are both three levels down from the same trust anchor, > > or from the last common CA in their paths. This issue is not newly caused > > by CRL AIA, since the same issue can arise with CRL's containing only > > AKID. AIA only allows RP's to build a path (whether right or wrong) more > > quickly. > > In any case, nothing more than a note in Security Considerations > > is appropriate in any of our RFC's other than 3280 and its successor. > > > > Tom Gindin > > P.S. - The above views are mine, and not necessarily those of my employer > > > > > > > > > > > > Tim Polk > > Sent by: owner-ietf-pkix@mail.imc.org > > 05/10/2005 05:27 PM > > > > To: ietf-pkix@imc.org > > cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > This message initiates working group Last Call for the specification > > "Internet X.509 Public Key Infrastructure: Authority Information Access > > CRL > > Extension". While some issues raised in the working group are unresolved, > > > > the editors believe that rough consensus supports the current > > specification. > > > > The URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > Last Call will run for (at least) two weeks. That is, Last Call will not > > close before May 24. > > > > Thanks, > > > > Tim Polk > > > > > > From owner-ietf-pkix@mail.imc.org Tue May 24 15:16:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03373 for ; Tue, 24 May 2005 15:16:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OISQQn046572; Tue, 24 May 2005 11:28:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OISQ4S046571; Tue, 24 May 2005 11:28:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OISOQF046556 for ; Tue, 24 May 2005 11:28:25 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 19:28:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: AIA CRL extension Date: Tue, 24 May 2005 19:28:11 +0100 Message-ID: Thread-Topic: WG Last Call: AIA CRL extension Thread-Index: AcVghl4hQGnOpNmhQJqTj0yo+nDs+gABuyzA From: "Stefan Santesson" To: "Julien Stern" , "Tom Gindin" Cc: X-OriginalArrivalTime: 24 May 2005 18:28:19.0020 (UTC) FILETIME=[5BB5F0C0:01C5608E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OISPQF046566 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Tom and Julien, Since this is a repetition of the discussion we had before San Diego and I don't want to repeat it here. I'm not saying that this discussion is invalid; it is just directed towards the wrong draft. As Tom pointed out: > this fraudulently issued CRL will probably be validated whether it > contains an AIA or not. This indicates once again that this is not an issue caused by the use of AIA in CRLs but a generic CRL validation issue that belongs with RFC 3280bis and not with the CRL-AIA draft. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Julien Stern > Sent: den 24 maj 2005 09:39 > To: Tom Gindin > Cc: ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > There is one scenario permitted by the "same trust anchor" rule > > for CRL signers which seems to me to be a serious security hole. Let us > > assume a valid CA which is a direct subordinate of one of the RP's trust > > anchors. This CA issues separate CRL's and ARL's, in a quite usual way, > > and issues cross certificates. After months or years of operation, it > > revokes one of its cross certificates because the subject's operator has > > gone rogue. That rogue subject then issues a fraudulent CRL Signing > > certificate with the DN that the superior certificate has been using to > > sign ARL's, a public key which it has newly generated, and various > > extensions including an SKID. It then issues an updated copy of an old > > ARL under the fraudulent CRL signer's certificate and with an AKID > > matching the fraudulent signer's SKID. If the rogue can break into the > > repository where the CRL is expected, this fraudulently issued CRL will > > probably be validated whether it contains an AIA or not. It will > > certainly pass the "same trust anchor" condition. > > This scenario, in which a rogue CA issues an ARL certifiying > that > > its primary certificate has not been revoked and gets the ARL accepted, > is > > possible under "same trust anchor" but not under "signed by path > member". > > I agree with the validity of this scenario. I believe this is very > close to the issue I attempted to bring on the list a short time ago. > Of course, it assumes the existence of a rogue CA at some point in time. > > Note that the CRL could be directly inserted into a "long term" > signature (according to RFC3126 for example). This does not require > a repository break-in and makes the "attack" even more realistic. > > Regards. > > -- > Julien Stern > > > > > Tom Gindin > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > > > > > > Tom Gindin > > 05/23/2005 10:46 PM > > > > To: wpolk@nist.gov > > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, > > stefans@microsoft.com > > From: Tom Gindin/Watson/IBM@IBMUS > > Subject: Re: WG Last Call: AIA CRL extension > > > > Tim: > > > > I should probably have brought this up earlier, but are we > certain > > that "same trust anchor" is a strong enough check that the CRL signer is > > the one expected by the issuing CA? While I was not in San Diego when > > this wording was included in the 3280 series, I do not really think that > > that check is strong enough. I would suggest instead that the CRL > > signer's certificate needs to be directly issued by one of the CA's in > the > > certification path back to the trust anchor used for the certificate's > > verification, or by that anchor itself, unless people have practical > > experience with CA structures which that rule would prohibit. Forcing > the > > CRL to be issued by the CA itself (as I understand Denis to have > > suggested) prohibits the reasonable case where the CRL is issued by a > > hierarchical superior, so it is IMHO too strict. > > I am personally not sure, FWIW, that a CRL should be permitted > to > > be signed by a second-cousin certificate of the issuer's certificate. > By > > analogy to the use of the terms in families, "sibling" certificates > would > > have the same issuer, "first-cousin" certificates would be issued by > > siblings, and "second-cousin" certificates would be issued by first > > cousins - so they are both three levels down from the same trust anchor, > > or from the last common CA in their paths. This issue is not newly > caused > > by CRL AIA, since the same issue can arise with CRL's containing only > > AKID. AIA only allows RP's to build a path (whether right or wrong) > more > > quickly. > > In any case, nothing more than a note in Security Considerations > > is appropriate in any of our RFC's other than 3280 and its successor. > > > > Tom Gindin > > P.S. - The above views are mine, and not necessarily those of my > employer > > > > > > > > > > > > Tim Polk > > Sent by: owner-ietf-pkix@mail.imc.org > > 05/10/2005 05:27 PM > > > > To: ietf-pkix@imc.org > > cc: kent@bbn.com, stefans@microsoft.com, > housley@vigilsec.com > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > This message initiates working group Last Call for the specification > > "Internet X.509 Public Key Infrastructure: Authority Information Access > > CRL > > Extension". While some issues raised in the working group are > unresolved, > > > > the editors believe that rough consensus supports the current > > specification. > > > > The URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > Last Call will run for (at least) two weeks. That is, Last Call will not > > close before May 24. > > > > Thanks, > > > > Tim Polk > > > > > > From owner-ietf-pkix@mail.imc.org Tue May 24 16:40:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22803 for ; Tue, 24 May 2005 16:40:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OJmdQQ056041; Tue, 24 May 2005 12:48:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OJmd3H056040; Tue, 24 May 2005 12:48:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OJmc0k056032 for ; Tue, 24 May 2005 12:48:38 -0700 (PDT) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 3607262D06; Tue, 24 May 2005 21:48:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id DA292440ED; Tue, 24 May 2005 21:49:09 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19521-03; Tue, 24 May 2005 21:49:04 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id D647A440AF; Tue, 24 May 2005 21:49:04 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 24 May 2005 21:48:31 +0200 From: "Julien Stern" Date: Tue, 24 May 2005 21:48:31 +0200 To: Stefan Santesson Cc: Tom Gindin , ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension Message-ID: <20050524194827.GA13972@cryptolog.com> Mail-Followup-To: Julien Stern , Stefan Santesson , Tom Gindin , ietf-pkix@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego and > I don't want to repeat it here. I'm not saying that this discussion is > invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use of > AIA in CRLs but a generic CRL validation issue that belongs with RFC > 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite usual > way, > > > and issues cross certificates. After months or years of operation, > it > > > revokes one of its cross certificates because the subject's operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL Signing > > > certificate with the DN that the superior certificate has been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time ago. > > Of course, it assumes the existence of a rogue CA at some point in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have practical > > > experience with CA structures which that rule would prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued by > > > siblings, and "second-cousin" certificates would be issued by first > > > cousins - so they are both three levels down from the same trust > anchor, > > > or from the last common CA in their paths. This issue is not newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the specification > > > "Internet X.509 Public Key Infrastructure: Authority Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Tue May 24 19:33:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05762 for ; Tue, 24 May 2005 19:33:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OMgl0G093020; Tue, 24 May 2005 15:42:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OMgl5C093019; Tue, 24 May 2005 15:42:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OMgkDr093013 for ; Tue, 24 May 2005 15:42:47 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4OMga8e015975; Tue, 24 May 2005 18:42:36 -0400 From: "Santosh Chokhani" To: "'Tom Gindin'" , Cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Tue, 24 May 2005 18:42:31 -0400 Message-ID: <005601c560b1$e2034470$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050524194827.GA13972@cryptolog.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OMglDr093014 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 04:44:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19249 for ; Wed, 25 May 2005 04:44:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4P7jq9t061700; Wed, 25 May 2005 00:45:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4P7jqTk061699; Wed, 25 May 2005 00:45:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4P7jnO1061655 for ; Wed, 25 May 2005 00:45:50 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA38762; Wed, 25 May 2005 10:00:38 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052509452887:606 ; Wed, 25 May 2005 09:45:28 +0200 Message-ID: <42942D57.5010103@bull.net> Date: Wed, 25 May 2005 09:46:31 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension References: <20050524163852.GA13889@cryptolog.com> <6.2.1.2.2.20050524142144.068279f0@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/05/2005 09:45:28, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/05/2005 09:45:30, Serialize complete at 25/05/2005 09:45:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Russ, Two points: 1. The current text in the security considerations section contains text which suggest a solution to the problem but which is not. At least the two following sentences SHALL be deleted: " As means of reducing problems and security issues related to issuer name collisions, CA names SHOULD be formed in a way that reduce the likelihood of name collisions. Implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at the same trust anchor". 2. We strongly agree that 3280bis MUST address this issue and currently it does not do it correctly (otherwise we would not have this loooong discussion), ... that we can continue within the scope of 3280bis. Denis > Julien & Tom: > > Two points: > > 1. I understand this scenario. The change that you advocate as a > countermeasure will prevent Indirect CRLs from working in scenarios that > are intended. > > 2. This observation has noting to do with the CRL AIA extension. The > attacker is inserting the bogus revocation information into the > repository. Any relying party that uses that repository (when using the > CRL AIA extension or any other configuration information to locate it) > will get the bogus revocation information. > > If this is a concern, then it needs to be addressed in RFC3280bis, not > here. > > Russ > > At 12:38 PM 5/24/2005, Julien Stern wrote: > >> On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: >> > >> > There is one scenario permitted by the "same trust anchor" rule >> > for CRL signers which seems to me to be a serious security hole. >> Let us >> > assume a valid CA which is a direct subordinate of one of the RP's >> trust >> > anchors. This CA issues separate CRL's and ARL's, in a quite usual >> way, >> > and issues cross certificates. After months or years of operation, it >> > revokes one of its cross certificates because the subject's operator >> has >> > gone rogue. That rogue subject then issues a fraudulent CRL Signing >> > certificate with the DN that the superior certificate has been using to >> > sign ARL's, a public key which it has newly generated, and various >> > extensions including an SKID. It then issues an updated copy of an old >> > ARL under the fraudulent CRL signer's certificate and with an AKID >> > matching the fraudulent signer's SKID. If the rogue can break into the >> > repository where the CRL is expected, this fraudulently issued CRL will >> > probably be validated whether it contains an AIA or not. It will >> > certainly pass the "same trust anchor" condition. >> > This scenario, in which a rogue CA issues an ARL certifiying >> that >> > its primary certificate has not been revoked and gets the ARL >> accepted, is >> > possible under "same trust anchor" but not under "signed by path >> member". >> >> I agree with the validity of this scenario. I believe this is very >> close to the issue I attempted to bring on the list a short time ago. >> Of course, it assumes the existence of a rogue CA at some point in time. >> >> Note that the CRL could be directly inserted into a "long term" >> signature (according to RFC3126 for example). This does not require >> a repository break-in and makes the "attack" even more realistic. >> >> Regards. >> >> -- >> Julien Stern >> >> > >> > Tom Gindin >> > >> > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- >> > >> > >> > Tom Gindin >> > 05/23/2005 10:46 PM >> > >> > To: wpolk@nist.gov >> > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, >> > stefans@microsoft.com >> > From: Tom Gindin/Watson/IBM@IBMUS >> > Subject: Re: WG Last Call: AIA CRL extension >> > >> > Tim: >> > >> > I should probably have brought this up earlier, but are we >> certain >> > that "same trust anchor" is a strong enough check that the CRL >> signer is >> > the one expected by the issuing CA? While I was not in San Diego when >> > this wording was included in the 3280 series, I do not really think >> that >> > that check is strong enough. I would suggest instead that the CRL >> > signer's certificate needs to be directly issued by one of the CA's >> in the >> > certification path back to the trust anchor used for the certificate's >> > verification, or by that anchor itself, unless people have practical >> > experience with CA structures which that rule would prohibit. >> Forcing the >> > CRL to be issued by the CA itself (as I understand Denis to have >> > suggested) prohibits the reasonable case where the CRL is issued by a >> > hierarchical superior, so it is IMHO too strict. >> > I am personally not sure, FWIW, that a CRL should be >> permitted to >> > be signed by a second-cousin certificate of the issuer's >> certificate. By >> > analogy to the use of the terms in families, "sibling" certificates >> would >> > have the same issuer, "first-cousin" certificates would be issued by >> > siblings, and "second-cousin" certificates would be issued by first >> > cousins - so they are both three levels down from the same trust >> anchor, >> > or from the last common CA in their paths. This issue is not newly >> caused >> > by CRL AIA, since the same issue can arise with CRL's containing only >> > AKID. AIA only allows RP's to build a path (whether right or wrong) >> more >> > quickly. >> > In any case, nothing more than a note in Security >> Considerations >> > is appropriate in any of our RFC's other than 3280 and its successor. >> > >> > Tom Gindin >> > P.S. - The above views are mine, and not necessarily those of my >> employer >> > >> > >> > >> > >> > >> > Tim Polk >> > Sent by: owner-ietf-pkix@mail.imc.org >> > 05/10/2005 05:27 PM >> > >> > To: ietf-pkix@imc.org >> > cc: kent@bbn.com, stefans@microsoft.com, >> housley@vigilsec.com >> > Subject: WG Last Call: AIA CRL extension >> > >> > >> > >> > >> > This message initiates working group Last Call for the specification >> > "Internet X.509 Public Key Infrastructure: Authority Information Access >> > CRL >> > Extension". While some issues raised in the working group are >> unresolved, >> > >> > the editors believe that rough consensus supports the current >> > specification. >> > >> > The URL for this Internet-Draft is: >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt >> > >> > Last Call will run for (at least) two weeks. That is, Last Call will >> not >> > close before May 24. >> > >> > Thanks, >> > >> > Tim Polk >> > >> > >> > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 08:40:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06686 for ; Wed, 25 May 2005 08:40:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PBo2vI060031; Wed, 25 May 2005 04:50:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PBo2nI060030; Wed, 25 May 2005 04:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PBo0Oq059983 for ; Wed, 25 May 2005 04:50:00 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4PBnsT5023927 for ; Wed, 25 May 2005 07:49:54 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4PBns5Z157526 for ; Wed, 25 May 2005 07:49:54 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4PBnsPS002935 for ; Wed, 25 May 2005 07:49:54 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4PBnsxc002932; Wed, 25 May 2005 07:49:54 -0400 In-Reply-To: <005601c560b1$e2034470$aa02a8c0@hq.orionsec.com> To: "Santosh Chokhani" Cc: ietf-pkix@imc.org, "'Julien Stern'" MIME-Version: 1.0 Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Wed, 25 May 2005 07:49:50 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/25/2005 07:49:53, Serialize complete at 05/25/2005 07:49:53 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 09:58:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13114 for ; Wed, 25 May 2005 09:58:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PCx0tM000309; Wed, 25 May 2005 05:59:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PCx04v000307; Wed, 25 May 2005 05:59:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PCwxdX000294 for ; Wed, 25 May 2005 05:58:59 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4PCww8e005156 for ; Wed, 25 May 2005 08:58:59 -0400 From: "Santosh Chokhani" To: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Wed, 25 May 2005 08:58:52 -0400 Message-ID: <000401c56129$83eb3370$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PCx0dX000301 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Tom, It is not clear from your example who the indirect CRL issuer is and what role the "indirect CRL" plays in the attack. If S is the indirect CRL issuer, C should be smart enough to not create circularity (a good toolkit will not verify path when C issues a certificate to S and points to S as the indirect CRL issuer since it causes circularity and chicken and egg problem). That scenario can be easily rectified within current standard by C not declaring S as the indirect CRL issuer for certificate issued to S. C can declare itself in the CDP or some other issuer. I suspect you do not mean this. Your example may be simpler. To me the attack is still not plausible. Your scenario is not detailed enough to illustrate an attack. It does not seem that there is a way to validate the certificate issued to C by S without looking at CRL issued by C, resulting in circularity, which relying party clients should not accept. (Note that my November presentation to IETF in DC covered the circularity issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to the CRL certification path) -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, May 25, 2005 7:50 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; 'Julien Stern' Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 10:45:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17998 for ; Wed, 25 May 2005 10:45:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PDnWc6014890; Wed, 25 May 2005 06:49:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PDnWgR014889; Wed, 25 May 2005 06:49:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PDnUEw014875 for ; Wed, 25 May 2005 06:49:31 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 May 2005 14:49:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: AIA CRL extension Date: Wed, 25 May 2005 14:49:10 +0100 Message-ID: Thread-Topic: WG Last Call: AIA CRL extension Thread-Index: AcVhBrzVcfnlDPymT/ae2CZ3lJTg4AAKSlig From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: X-OriginalArrivalTime: 25 May 2005 13:49:25.0237 (UTC) FILETIME=[90030A50:01C56130] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PDnVEw014883 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, I discussed this with Russ and our conclusion is that if this resolves your last call issues, then we can live with deleting these sentences. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 25 maj 2005 00:47 > To: Russ Housley > Cc: ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > Russ, > > Two points: > > 1. The current text in the security considerations section contains > text which suggest a solution to the problem but which is not. > At least the two following sentences SHALL be deleted: > > " As means of reducing problems and security issues related to issuer > name collisions, CA names SHOULD be formed in a way that reduce the > likelihood of name collisions. Implementations validating CRLs > MUST ensure that the certification path of the target certificate > and the CRL issuer certification path used to validate the target > certificate, terminate at the same trust anchor". > > 2. We strongly agree that 3280bis MUST address this issue and currently > it does not do it correctly (otherwise we would not have this > loooong discussion), ... that we can continue within the scope > of 3280bis. > > Denis > > > Julien & Tom: > > > > Two points: > > > > 1. I understand this scenario. The change that you advocate as a > > countermeasure will prevent Indirect CRLs from working in scenarios that > > are intended. > > > > 2. This observation has noting to do with the CRL AIA extension. The > > attacker is inserting the bogus revocation information into the > > repository. Any relying party that uses that repository (when using the > > CRL AIA extension or any other configuration information to locate it) > > will get the bogus revocation information. > > > > If this is a concern, then it needs to be addressed in RFC3280bis, not > > here. > > > > Russ > > > > At 12:38 PM 5/24/2005, Julien Stern wrote: > > > >> On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > >> > > >> > There is one scenario permitted by the "same trust anchor" > rule > >> > for CRL signers which seems to me to be a serious security hole. > >> Let us > >> > assume a valid CA which is a direct subordinate of one of the RP's > >> trust > >> > anchors. This CA issues separate CRL's and ARL's, in a quite usual > >> way, > >> > and issues cross certificates. After months or years of operation, > it > >> > revokes one of its cross certificates because the subject's operator > >> has > >> > gone rogue. That rogue subject then issues a fraudulent CRL Signing > >> > certificate with the DN that the superior certificate has been using > to > >> > sign ARL's, a public key which it has newly generated, and various > >> > extensions including an SKID. It then issues an updated copy of an > old > >> > ARL under the fraudulent CRL signer's certificate and with an AKID > >> > matching the fraudulent signer's SKID. If the rogue can break into > the > >> > repository where the CRL is expected, this fraudulently issued CRL > will > >> > probably be validated whether it contains an AIA or not. It will > >> > certainly pass the "same trust anchor" condition. > >> > This scenario, in which a rogue CA issues an ARL certifiying > >> that > >> > its primary certificate has not been revoked and gets the ARL > >> accepted, is > >> > possible under "same trust anchor" but not under "signed by path > >> member". > >> > >> I agree with the validity of this scenario. I believe this is very > >> close to the issue I attempted to bring on the list a short time ago. > >> Of course, it assumes the existence of a rogue CA at some point in > time. > >> > >> Note that the CRL could be directly inserted into a "long term" > >> signature (according to RFC3126 for example). This does not require > >> a repository break-in and makes the "attack" even more realistic. > >> > >> Regards. > >> > >> -- > >> Julien Stern > >> > >> > > >> > Tom Gindin > >> > > >> > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > >> > > >> > > >> > Tom Gindin > >> > 05/23/2005 10:46 PM > >> > > >> > To: wpolk@nist.gov > >> > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > >> > stefans@microsoft.com > >> > From: Tom Gindin/Watson/IBM@IBMUS > >> > Subject: Re: WG Last Call: AIA CRL extension > >> > > >> > Tim: > >> > > >> > I should probably have brought this up earlier, but are we > >> certain > >> > that "same trust anchor" is a strong enough check that the CRL > >> signer is > >> > the one expected by the issuing CA? While I was not in San Diego > when > >> > this wording was included in the 3280 series, I do not really think > >> that > >> > that check is strong enough. I would suggest instead that the CRL > >> > signer's certificate needs to be directly issued by one of the CA's > >> in the > >> > certification path back to the trust anchor used for the > certificate's > >> > verification, or by that anchor itself, unless people have practical > >> > experience with CA structures which that rule would prohibit. > >> Forcing the > >> > CRL to be issued by the CA itself (as I understand Denis to have > >> > suggested) prohibits the reasonable case where the CRL is issued by a > >> > hierarchical superior, so it is IMHO too strict. > >> > I am personally not sure, FWIW, that a CRL should be > >> permitted to > >> > be signed by a second-cousin certificate of the issuer's > >> certificate. By > >> > analogy to the use of the terms in families, "sibling" certificates > >> would > >> > have the same issuer, "first-cousin" certificates would be issued by > >> > siblings, and "second-cousin" certificates would be issued by first > >> > cousins - so they are both three levels down from the same trust > >> anchor, > >> > or from the last common CA in their paths. This issue is not newly > >> caused > >> > by CRL AIA, since the same issue can arise with CRL's containing only > >> > AKID. AIA only allows RP's to build a path (whether right or wrong) > >> more > >> > quickly. > >> > In any case, nothing more than a note in Security > >> Considerations > >> > is appropriate in any of our RFC's other than 3280 and its successor. > >> > > >> > Tom Gindin > >> > P.S. - The above views are mine, and not necessarily those of my > >> employer > >> > > >> > > >> > > >> > > >> > > >> > Tim Polk > >> > Sent by: owner-ietf-pkix@mail.imc.org > >> > 05/10/2005 05:27 PM > >> > > >> > To: ietf-pkix@imc.org > >> > cc: kent@bbn.com, stefans@microsoft.com, > >> housley@vigilsec.com > >> > Subject: WG Last Call: AIA CRL extension > >> > > >> > > >> > > >> > > >> > This message initiates working group Last Call for the specification > >> > "Internet X.509 Public Key Infrastructure: Authority Information > Access > >> > CRL > >> > Extension". While some issues raised in the working group are > >> unresolved, > >> > > >> > the editors believe that rough consensus supports the current > >> > specification. > >> > > >> > The URL for this Internet-Draft is: > >> > > >> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > >> > > >> > Last Call will run for (at least) two weeks. That is, Last Call will > >> not > >> > close before May 24. > >> > > >> > Thanks, > >> > > >> > Tim Polk > >> > > >> > > >> > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 11:39:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22304 for ; Wed, 25 May 2005 11:39:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PEZxSa022338; Wed, 25 May 2005 07:35:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PEZxwt022337; Wed, 25 May 2005 07:35:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PEZvuB022317 for ; Wed, 25 May 2005 07:35:58 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA56426; Wed, 25 May 2005 16:50:41 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052516352850:1008 ; Wed, 25 May 2005 16:35:28 +0200 Message-ID: <42948D66.7090300@bull.net> Date: Wed, 25 May 2005 16:36:22 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson , Russ Housley CC: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/05/2005 16:35:28, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/05/2005 16:35:33, Serialize complete at 25/05/2005 16:35:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan and Russ, > Denis, > I discussed this with Russ and our conclusion is that if this resolves > your last call issues, then we can live with deleting these sentences. If so, my concern is solved. Thanks, Denis PS: Stefan, we do not need to meet anymore next week on this topic, and we can spend more time to enjoy some good food on the French Riviera. :-) > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 25 maj 2005 00:47 >>To: Russ Housley >>Cc: ietf-pkix@imc.org >>Subject: Re: WG Last Call: AIA CRL extension >> >> >>Russ, >> >>Two points: >> >>1. The current text in the security considerations section contains >> text which suggest a solution to the problem but which is not. >> At least the two following sentences SHALL be deleted: >> >> " As means of reducing problems and security issues related to > > issuer > >> name collisions, CA names SHOULD be formed in a way that reduce > > the > >> likelihood of name collisions. Implementations validating CRLs >> MUST ensure that the certification path of the target certificate >> and the CRL issuer certification path used to validate the target >> certificate, terminate at the same trust anchor". >> >>2. We strongly agree that 3280bis MUST address this issue and > > currently > >> it does not do it correctly (otherwise we would not have this >> loooong discussion), ... that we can continue within the scope >> of 3280bis. >> >>Denis >> >> >>>Julien & Tom: >>> >>>Two points: >>> >>>1. I understand this scenario. The change that you advocate as a >>>countermeasure will prevent Indirect CRLs from working in scenarios >> > that > >>>are intended. >>> >>>2. This observation has noting to do with the CRL AIA extension. >> > The > >>>attacker is inserting the bogus revocation information into the >>>repository. Any relying party that uses that repository (when using >> > the > >>>CRL AIA extension or any other configuration information to locate >> > it) > >>>will get the bogus revocation information. >>> >>>If this is a concern, then it needs to be addressed in RFC3280bis, >> > not > >>>here. >>> >>>Russ >>> >>>At 12:38 PM 5/24/2005, Julien Stern wrote: >>> >>> >>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: >>>> >>>>> There is one scenario permitted by the "same trust >>>> > anchor" > >>rule >> >>>>>for CRL signers which seems to me to be a serious security hole. >>>> >>>>Let us >>>> >>>>>assume a valid CA which is a direct subordinate of one of the >>>> > RP's > >>>>trust >>>> >>>>>anchors. This CA issues separate CRL's and ARL's, in a quite >>>> > usual > >>>>way, >>>> >>>>>and issues cross certificates. After months or years of >>>> > operation, > >>it >> >>>>>revokes one of its cross certificates because the subject's >>>> > operator > >>>>has >>>> >>>>>gone rogue. That rogue subject then issues a fraudulent CRL >>>> > Signing > >>>>>certificate with the DN that the superior certificate has been >>>> > using > >>to >> >>>>>sign ARL's, a public key which it has newly generated, and >>>> > various > >>>>>extensions including an SKID. It then issues an updated copy of >>>> > an > >>old >> >>>>>ARL under the fraudulent CRL signer's certificate and with an >>>> > AKID > >>>>>matching the fraudulent signer's SKID. If the rogue can break >>>> > into > >>the >> >>>>>repository where the CRL is expected, this fraudulently issued >>>> > CRL > >>will >> >>>>>probably be validated whether it contains an AIA or not. It will >>>>>certainly pass the "same trust anchor" condition. >>>>> This scenario, in which a rogue CA issues an ARL >>>> > certifiying > >>>>that >>>> >>>>>its primary certificate has not been revoked and gets the ARL >>>> >>>>accepted, is >>>> >>>>>possible under "same trust anchor" but not under "signed by path >>>> >>>>member". >>>> >>>>I agree with the validity of this scenario. I believe this is very >>>>close to the issue I attempted to bring on the list a short time >>> > ago. > >>>>Of course, it assumes the existence of a rogue CA at some point in >>> >>time. >> >>>>Note that the CRL could be directly inserted into a "long term" >>>>signature (according to RFC3126 for example). This does not require >>>>a repository break-in and makes the "attack" even more realistic. >>>> >>>>Regards. >>>> >>>>-- >>>>Julien Stern >>>> >>>> >>>>> Tom Gindin >>>>> >>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM >>>> > ----- > >>>>> >>>>>Tom Gindin >>>>>05/23/2005 10:46 PM >>>>> >>>>> To: wpolk@nist.gov >>>>> cc: housley@vigilsec.com, ietf-pkix@imc.org, >>>> >>kent@bbn.com, >> >>>>>stefans@microsoft.com >>>>> From: Tom Gindin/Watson/IBM@IBMUS >>>>> Subject: Re: WG Last Call: AIA CRL extension >>>>> >>>>> Tim: >>>>> >>>>> I should probably have brought this up earlier, but are >>>> > we > >>>>certain >>>> >>>>>that "same trust anchor" is a strong enough check that the CRL >>>> >>>>signer is >>>> >>>>>the one expected by the issuing CA? While I was not in San Diego >>>> >>when >> >>>>>this wording was included in the 3280 series, I do not really >>>> > think > >>>>that >>>> >>>>>that check is strong enough. I would suggest instead that the >>>> > CRL > >>>>>signer's certificate needs to be directly issued by one of the >>>> > CA's > >>>>in the >>>> >>>>>certification path back to the trust anchor used for the >>>> >>certificate's >> >>>>>verification, or by that anchor itself, unless people have >>>> > practical > >>>>>experience with CA structures which that rule would prohibit. >>>> >>>>Forcing the >>>> >>>>>CRL to be issued by the CA itself (as I understand Denis to have >>>>>suggested) prohibits the reasonable case where the CRL is issued >>>> > by a > >>>>>hierarchical superior, so it is IMHO too strict. >>>>> I am personally not sure, FWIW, that a CRL should be >>>> >>>>permitted to >>>> >>>>>be signed by a second-cousin certificate of the issuer's >>>> >>>>certificate. By >>>> >>>>>analogy to the use of the terms in families, "sibling" >>>> > certificates > >>>>would >>>> >>>>>have the same issuer, "first-cousin" certificates would be issued >>>> > by > >>>>>siblings, and "second-cousin" certificates would be issued by >>>> > first > >>>>>cousins - so they are both three levels down from the same trust >>>> >>>>anchor, >>>> >>>>>or from the last common CA in their paths. This issue is not >>>> > newly > >>>>caused >>>> >>>>>by CRL AIA, since the same issue can arise with CRL's containing >>>> > only > >>>>>AKID. AIA only allows RP's to build a path (whether right or >>>> > wrong) > >>>>more >>>> >>>>>quickly. >>>>> In any case, nothing more than a note in Security >>>> >>>>Considerations >>>> >>>>>is appropriate in any of our RFC's other than 3280 and its >>>> > successor. > >>>>> Tom Gindin >>>>>P.S. - The above views are mine, and not necessarily those of my >>>> >>>>employer >>>> >>>>> >>>>> >>>>> >>>>> >>>>>Tim Polk >>>>>Sent by: owner-ietf-pkix@mail.imc.org >>>>>05/10/2005 05:27 PM >>>>> >>>>> To: ietf-pkix@imc.org >>>>> cc: kent@bbn.com, stefans@microsoft.com, >>>> >>>>housley@vigilsec.com >>>> >>>>> Subject: WG Last Call: AIA CRL extension >>>>> >>>>> >>>>> >>>>> >>>>>This message initiates working group Last Call for the >>>> > specification > >>>>>"Internet X.509 Public Key Infrastructure: Authority Information >>>> >>Access >> >>>>>CRL >>>>>Extension". While some issues raised in the working group are >>>> >>>>unresolved, >>>> >>>>>the editors believe that rough consensus supports the current >>>>>specification. >>>>> >>>>>The URL for this Internet-Draft is: >>>>> >>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt >>>>> >>>>>Last Call will run for (at least) two weeks. That is, Last Call >>>> > will > >>>>not >>>> >>>>>close before May 24. >>>>> >>>>>Thanks, >>>>> >>>>>Tim Polk >>>>> >>>>> >>>>> >>>> >>> >>> >>> > > From owner-ietf-pkix@mail.imc.org Wed May 25 15:00:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09133 for ; Wed, 25 May 2005 15:00:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PII1t3077633; Wed, 25 May 2005 11:18:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PII1s8077632; Wed, 25 May 2005 11:18:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PIHxDS077624 for ; Wed, 25 May 2005 11:18:00 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 May 2005 19:17:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Wed, 25 May 2005 19:17:51 +0100 Message-ID: Thread-Topic: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Thread-Index: AcVhJ7hMyO7FTj+VSwauDRaoZ34EWQALZJgQ From: "Stefan Santesson" To: "Tom Gindin" , "Santosh Chokhani" Cc: , "Julien Stern" X-OriginalArrivalTime: 25 May 2005 18:17:54.0270 (UTC) FILETIME=[11BE67E0:01C56156] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PII0DS077627 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, > cc: "'Julien Stern'" > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, > but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion > would have to take place at some point regarding the overall security > model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 15:12:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10772 for ; Wed, 25 May 2005 15:12:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PIMpMA077900; Wed, 25 May 2005 11:22:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PIMpcX077899; Wed, 25 May 2005 11:22:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PIMofZ077893 for ; Wed, 25 May 2005 11:22:50 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4PIMn8e027842 for ; Wed, 25 May 2005 14:22:49 -0400 From: "Santosh Chokhani" To: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Wed, 25 May 2005 14:22:44 -0400 Message-ID: <002f01c56156$c1f50830$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PIMpfZ077894 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Stephan, Validation related text (e.g., infinite loops) belongs more in 3280. Having it in the new I-D does not harm. But, validation should be addressed by 3280 and not diced up in multiple RFC and then served. -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Wednesday, May 25, 2005 2:18 PM To: Tom Gindin; Santosh Chokhani Cc: ietf-pkix@imc.org; Julien Stern Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, > cc: "'Julien Stern'" > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion would have to take place at some point regarding the > overall security model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 16:17:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23924 for ; Wed, 25 May 2005 16:17:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJeDBl089544; Wed, 25 May 2005 12:40:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PJeDUJ089543; Wed, 25 May 2005 12:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJeBRl089537 for ; Wed, 25 May 2005 12:40:12 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4PJdjjo027420; Wed, 25 May 2005 15:40:00 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4PJcZ6v008597; Wed, 25 May 2005 15:38:36 -0400 (EDT) Message-Id: <5.1.0.14.2.20050525152918.03815c60@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 25 May 2005 15:40:18 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: Re: WG Last Call: AIA CRL extension Cc: Denis Pinkas , Stefan Santesson , Russ Housley In-Reply-To: <42948D66.7090300@bull.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, My reading of this thread says that rough consensus has been achieved on the AIA CRL extension ID, and that I can forward the document to the appropriate Area Director after deletion of these sentences. (If anyone disagrees, please say so on list ASAP!) As noted, this issue will have to be addressed in the context of 3280bis. It is clear that the current content of 3280bis with respect to CRL validation does not enjoy consensus within the working group. Thanks, Tim Polk At 04:36 PM 5/25/2005 +0200, Denis Pinkas wrote: >Stefan and Russ, > >>Denis, > >>I discussed this with Russ and our conclusion is that if this resolves >>your last call issues, then we can live with deleting these sentences. > >If so, my concern is solved. > >Thanks, > >Denis > >PS: Stefan, we do not need to meet anymore next week on this topic, > and we can spend more time to enjoy some good food on the > French Riviera. :-) > >>Stefan Santesson >>Program Manager, Standards Liaison >>Windows Security >> >> >>>-----Original Message----- >>>From: owner-ietf-pkix@mail.imc.org >>[mailto:owner-ietf-pkix@mail.imc.org] >> >>>On Behalf Of Denis Pinkas >>>Sent: den 25 maj 2005 00:47 >>>To: Russ Housley >>>Cc: ietf-pkix@imc.org >>>Subject: Re: WG Last Call: AIA CRL extension >>> >>> >>>Russ, >>> >>>Two points: >>> >>>1. The current text in the security considerations section contains >>> text which suggest a solution to the problem but which is not. >>> At least the two following sentences SHALL be deleted: >>> >>> " As means of reducing problems and security issues related to >>issuer >> >>> name collisions, CA names SHOULD be formed in a way that reduce >>the >> >>> likelihood of name collisions. Implementations validating CRLs >>> MUST ensure that the certification path of the target certificate >>> and the CRL issuer certification path used to validate the target >>> certificate, terminate at the same trust anchor". >>> >>>2. We strongly agree that 3280bis MUST address this issue and >>currently >> >>> it does not do it correctly (otherwise we would not have this >>> loooong discussion), ... that we can continue within the scope >>> of 3280bis. >>> >>>Denis >>> >>> >>>>Julien & Tom: >>>> >>>>Two points: >>>> >>>>1. I understand this scenario. The change that you advocate as a >>>>countermeasure will prevent Indirect CRLs from working in scenarios >>that >> >>>>are intended. >>>> >>>>2. This observation has noting to do with the CRL AIA extension. >>The >> >>>>attacker is inserting the bogus revocation information into the >>>>repository. Any relying party that uses that repository (when using >>the >> >>>>CRL AIA extension or any other configuration information to locate >>it) >> >>>>will get the bogus revocation information. >>>> >>>>If this is a concern, then it needs to be addressed in RFC3280bis, >>not >> >>>>here. >>>> >>>>Russ >>>> >>>>At 12:38 PM 5/24/2005, Julien Stern wrote: >>>> >>>> >>>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: >>>>> >>>>>> There is one scenario permitted by the "same trust >>anchor" >> >>>rule >>> >>>>>>for CRL signers which seems to me to be a serious security hole. >>>>> >>>>>Let us >>>>> >>>>>>assume a valid CA which is a direct subordinate of one of the >>RP's >> >>>>>trust >>>>> >>>>>>anchors. This CA issues separate CRL's and ARL's, in a quite >>usual >> >>>>>way, >>>>> >>>>>>and issues cross certificates. After months or years of >>operation, >> >>>it >>> >>>>>>revokes one of its cross certificates because the subject's >>operator >> >>>>>has >>>>> >>>>>>gone rogue. That rogue subject then issues a fraudulent CRL >>Signing >> >>>>>>certificate with the DN that the superior certificate has been >>using >> >>>to >>> >>>>>>sign ARL's, a public key which it has newly generated, and >>various >> >>>>>>extensions including an SKID. It then issues an updated copy of >>an >> >>>old >>> >>>>>>ARL under the fraudulent CRL signer's certificate and with an >>AKID >> >>>>>>matching the fraudulent signer's SKID. If the rogue can break >>into >> >>>the >>> >>>>>>repository where the CRL is expected, this fraudulently issued >>CRL >> >>>will >>> >>>>>>probably be validated whether it contains an AIA or not. It will >>>>>>certainly pass the "same trust anchor" condition. >>>>>> This scenario, in which a rogue CA issues an ARL >>certifiying >> >>>>>that >>>>> >>>>>>its primary certificate has not been revoked and gets the ARL >>>>> >>>>>accepted, is >>>>> >>>>>>possible under "same trust anchor" but not under "signed by path >>>>> >>>>>member". >>>>> >>>>>I agree with the validity of this scenario. I believe this is very >>>>>close to the issue I attempted to bring on the list a short time >>ago. >> >>>>>Of course, it assumes the existence of a rogue CA at some point in >>>time. >>> >>>>>Note that the CRL could be directly inserted into a "long term" >>>>>signature (according to RFC3126 for example). This does not require >>>>>a repository break-in and makes the "attack" even more realistic. >>>>> >>>>>Regards. >>>>> >>>>>-- >>>>>Julien Stern >>>>> >>>>> >>>>>> Tom Gindin >>>>>> >>>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM >>----- >> >>>>>> >>>>>>Tom Gindin >>>>>>05/23/2005 10:46 PM >>>>>> >>>>>> To: wpolk@nist.gov >>>>>> cc: housley@vigilsec.com, ietf-pkix@imc.org, >>>kent@bbn.com, >>> >>>>>>stefans@microsoft.com >>>>>> From: Tom Gindin/Watson/IBM@IBMUS >>>>>> Subject: Re: WG Last Call: AIA CRL extension >>>>>> >>>>>> Tim: >>>>>> >>>>>> I should probably have brought this up earlier, but are >>we >> >>>>>certain >>>>> >>>>>>that "same trust anchor" is a strong enough check that the CRL >>>>> >>>>>signer is >>>>> >>>>>>the one expected by the issuing CA? While I was not in San Diego >>>when >>> >>>>>>this wording was included in the 3280 series, I do not really >>think >> >>>>>that >>>>> >>>>>>that check is strong enough. I would suggest instead that the >>CRL >> >>>>>>signer's certificate needs to be directly issued by one of the >>CA's >> >>>>>in the >>>>> >>>>>>certification path back to the trust anchor used for the >>>certificate's >>> >>>>>>verification, or by that anchor itself, unless people have >>practical >> >>>>>>experience with CA structures which that rule would prohibit. >>>>> >>>>>Forcing the >>>>> >>>>>>CRL to be issued by the CA itself (as I understand Denis to have >>>>>>suggested) prohibits the reasonable case where the CRL is issued >>by a >> >>>>>>hierarchical superior, so it is IMHO too strict. >>>>>> I am personally not sure, FWIW, that a CRL should be >>>>> >>>>>permitted to >>>>> >>>>>>be signed by a second-cousin certificate of the issuer's >>>>> >>>>>certificate. By >>>>> >>>>>>analogy to the use of the terms in families, "sibling" >>certificates >> >>>>>would >>>>> >>>>>>have the same issuer, "first-cousin" certificates would be issued >>by >> >>>>>>siblings, and "second-cousin" certificates would be issued by >>first >> >>>>>>cousins - so they are both three levels down from the same trust >>>>> >>>>>anchor, >>>>> >>>>>>or from the last common CA in their paths. This issue is not >>newly >> >>>>>caused >>>>> >>>>>>by CRL AIA, since the same issue can arise with CRL's containing >>only >> >>>>>>AKID. AIA only allows RP's to build a path (whether right or >>wrong) >> >>>>>more >>>>> >>>>>>quickly. >>>>>> In any case, nothing more than a note in Security >>>>> >>>>>Considerations >>>>> >>>>>>is appropriate in any of our RFC's other than 3280 and its >>successor. >> >>>>>> Tom Gindin >>>>>>P.S. - The above views are mine, and not necessarily those of my >>>>> >>>>>employer >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>Tim Polk >>>>>>Sent by: owner-ietf-pkix@mail.imc.org >>>>>>05/10/2005 05:27 PM >>>>>> >>>>>> To: ietf-pkix@imc.org >>>>>> cc: kent@bbn.com, stefans@microsoft.com, >>>>> >>>>>housley@vigilsec.com >>>>> >>>>>> Subject: WG Last Call: AIA CRL extension >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>This message initiates working group Last Call for the >>specification >> >>>>>>"Internet X.509 Public Key Infrastructure: Authority Information >>>Access >>> >>>>>>CRL >>>>>>Extension". While some issues raised in the working group are >>>>> >>>>>unresolved, >>>>> >>>>>>the editors believe that rough consensus supports the current >>>>>>specification. >>>>>> >>>>>>The URL for this Internet-Draft is: >>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt >>>>>> >>>>>>Last Call will run for (at least) two weeks. That is, Last Call >>will >> >>>>>not >>>>> >>>>>>close before May 24. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Tim Polk >>>>>> >>>>>> >>>> >>>> > > From owner-ietf-pkix@mail.imc.org Wed May 25 16:31:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26964 for ; Wed, 25 May 2005 16:31:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJZ0pk089335; Wed, 25 May 2005 12:35:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PJZ0hg089334; Wed, 25 May 2005 12:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJYwwc089303 for ; Wed, 25 May 2005 12:34:59 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 May 2005 20:34:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Wed, 25 May 2005 20:34:51 +0100 Message-ID: Thread-Topic: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Thread-Index: AcVhXm8ooUxoytr5QSaYmzrpXI8E5AAAkefw From: "Stefan Santesson" To: "Santosh Chokhani" , X-OriginalArrivalTime: 25 May 2005 19:34:53.0134 (UTC) FILETIME=[D2CD1EE0:01C56160] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PJYxwc089323 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Santosh, Agree, I was talking about 3280bis. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Santosh Chokhani > Sent: den 25 maj 2005 11:23 > To: ietf-pkix@imc.org > Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Stephan, > > Validation related text (e.g., infinite loops) belongs more in 3280. > Having > it in the new I-D does not harm. But, validation should be addressed by > 3280 and not diced up in multiple RFC and then served. > > -----Original Message----- > From: Stefan Santesson [mailto:stefans@microsoft.com] > Sent: Wednesday, May 25, 2005 2:18 PM > To: Tom Gindin; Santosh Chokhani > Cc: ietf-pkix@imc.org; Julien Stern > Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Tom, > > If the substitution would be successful the validation would go into an > infinite loop and fail. Validation of S's fake CRL requires validation of > C's cross certificate to S which triggers another validation of S's fake > CRL > and so on. > > I think we added some text against infinite loops but I don't have it > fresh > in my memory. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Tom Gindin > > Sent: den 25 maj 2005 04:50 > > To: Santosh Chokhani > > Cc: ietf-pkix@imc.org; 'Julien Stern' > > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > > > > Santosh: > > > > A relatively concrete example would be the following: > > Assume a trust anchor called A, and CA it has issued a cross > > certificate to called C. Further assume that C uses indirect CRL's, > and > > has issued a cross certificate without name constraints to another CA > > called S. Then assume that S goes rogue and creates a CRL signing > > certificate with the same name as C uses for its indirect CRL's (the > key > > pair in that certificate is hereinafter called the "rogue CRL > signer"). > > Further assume that C finds out about this and creates a CRL listing S > as > > revoked, but that S successfully replaces that CRL in the repository > by > > one signed by the rogue CRL signer. > > Does RFC 3280 path validation consider S invalid? If so, > which > > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what > else > > would be likely to cause S to be recognized as invalid? You could > > probably patch any difficulties by adding "if the certificate whose > > revocation is being checked appears in the path, reject it" to > 6.3.3-f. > > > > Tom Gindin > > > > > > > > > > > > > > "Santosh Chokhani" > > 05/24/2005 06:42 PM > > > > To: Tom Gindin/Watson/IBM@IBMUS, > > cc: "'Julien Stern'" > > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > > extension) > > > > > > Tom, > > > > > > I assume you are talking about CRL certification path solution I > proposed > > will not permit the scenario? I still do not see in your case, if the > > Subject CA (cross certified CA) is revoked, you will verify the path > to it > > in the first place. May be I am not understanding your scenario > properly. > > How does the revoked CA gets verified? > > > > > > Julien, > > > > We have defined and proven the solution for how to do this. The > scenario > > you proposed is not something X.509 worries about (A CA that is still > > valid, but has gone bad). > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On > > Behalf Of Julien Stern > > Sent: Tuesday, May 24, 2005 3:49 PM > > To: Stefan Santesson > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > > Tom and Julien, > > > > > > Since this is a repetition of the discussion we had before San Diego > > > and I don't want to repeat it here. I'm not saying that this > > > discussion is invalid; it is just directed towards the wrong draft. > > > > Stefan, > > > > I agree with you. Actually, I would tend to believe that a _real_ > > discussion would have to take place at some point regarding the > > overall security model > > of CRL validation, but I have absolutely no objection to the AIA, as > soon > > as > > it is made clear that it's only goal is to simplify path building > > implementations, and not to adress security issues. My very humble > take on > > the subject is that Denis and yourself have been arguing on the list > on > > absolutely valid but different matters. > > > > So, I chose not to comment expect for my last mail (and will not any > more) > > about AIA, but I still think that a discusssion regarding revocation > > validation should take place for RFC3280bis, eventually. > > > > Regards, > > > > -- > > Julien Stern > > > > > > > > As Tom pointed out: > > > > this fraudulently issued CRL will probably be validated whether it > > > > contains an AIA or not. > > > > > > This indicates once again that this is not an issue caused by the > use > > > of AIA in CRLs but a generic CRL validation issue that belongs with > > > RFC 3280bis and not with the CRL-AIA draft. > > > > > > Stefan Santesson > > > Program Manager, Standards Liaison > > > Windows Security > > > > > > > > > > -----Original Message----- > > > > From: owner-ietf-pkix@mail.imc.org > > > [mailto:owner-ietf-pkix@mail.imc.org] > > > > On Behalf Of Julien Stern > > > > Sent: den 24 maj 2005 09:39 > > > > To: Tom Gindin > > > > Cc: ietf-pkix@imc.org > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > > > There is one scenario permitted by the "same trust > anchor" > > > rule > > > > > for CRL signers which seems to me to be a serious security hole. > > > Let us > > > > > assume a valid CA which is a direct subordinate of one of the > RP's > > > trust > > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > > usual > > > way, > > > > > and issues cross certificates. After months or years of > > > > > operation, > > > it > > > > > revokes one of its cross certificates because the subject's > > > > > operator > > > has > > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > > Signing certificate with the DN that the superior certificate > has > > > > > been using > > > to > > > > > sign ARL's, a public key which it has newly generated, and > various > > > > > extensions including an SKID. It then issues an updated copy of > > > > > an > > > old > > > > > ARL under the fraudulent CRL signer's certificate and with an > AKID > > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > > into > > > the > > > > > repository where the CRL is expected, this fraudulently issued > CRL > > > will > > > > > probably be validated whether it contains an AIA or not. It > will > > > > > certainly pass the "same trust anchor" condition. > > > > > This scenario, in which a rogue CA issues an ARL > > > > > certifiying > > > > that > > > > > its primary certificate has not been revoked and gets the ARL > > > accepted, > > > > is > > > > > possible under "same trust anchor" but not under "signed by path > > > > member". > > > > > > > > I agree with the validity of this scenario. I believe this is very > > > > close to the issue I attempted to bring on the list a short time > > > > ago. Of course, it assumes the existence of a rogue CA at some > point > > > > in > > > time. > > > > > > > > Note that the CRL could be directly inserted into a "long term" > > > > signature (according to RFC3126 for example). This does not > require > > > > a repository break-in and makes the "attack" even more realistic. > > > > > > > > Regards. > > > > > > > > -- > > > > Julien Stern > > > > > > > > > > > > > > Tom Gindin > > > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > > ----- > > > > > > > > > > > > > > > Tom Gindin > > > > > 05/23/2005 10:46 PM > > > > > > > > > > To: wpolk@nist.gov > > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > > kent@bbn.com, > > > > > stefans@microsoft.com > > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > > Tim: > > > > > > > > > > I should probably have brought this up earlier, but are > we > > > > certain > > > > > that "same trust anchor" is a strong enough check that the CRL > > > signer is > > > > > the one expected by the issuing CA? While I was not in San > Diego > > > when > > > > > this wording was included in the 3280 series, I do not really > > > > > think > > > that > > > > > that check is strong enough. I would suggest instead that the > CRL > > > > > signer's certificate needs to be directly issued by one of the > > > > > CA's > > > in > > > > the > > > > > certification path back to the trust anchor used for the > > > certificate's > > > > > verification, or by that anchor itself, unless people have > > > > > practical experience with CA structures which that rule would > > > > > prohibit. > > > Forcing > > > > the > > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > > by > > > a > > > > > hierarchical superior, so it is IMHO too strict. > > > > > I am personally not sure, FWIW, that a CRL should be > > > permitted > > > > to > > > > > be signed by a second-cousin certificate of the issuer's > > > certificate. > > > > By > > > > > analogy to the use of the terms in families, "sibling" > > > > > certificates > > > > would > > > > > have the same issuer, "first-cousin" certificates would be > issued > > > > > by siblings, and "second-cousin" certificates would be issued by > > > > > first cousins - so they are both three levels down from the same > > > > > trust > > > anchor, > > > > > or from the last common CA in their paths. This issue is not > > > > > newly > > > > caused > > > > > by CRL AIA, since the same issue can arise with CRL's containing > > > only > > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > > wrong) > > > > more > > > > > quickly. > > > > > In any case, nothing more than a note in Security > > > Considerations > > > > > is appropriate in any of our RFC's other than 3280 and its > > > successor. > > > > > > > > > > Tom Gindin > > > > > P.S. - The above views are mine, and not necessarily those of > my > > > > employer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > > 05/10/2005 05:27 PM > > > > > > > > > > To: ietf-pkix@imc.org > > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > > housley@vigilsec.com > > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > > specification "Internet X.509 Public Key Infrastructure: > Authority > > > > > Information > > > Access > > > > > CRL > > > > > Extension". While some issues raised in the working group are > > > > unresolved, > > > > > > > > > > the editors believe that rough consensus supports the current > > > > > specification. > > > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > > will > > > not > > > > > close before May 24. > > > > > > > > > > Thanks, > > > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 21:09:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18593 for ; Wed, 25 May 2005 21:09:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q0JcQs039206; Wed, 25 May 2005 17:19:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q0JcLM039205; Wed, 25 May 2005 17:19:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sniper.kisa.or.kr ([211.252.150.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4Q0JZYJ039189 for ; Wed, 25 May 2005 17:19:37 -0700 (PDT) (envelope-from jhyoon@kisa.or.kr) Received: (snipe 30238 invoked by alias); 26 May 2005 09:18:03 +0900 Received: from jhyoon@kisa.or.kr with Spamsniper 2.83.29 (Processed in 0.010963 secs); Received: from unknown (HELO 5434d1) (172.16.7.114) by unknown with SMTP; 26 May 2005 09:18:03 +0900 X-RCPTTO: ietf-pkix@imc.org Message-ID: <001501c56188$964f40b0$720710ac@5434d1> From: "Jaeho Yoon" To: Subject: [draft-ietf-pkix-sim-04.txt] Date: Thu, 26 May 2005 09:19:31 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C561D4.05FB6650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C561D4.05FB6650 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBQS0lYIFdHIG1lbWJlcnMsDQoNClBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gdGhl IGZvbGxvd2luZyBkcmFmdCA6IA0KSW50ZXJuZXQgWC41MDkgUHVibGljIEtleSBJbmZyYXN0cnVj dHVyZSBTdWJqZWN0IElkZW50aWZpY2F0aW9uIE1ldGhvZCAoU0lNKQ0KPGRyYWZ0LWlldGYtcGtp eC1zaW0tMDQudHh0PiANCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtc2ltLTA0LnR4 dA0KDQpUaGlzIGRvY3VtZW50IGRlZmluZXMgUHJpdmFjeS1FbmhhbmNlZCBQcm90ZWN0ZWQgU3Vi amVjdCBJZGVudGlmaWVyKFBFUFNJKSBmb3JtYXQgZm9yIGluY2x1ZGluZyBhIHByaXZhY3kgc2Vu c2l0aXZlIGlkZW50aWZpZXIgaW4gdGhlIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbiBvZiBhIGNl cnRpZmljYXRlLiBUaGUgUEVQU0kgaXMgYW4gb3B0aW9uYWwgZmVhdHVyZSB0aGF0IG1heSBiZSB1 c2VkIGJ5IGEgcmVseWluZyBwYXJ0aWVzIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZSBzdWJqZWN0 IG9mIGEgcGFydGljdWxhciBjZXJ0aWZpY2F0ZSBpcyBhbHNvIHRoZSBwZXJzb24gY29ycmVzcG9u ZGluZyB0byBhIHBhcnRpY3VsYXIgc2Vuc2l0aXZlIGlkZW50aWZpZXIuDQogICAgICAgIA0KUmVn YXJkcywgDQoNCkphZWhvIFlvb24NCg== ------=_NextPart_000_0012_01C561D4.05FB6650 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMjYyNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+RGVhciBQS0lYIFdHIG1lbWJlcnMs PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5QbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50 IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgOiA8L0RJVj4NCjxESVY+SW50ZXJuZXQgWC41MDkgUHVi bGljIEtleSBJbmZyYXN0cnVjdHVyZSBTdWJqZWN0Jm5ic3A7SWRlbnRpZmljYXRpb24gTWV0aG9k IA0KKFNJTSk8QlI+Jmx0O2RyYWZ0LWlldGYtcGtpeC1zaW0tMDQudHh0Jmd0OyA8L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxC Uj48QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtcGtpeC1zaW0tMDQudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLXBraXgtc2ltLTA0LnR4dDwvQT48QlI+PEJSPlRoaXMgDQpkb2N1bWVudCBkZWZp bmVzIFByaXZhY3ktRW5oYW5jZWQgUHJvdGVjdGVkIFN1YmplY3QgSWRlbnRpZmllcihQRVBTSSkg Zm9ybWF0IGZvciANCmluY2x1ZGluZyBhIHByaXZhY3kgc2Vuc2l0aXZlIGlkZW50aWZpZXIgaW4g dGhlIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbiBvZiBhIA0KY2VydGlmaWNhdGUuIFRoZSBQRVBT SSBpcyBhbiBvcHRpb25hbCBmZWF0dXJlIHRoYXQgbWF5IGJlIHVzZWQgYnkgYSByZWx5aW5nIA0K cGFydGllcyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgc3ViamVjdCBvZiBhIHBhcnRpY3VsYXIg Y2VydGlmaWNhdGUgaXMgYWxzbyB0aGUgDQpwZXJzb24gY29ycmVzcG9uZGluZyB0byBhIHBhcnRp Y3VsYXIgc2Vuc2l0aXZlIA0KaWRlbnRpZmllci48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj5SZWdhcmRzLCA8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+SmFlaG8gWW9vbjxCUj48L0RJVj48L0JPRFk+PC9I VE1MPg0K ------=_NextPart_000_0012_01C561D4.05FB6650-- From owner-ietf-pkix@mail.imc.org Wed May 25 22:50:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27691 for ; Wed, 25 May 2005 22:50:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q22FxL066512; Wed, 25 May 2005 19:02:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q22Fq6066510; Wed, 25 May 2005 19:02:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q22Dkv066489 for ; Wed, 25 May 2005 19:02:13 -0700 (PDT) (envelope-from andrewsciberras@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so365818rne for ; Wed, 25 May 2005 19:02:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=EkI6kQAWsU62nj1nOISgueP3iYp19aWQNVX2g98h3zfgTxPsP26nbAparay1imdairrtvwCkOz03pJxG9W/8pBYIb/GDvS9XcFA9IirC6hg82TfNZYLlNCIVacO0g/kpBVG4wGoKR9HqQELJmkq85bTHmd8HqkJxxHI7TzZMQpM= Received: by 10.38.153.45 with SMTP id a45mr1528028rne; Wed, 25 May 2005 19:02:12 -0700 (PDT) Received: from ?192.168.1.13? ([202.164.196.167]) by mx.gmail.com with ESMTP id k21sm457814rnb.2005.05.25.19.02.11; Wed, 25 May 2005 19:02:12 -0700 (PDT) Message-ID: <42952E61.4020601@gmail.com> Date: Thu, 26 May 2005 12:03:13 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jaeho Yoon CC: ietf-pkix@imc.org Subject: Re: [draft-ietf-pkix-sim-04.txt] References: <001501c56188$964f40b0$720710ac@5434d1> In-Reply-To: <001501c56188$964f40b0$720710ac@5434d1> Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jaeho Yoon wrote:
Please review and comment on the following draft :
Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
<draft-ietf-pkix-sim-04.txt>
Hi,

Just a couple of little things...

Since your defining ASN.1 types, it would probably be a good idea to reference an ASN.1 specification, including the year. The year is important because newer versions of the specification wont accept (or compile) your ASN.1 module do to the usage of the UTF8String reserved keyword as a typereference.

The [PI] reference should probably refer to RFC4043

Cheers,
Andrew
From owner-ietf-pkix@mail.imc.org Wed May 25 23:05:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28783 for ; Wed, 25 May 2005 23:05:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2MAb6072099; Wed, 25 May 2005 19:22:10 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q2MArH072098; Wed, 25 May 2005 19:22:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2M95m072081 for ; Wed, 25 May 2005 19:22:09 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2M4hh019058 for ; Wed, 25 May 2005 22:22:04 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4Q2M4hk090058 for ; Wed, 25 May 2005 22:22:04 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4Q2M4Ec017753 for ; Wed, 25 May 2005 22:22:04 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2M3rk017750; Wed, 25 May 2005 22:22:03 -0400 In-Reply-To: To: "Stefan Santesson" Cc: "Santosh Chokhani" , ietf-pkix@imc.org, "Julien Stern" MIME-Version: 1.0 Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Wed, 25 May 2005 22:21:59 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/25/2005 22:22:03, Serialize complete at 05/25/2005 22:22:03 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: I can't find any loop control text on this subject in 3280 or 3280-bis. I don't know what a practical validation library would do with a potential loop like this, and I doubt if anybody who hasn't written such a library knows either. One of the things it might do is note that the certificate is already being validated and assume that its validation result is sufficient. That avoids the loop, at the cost of letting this certificate through. Being sure that the library will encounter a loop depends on the library's author interpreting "Obtain and validate the certification path for the complete CRL issuer" to include calling a revocation check on each element in the path and not assuming that a bad certificate already being validated once will be caught elsewhere in the algorithm. On a related issue, the certpathbuild I-D may be just as involved in our discussions as 3280-bis. Its security considerations section on CRL signer paths is considerably more elaborate than 3280's discussion, and does not consider that terminating at the same trust anchor is good enough. Tom Gindin "Stefan Santesson" 05/25/2005 02:17 PM To: Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" cc: , "Julien Stern" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, > cc: "'Julien Stern'" > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, > but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion > would have to take place at some point regarding the overall security > model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Wed May 25 23:05:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28822 for ; Wed, 25 May 2005 23:05:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2M5WX072088; Wed, 25 May 2005 19:22:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q2M58k072087; Wed, 25 May 2005 19:22:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2M4eJ072071 for ; Wed, 25 May 2005 19:22:04 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2Lxig013375 for ; Wed, 25 May 2005 22:21:59 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4Q2Lxhk069204 for ; Wed, 25 May 2005 22:21:59 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4Q2LwXZ013584 for ; Wed, 25 May 2005 22:21:58 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2Lwex013581; Wed, 25 May 2005 22:21:58 -0400 In-Reply-To: <000401c56129$83eb3370$9a00a8c0@hq.orionsec.com> To: "Santosh Chokhani" Cc: ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Wed, 25 May 2005 22:21:54 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/25/2005 22:21:57, Serialize complete at 05/25/2005 22:21:57 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh: I thought that I had made that particular issue clear. The indirect CRL being retrieved governs C's certificates and its issuer name (call it C1) is supposed to belong to C. Indeed, C has issued a CRL signing certificate with subject name C1. However, S has created another CRL signing certificate with this same subject name and has created a CRL with that key pair. C did not create any circularity. The original certificate for C1 was issued by C and the corresponding private key belongs to an entity under C's control, while the new certificate for C1 was issued by S and the corresponding private key belongs to a malicious subsystem inside S. While certificates are issued to entities, relying parties know the name and the chain but not the entity. No relevant CRL is issued by S. I'm sure that your objection to ' looking at CRL issued by C' actually meant 'issued by S', because you normally verify certificates by looking at CRL's issued by the certificate issuer or its delegate. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/25/2005 08:58 AM To: cc: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, It is not clear from your example who the indirect CRL issuer is and what role the "indirect CRL" plays in the attack. If S is the indirect CRL issuer, C should be smart enough to not create circularity (a good toolkit will not verify path when C issues a certificate to S and points to S as the indirect CRL issuer since it causes circularity and chicken and egg problem). That scenario can be easily rectified within current standard by C not declaring S as the indirect CRL issuer for certificate issued to S. C can declare itself in the CDP or some other issuer. I suspect you do not mean this. Your example may be simpler. To me the attack is still not plausible. Your scenario is not detailed enough to illustrate an attack. It does not seem that there is a way to validate the certificate issued to C by S without looking at CRL issued by C, resulting in circularity, which relying party clients should not accept. (Note that my November presentation to IETF in DC covered the circularity issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to the CRL certification path) -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, May 25, 2005 7:50 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; 'Julien Stern' Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 26 03:49:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07544 for ; Thu, 26 May 2005 03:48:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q6rsw7015419; Wed, 25 May 2005 23:53:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q6rsn5015418; Wed, 25 May 2005 23:53:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q6rqj4015380 for ; Wed, 25 May 2005 23:53:53 -0700 (PDT) (envelope-from olivier.dubuisson@francetelecom.com) Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 08:53:49 +0200 Received: from [10.193.13.92] ([10.193.13.92]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 08:53:49 +0200 Message-ID: <4295727D.1020100@francetelecom.com> Date: Thu, 26 May 2005 08:53:49 +0200 From: Olivier Dubuisson Organization: France Telecom - Research & Development User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Sciberras CC: Jaeho Yoon , ietf-pkix@imc.org Subject: Re: [draft-ietf-pkix-sim-04.txt] References: <001501c56188$964f40b0$720710ac@5434d1> <42952E61.4020601@gmail.com> In-Reply-To: <42952E61.4020601@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2005 06:53:49.0550 (UTC) FILETIME=[AB98E8E0:01C561BF] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Andrew Sciberras wrote: > Jaeho Yoon wrote: > >> Please review and comment on the following draft : >> Internet X.509 Public Key Infrastructure Subject Identification Method >> (SIM) >> > > Hi, > > Just a couple of little things... > > Since your defining ASN.1 types, it would probably be a good idea to > reference an ASN.1 specification, including the year. The right references are there: http://asn1.elibel.tm.fr/en/standards/index.htm > The year is > important because newer versions of the specification wont accept (or > compile) your ASN.1 module do to the usage of the UTF8String reserved > keyword as a typereference. Why redefine the UTF8String instead of using the one standardized in the ASN.1 standard? -- Olivier DUBUISSON France Telecom Recherche & Developpement R&D/MAPS/AMS - 22307 Lannion Cedex - France t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/ From owner-ietf-pkix@mail.imc.org Thu May 26 05:40:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14529 for ; Thu, 26 May 2005 05:40:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q8gbge030944; Thu, 26 May 2005 01:42:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q8gba3030943; Thu, 26 May 2005 01:42:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q8gZ58030933 for ; Thu, 26 May 2005 01:42:36 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA14146 for ; Thu, 26 May 2005 10:57:39 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052610422807:1303 ; Thu, 26 May 2005 10:42:28 +0200 Message-ID: <42958C32.8020706@bull.net> Date: Thu, 26 May 2005 10:43:30 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: pkix Subject: 3280bis: CRL validation X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/05/2005 10:42:28, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/05/2005 10:42:30, Serialize complete at 26/05/2005 10:42:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit To the list, I changed the name of the thread which is now under 3280bis. As Tim mentioned: "it is clear that the current content of 3280bis with respect to CRL validation does not enjoy consensus within the working group". Issues 33 and 43 are directly related to this topic. They are both copied below: 33) The certificateIssuer CRL entry extension contains a GeneralNames. While RFC 3280 does not state this, there seems to be general agreement that the certificateIssuer extension should only contain the DN from the issuer field of the certificate being revoked. 3280bis states: "Conforming CRL issuers MUST include in [the certificateIssuer] extension the distinguished name (DN) from the issuer field of the certificate that corresponds to this CRL entry. The encoding of the DN MUST be identical to the encoding used in the certificate." 43) It should be noted in 3280bis that there is a risk that two different CAs (or a CA and a CRL issuer) may issue certificates and CRLs under the same name and that if this happens there is a risk that a relying party will validate a certificate issued by one of these entities using a CRL issued by the other. The security considerations section of 3280bis states that CAs and CRL issuers should be formed in a way that reduces the likelihood of name collisions. It also states that implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate terminate at the same trust anchor. Both statements are incorrect. For issue 43: name collisions are possible and a design cannot be based on the assumption that name collisions, whether accidental or intentional, will never happen. This means that chosing names to "reduce the likehood of name collisions" is not a way to solve the issue. Termination at the same trust anchor without additional details does not solve the issue either. For issue 33: the certificateIssuer extension is defined as : certificateIssuer ::= GeneralNames with GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName It is not defined as: certificateIssuer ::= GeneralName ... and this is NOT an error. To go directly to the point, certificateIssuer may contain in practice either: - one name, or - a sequence of names. If it contains one name, this means that this name MUST be certified by the CA that has issued the certificate where the extension appears. If it contains a sequence of names, this means that the certification path of the CRL issuer certificate formed using that sequence of names MUST also terminate at the trust anchor of the target certificate. This is secure and avoids any name collision, either deliberate or intentional. Denis From owner-ietf-pkix@mail.imc.org Thu May 26 05:51:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15306 for ; Thu, 26 May 2005 05:51:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q96k07032616; Thu, 26 May 2005 02:06:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q96k6m032615; Thu, 26 May 2005 02:06:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q96j5N032608 for ; Thu, 26 May 2005 02:06:45 -0700 (PDT) (envelope-from aalberti@axway.com) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id j4Q95KNg031948; Thu, 26 May 2005 11:05:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: 3280bis: CRL validation Date: Thu, 26 May 2005 11:00:30 +0200 Message-ID: Thread-Topic: 3280bis: CRL validation Thread-Index: AcVh0Glcm/QNTzxlS8u5gg6UddMuUgAAKgbw From: "Alberti Antoine" To: "Denis Pinkas" , "pkix" X-OriginalArrivalTime: 26 May 2005 09:09:13.0437 (UTC) FILETIME=[95CFB0D0:01C561D2] X-Scanned-By: MIMEDefang 2.38 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j4Q96k5N032610 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The fact that a cert is a trust anchor becomes very personal when using a cross-certified model: two parties are not supposed to have the same ones, but can still communicate. > -----Message d'origine----- > De : owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]De la part de Denis Pinkas > Envoyé : jeudi 26 mai 2005 10:44 > À : pkix > Objet : 3280bis: CRL validation > > > > To the list, > > I changed the name of the thread which is now under 3280bis. > > As Tim mentioned: "it is clear that the current content of > 3280bis with > respect to CRL validation does not enjoy consensus within the > working group". > > Issues 33 and 43 are directly related to this topic. They are > both copied > below: > > 33) The certificateIssuer CRL entry extension contains a > GeneralNames. > While RFC 3280 does not state this, there seems to be general > agreement that > the certificateIssuer extension should only contain the DN > from the issuer > field of the certificate being revoked. > > 3280bis states: "Conforming CRL issuers MUST include in [the > certificateIssuer] extension the distinguished name (DN) from the > issuer field of the certificate that corresponds to this CRL entry. > The encoding of the DN MUST be identical to the encoding > used in the > certificate." > > > 43) It should be noted in 3280bis that there is a risk that > two different > CAs (or a CA and a CRL issuer) may issue certificates > and CRLs under > the same name and that if this happens there is a risk > that a relying > party will validate a certificate issued by one of > these entities > using a CRL issued by the other. > > The security considerations section of 3280bis states that > CAs and CRL > issuers should be formed in a way that reduces the > likelihood of name > collisions. It also states that implementations > validating CRLs MUST > ensure that the certification path of the target > certificate and the > CRL issuer certification path used to validate the target > certificate > terminate at the same trust anchor. > > Both statements are incorrect. > > For issue 43: name collisions are possible and a design > cannot be based on > the assumption that name collisions, whether accidental or > intentional, will > never happen. This means that chosing names to "reduce the > likehood of name > collisions" is not a way to solve the issue. Termination at > the same trust > anchor without additional details does not solve the issue either. > > For issue 33: the certificateIssuer extension is defined as : > > certificateIssuer ::= GeneralNames > > with > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > It is not defined as: > > certificateIssuer ::= GeneralName > > ... and this is NOT an error. > > To go directly to the point, certificateIssuer may contain in > practice either: > > - one name, or > - a sequence of names. > > If it contains one name, this means that this name MUST be > certified by the > CA that has issued the certificate where the extension appears. > > If it contains a sequence of names, this means that the > certification path > of the CRL issuer certificate formed using that sequence of > names MUST also > terminate at the trust anchor of the target certificate. > > This is secure and avoids any name collision, either > deliberate or intentional. > > Denis > > From owner-ietf-pkix@mail.imc.org Thu May 26 05:52:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15393 for ; Thu, 26 May 2005 05:52:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q8xxMs032103; Thu, 26 May 2005 01:59:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q8xxgM032102; Thu, 26 May 2005 01:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q8xvYJ032093 for ; Thu, 26 May 2005 01:59:58 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA22652 for ; Thu, 26 May 2005 11:15:01 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052610595055:1323 ; Thu, 26 May 2005 10:59:50 +0200 Message-ID: <42959044.4070802@bull.net> Date: Thu, 26 May 2005 11:00:52 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: pkix Subject: 3280bis: key usage (13) X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/05/2005 10:59:50, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/05/2005 10:59:52, Serialize complete at 26/05/2005 10:59:52 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit To the list, The disposition of comments states: 13) The descriptions of the meanings of the digitalSignature and nonRepudiation bits of keyUsage may need to be adjusted based on the work in X.509 The new text in X.509 aligns with the text in RFC 3280. No changes are required to 3280bis. A comment has been added to the ASN.1 for KeyUsage stating that "recent editions of X.509 have renamed [the nonRepudiation] bit to contentCommitment" This statement is untrue. The text from X.509 has been published in Corrigendum 3 (04/2004) on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). An extract from this text is copied below: a) digitalSignature: for verifying digital signatures that are used with an entity authentication service, a data origin authentication service or/and an integrity service; b) contentCommitment: for verifying digital signatures which are intended to signal that the signer is committing to the content being signed. The type of commitment the certificate can be used to support may be further constrained by the CA, e.g. through a certificate policy. The precise type of commitment of the signer e.g. "reviewed and approved" or "with the intent to be bound", may be signalled by the content being signed, e.g. the signed document itself or some additional signed information. Since a content commitment signing is considered to be a digitally signed transaction, the digitalSignature bit need not be set in the certificate. If it is set, it does not affect the level of commitment the signer has endowed in the signed content. Note that it is not incorrect to refer to this keyUsage bit using the identifier nonRepudiation. However, the use of this identifier has been deprecated. Regardless of the identifier used, the semantics of this bit are as specified in this Directory Specification. The text from 3280 is copied below: The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. The nonRepudiation bit is asserted when the subject public key is used to verify digital signatures used to provide a non- repudiation service which protects against the signing entity falsely denying some action, excluding certificate or CRL signing. In the case of later conflict, a reliable third party may determine the authenticity of the signed data. Further distinctions between the digitalSignature and nonRepudiation bits may be provided in specific certificate policies. The text from 3280bis does not align with the ISO-ITU text. Please align with the the ISO-ITU text. Denis From owner-ietf-pkix@mail.imc.org Thu May 26 08:55:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26171 for ; Thu, 26 May 2005 08:55:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QC3bce071632; Thu, 26 May 2005 05:03:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QC3bsi071631; Thu, 26 May 2005 05:03:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QC3bFa071621 for ; Thu, 26 May 2005 05:03:37 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4QC3a8e026461 for ; Thu, 26 May 2005 08:03:36 -0400 From: "Santosh Chokhani" To: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Thu, 26 May 2005 08:03:26 -0400 Message-ID: <00a601c561ea$f12a2600$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QC3bFa071626 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Tom and Stefan, See below in [Santosh:] -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Wednesday, May 25, 2005 10:22 PM To: Stefan Santesson Cc: Santosh Chokhani; ietf-pkix@imc.org; Julien Stern Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Stefan: I can't find any loop control text on this subject in 3280 or 3280-bis. I don't know what a practical validation library would do with a potential loop like this, and I doubt if anybody who hasn't written such a library knows either. [Santosh: We at Orion has developed a library called PKIF for USMC that exactly does this. We found this circularity problem and our library went into neverland with infinite loop and we added loop control logic. So, saying that no one does or understands these things is dangerous and wrong in this case.] One of the things it might do is note that the certificate is already being validated and assume that its validation result is sufficient. That avoids the loop, at the cost of letting this certificate through. Being sure that the library will encounter a loop depends on the library's author interpreting "Obtain and validate the certification path for the complete CRL issuer" to include calling a revocation check on each element in the path and not assuming that a bad certificate already being validated once will be caught elsewhere in the algorithm. [Santosh: If I understand the above, be assured that X.509 requires that a CRL signature be verified using a public key that is fully validated per the X.509 certification path validation requirement, including revocation status checking of all the certificates in the CRL certification path] On a related issue, the certpathbuild I-D may be just as involved in our discussions as 3280-bis. Its security considerations section on CRL signer paths is considerably more elaborate than 3280's discussion, and does not consider that terminating at the same trust anchor is good enough. Tom Gindin "Stefan Santesson" 05/25/2005 02:17 PM To: Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" cc: , "Julien Stern" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, > cc: "'Julien Stern'" > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion would have to take place at some point regarding the > overall security model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 26 08:56:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26234 for ; Thu, 26 May 2005 08:56:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBw8VD071226; Thu, 26 May 2005 04:58:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QBw8L6071225; Thu, 26 May 2005 04:58:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBw7rb071215 for ; Thu, 26 May 2005 04:58:08 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4QBw68e006635 for ; Thu, 26 May 2005 07:58:06 -0400 From: "Santosh Chokhani" To: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Thu, 26 May 2005 07:57:59 -0400 Message-ID: <00a001c561ea$2c8b37d0$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tom, BTW, we may be putting Peter Guttman and rest of the group to sleep again, which may not be all bad. You need to provide a clear streamlined scenario. From what I discern, you are saying the following. Root R --> C C --> C1 as CRL issuer & C --> S and C asserts in S C1. C1 issues CRL. S goes rouge. C instructs C1 to put S on CRLgood. S --> C1. Now, the new C1 can issue a CRLbad without S on it. In order to verify signature on CRLbad, you need the path R --> C --> S --> C1. But, note that in order to verify signature on C --> S either you will find the correct path and CRL (R --> C --> C1 and CRLgood) or you will have circularity since C-->S require C1 CRL. There is no sense in having this e-mail discussion unless you lay out the scenario precisely as above as to what the various certification paths are. So far, when I fill in the gaps, all I see is circularity issues or what Stefan calls infinite loops. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Wednesday, May 25, 2005 10:22 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: I thought that I had made that particular issue clear. The indirect CRL being retrieved governs C's certificates and its issuer name (call it C1) is supposed to belong to C. Indeed, C has issued a CRL signing certificate with subject name C1. However, S has created another CRL signing certificate with this same subject name and has created a CRL with that key pair. C did not create any circularity. The original certificate for C1 was issued by C and the corresponding private key belongs to an entity under C's control, while the new certificate for C1 was issued by S and the corresponding private key belongs to a malicious subsystem inside S. While certificates are issued to entities, relying parties know the name and the chain but not the entity. No relevant CRL is issued by S. I'm sure that your objection to ' looking at CRL issued by C' actually meant 'issued by S', because you normally verify certificates by looking at CRL's issued by the certificate issuer or its delegate. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/25/2005 08:58 AM To: cc: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, It is not clear from your example who the indirect CRL issuer is and what role the "indirect CRL" plays in the attack. If S is the indirect CRL issuer, C should be smart enough to not create circularity (a good toolkit will not verify path when C issues a certificate to S and points to S as the indirect CRL issuer since it causes circularity and chicken and egg problem). That scenario can be easily rectified within current standard by C not declaring S as the indirect CRL issuer for certificate issued to S. C can declare itself in the CDP or some other issuer. I suspect you do not mean this. Your example may be simpler. To me the attack is still not plausible. Your scenario is not detailed enough to illustrate an attack. It does not seem that there is a way to validate the certificate issued to C by S without looking at CRL issued by C, resulting in circularity, which relying party clients should not accept. (Note that my November presentation to IETF in DC covered the circularity issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to the CRL certification path) -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, May 25, 2005 7:50 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; 'Julien Stern' Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 26 10:31:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02903 for ; Thu, 26 May 2005 10:31:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QDjcKa002532; Thu, 26 May 2005 06:45:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QDjcCE002531; Thu, 26 May 2005 06:45:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QDjYQo002520 for ; Thu, 26 May 2005 06:45:35 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 8A60014C062; Thu, 26 May 2005 14:45:24 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A07CCE6FB01; Thu, 26 May 2005 14:45:24 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id 57F5814C062; Thu, 26 May 2005 14:45:24 +0100 (IST) Message-ID: <4295D3EB.5010800@cs.tcd.ie> Date: Thu, 26 May 2005 14:49:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> In-Reply-To: <42959044.4070802@bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.731) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A17CCE6FB01 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Denis, > Please align with the the ISO-ITU text. Do you mean we should rename the bits and include the other new x.509 text? The design team were against doing that. Is there any (good) reason other than alignment to make such a change? Personally, I find the new x.509 text worse, although it does say: "Note that it is not incorrect to refer to this keyUsage bit using the identifier nonRepudiation." So I can argue that we are aligned, just not identical. But of course, I'm from the non-repudiation is non-sense camp so I may not be the best judge. Stephen. PS: A quibble: > The new text in X.509 aligns with the text in RFC 3280. No changes > are required to 3280bis. A comment has been added to the ASN.1 for > KeyUsage stating that "recent editions of X.509 have renamed > [the nonRepudiation] bit to contentCommitment" > > This statement is untrue. The paragraph to which I assume you refer contains 3 statements - it'd be easier to close these threads if you were more precise. (I think I got what you want by the end of the mail though...) PPS: "This statement is untrue." Are you from Crete after all? :-) Denis Pinkas wrote: > > To the list, > > The disposition of comments states: > > 13) The descriptions of the meanings of the digitalSignature and > nonRepudiation bits of keyUsage may need to be adjusted based > on the work in X.509 > > The new text in X.509 aligns with the text in RFC 3280. No changes > are required to 3280bis. A comment has been added to the ASN.1 for > KeyUsage stating that "recent editions of X.509 have renamed > [the nonRepudiation] bit to contentCommitment" > > This statement is untrue. > > The text from X.509 has been published in Corrigendum 3 (04/2004) > on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called > > ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). > > An extract from this text is copied below: > > a) digitalSignature: for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service; > > b) contentCommitment: for verifying digital signatures which are intended > to signal that the signer is committing to the content being signed. > The type of commitment the certificate can be used to support may be > further constrained by the CA, e.g. through a certificate policy. > The precise type of commitment of the signer e.g. "reviewed and > approved" or "with the intent to be bound", may be signalled by the > content being signed, e.g. the signed document itself or some additional > signed information. > > Since a content commitment signing is considered to be a digitally > signed > transaction, the digitalSignature bit need not be set in the > certificate. > If it is set, it does not affect the level of commitment the signer has > endowed in the signed content. > > Note that it is not incorrect to refer to this keyUsage bit using the > identifier nonRepudiation. However, the use of this identifier has been > deprecated. Regardless of the identifier used, the semantics of this bit > are as specified in this Directory Specification. > > The text from 3280 is copied below: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > The nonRepudiation bit is asserted when the subject public key is > used to verify digital signatures used to provide a non- > repudiation service which protects against the signing entity > falsely denying some action, excluding certificate or CRL signing. > In the case of later conflict, a reliable third party may > determine the authenticity of the signed data. > > Further distinctions between the digitalSignature and > nonRepudiation bits may be provided in specific certificate > policies. > > The text from 3280bis does not align with the ISO-ITU text. > Please align with the the ISO-ITU text. > > Denis > > > > From owner-ietf-pkix@mail.imc.org Thu May 26 11:01:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04927 for ; Thu, 26 May 2005 11:01:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QE1oVs004130; Thu, 26 May 2005 07:01:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QE1oUw004129; Thu, 26 May 2005 07:01:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QE1mW2004121 for ; Thu, 26 May 2005 07:01:48 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 3429 invoked by uid 0); 26 May 2005 14:01:14 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.12.30) by woodstock.binhost.com with SMTP; 26 May 2005 14:01:14 -0000 Message-Id: <6.2.1.2.2.20050526095809.05835eb0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 26 May 2005 10:01:14 -0400 To: Olivier Dubuisson , Andrew Sciberras From: Russ Housley Subject: Re: [draft-ietf-pkix-sim-04.txt] Cc: Jaeho Yoon , ietf-pkix@imc.org In-Reply-To: <4295727D.1020100@francetelecom.com> References: <001501c56188$964f40b0$720710ac@5434d1> <42952E61.4020601@gmail.com> <4295727D.1020100@francetelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is not fair to abuse new authors for following long-standing PKIX and S/MIME WG convention. These WGs have chosen to use the 1988 ASN.1 syntax because there are free tools that support it. If you have information about freeware tools that support the later syntax, please let us know. Russ At 02:53 AM 5/26/2005, Olivier Dubuisson wrote: >Why redefine the UTF8String instead of using the one standardized in the >ASN.1 standard? From owner-ietf-pkix@mail.imc.org Thu May 26 11:27:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06483 for ; Thu, 26 May 2005 11:27:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QEY8XL014022; Thu, 26 May 2005 07:34:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QEY81g014021; Thu, 26 May 2005 07:34:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QEY7GR014003 for ; Thu, 26 May 2005 07:34:07 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 565293464D; Fri, 27 May 2005 02:34:06 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08975-10; Fri, 27 May 2005 02:34:06 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 60AA934500; Fri, 27 May 2005 02:34:04 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0EB9737750; Fri, 27 May 2005 02:34:04 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DbJR7-0007jz-00; Fri, 27 May 2005 02:34:13 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: andrewsciberras@gmail.com, housley@vigilsec.com, Olivier.Dubuisson@francetelecom.com Subject: Re: [draft-ietf-pkix-sim-04.txt] Cc: ietf-pkix@imc.org, jhyoon@kisa.or.kr In-Reply-To: <6.2.1.2.2.20050526095809.05835eb0@mail.binhost.com> Message-Id: Date: Fri, 27 May 2005 02:34:13 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >It is not fair to abuse new authors for following long-standing PKIX and >S/MIME WG convention. These WGs have chosen to use the 1988 ASN.1 syntax >because there are free tools that support it. If you have information about >freeware tools that support the later syntax, please let us know. These WGs have chosen to use the obsolete 1988 ASN.1 syntax because they couldn't be bothered learning anything newer. The (un)availability of freeware tools is merely the most convenient red herring available to support this position. I'n not aware of a single OSS/freeware project that is hampered by the unavailability of freeware ASN.1 tools (the only project of this kind that I know of that even uses one is SFL, and that doesn't seem to have any problems). Peter. From owner-ietf-pkix@mail.imc.org Thu May 26 12:07:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09081 for ; Thu, 26 May 2005 12:07:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QFEN6x019844; Thu, 26 May 2005 08:14:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QFENbD019843; Thu, 26 May 2005 08:14:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nelson.textdrive.com (nelson.textdrive.com [70.85.91.228]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QFELVP019835 for ; Thu, 26 May 2005 08:14:21 -0700 (PDT) (envelope-from pmhesse@geminisecurity.com) Received: from geminiph (unknown [70.21.21.141]) by nelson.textdrive.com (Postfix) with ESMTP id 13819114175; Thu, 26 May 2005 15:14:20 +0000 (GMT) From: "Peter Hesse" To: , "'David A. Cooper'" Cc: , , , , "'Zagar, Terry (Mission Systems)'" , "'Guy Tallent [SIG] (E-mail)'" , "'Gary Secrest [JJCUS] (E-mail)'" Subject: Comments on / suggested changes for RFC3280bis Date: Thu, 26 May 2005 11:14:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcVX1K4llWiL9DePTeCFxe3k0UJfvQKIX8gwAADGGJAAAGWhkAACmAwg In-Reply-To: <232C3D7FF15B854084DB58733FFD624101FFF1A7@XCGV4806.northgrum.com> Message-Id: <20050526151420.13819114175@nelson.textdrive.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit PKIX list and RFC3280bis editors, I apologize in advance for the length of this message. Below are comments on the RFC3280bis draft developed on behalf of Gemini Security and the SAFE-Biopharma Association. The SAFE-Biopharma Association's mission is to deliver unique electronic identity credentials for strong authentication and for the application of digital signatures for use in electronic systems and transactions across the bio-pharmaceutical industry. The SAFE-Biopharma Association manages the SAFE digital signature standard and associated operating policies for its Members, which include the world's leading biopharmaceutical companies, their business partners, and regulatory agencies. This message contains specific comments on and suggested changes to the RFC3280bis draft. For the most part these changes are meant to clarify and normalize the language used to specify required behavior of certificate processing systems and CAs/CRL issuers. Some additional changes are requested and reasons for them are also given. A real-world example of the unclear language related to behavior causing a problem: RFC3280 specified that the inhibitAnyPolicy extension be marked critical. At least one version of the Sun Java CertPath implementation rejects any certification paths containing inhibitAnyPolicy extensions which are not marked critical. The wording in RFC3280 was not clear that this was a requirement for issuers and not for implementations. (This issue has been fixed the current RFC3280bis draft, but remains in other places for other extensions.) I will also be providing these changes in a Word document with tracked changes to David Cooper for his use in developing the next draft. See below for the actual comments. I appreciate your willingness to consider these changes for the next draft. Sincerely, Peter Hesse ------------------------------------------------ Location: 3.3, 4th para, 6th line Original Text: "all currently issued CRLs are updated" Recommendation: "all currently issued CRLs are scheduled to be updated". Reason: Whether or not the CRL is updated doesn't affect notification, it is whether a scheduled update (specified in nextUpdate) was due to occur. Location: 4.2, 2nd para, last sentence Original Text: "The text for each extension specifies the acceptable values for the critical field." Recommendation: "The text for each extension specifies the acceptable values for conforming CAs and CRL Issuers to place in the critical field. Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.1, 5th para Original Text: "This extension MUST NOT be marked critical." Recommendation: "Conforming CAs MUST mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.2, 2nd para, last sentence Original Text: "Applications are not required to verify that key identifiers match when performing certification path validation." Recommendation: "Applications SHOULD NOT verify that key identifiers match when performing certification path validation." Reason: Key identifier matching is not part of determining whether or not a certification path is valid. Location: 4.2.1.2, next-to-last para Original Text: "This extension MUST NOT be marked critical." Recommendation:" Conforming CAs MUST mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.3, 2nd para, last sentence Original Text: "When this extension appears, it SHOULD be marked critical." Recommendation: "When this extension appears, conforming CAs SHOULD mark it critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.4, 3rd para, last sentence Original Text: "If this extension is critical, the path validation software MUST be able to interpret this extension (including the optional qualifier), or MUST reject the certificate." Comment: This sentence seems like an unnecessary repetition of the behavior required on all extensions, specified in the first para of 4.2. I recommend this sentence be removed. Location: 4.2.1.5, 5th para Original Text: "This extension MAY be supported by CAs and/or applications, and it SHOULD be critical." Recommendation: "This extension MAY be supported by CAs and/or applications, and conforming CAs SHOULD mark this extension critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.6, 3rd para, last sentence Original Text: "If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical." Recommendation: Add the following sentence. "Otherwise, conforming CAs SHOULD mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.7, 2nd para Original Text: "Where present, this extension SHOULD NOT be marked critical." Recommendation: "Where present, conforming CAs SHOULD mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.9, 4th para, 1st sentence Original Text: "This extension MUST appear in all CA certificates that contain public keys used to validate digital signatures on certificates." Recommendation: "Conforming CAs must place this extension in all CA certificates that contain public keys used to validate digital signatures on certificates." Reason: This statement is in conflict with the statement "verify that certificate i is a CA certificate through out-of-band means" in section 6.1.4. Location: 4.2.1.9, 4th para, 3rd sentence Original Text: "This extension MAY appear as a critical or non-critical extension in CA certificates that contain public keys..." Recommendation: "Conforming CAs MAY mark this extension as critical or non-critical in CA certificates that contain public keys..." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.9, 4th para, last sentence Original Text: "This extension MAY appear as a critical or non-critical extension in end entity certificates." Recommendation: "Conforming CAs MAY mark this extension as critical or non-critical in end entity certificates." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.11, 4th para, last sentence Original Text: "If the policyConstraints extension is marked critical and the inhibitPolicyMapping field is present, applications that do not implement support for the inhibitPolicyMapping field MUST reject the certificate." Comment: This seems to be encouraging different behavior depending on the criticality of the field, which goes against the spirit of extension processing. Location: 4.2.1.12, 6th para Original Text: "This extension MAY, at the option of the certificate issuer, be either critical or non-critical." Recommendation: "Conforming CAs MAY mark this extension either critical or non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) & normalization of text Location: 4.2.1.12, 8th para Original Text: "If the anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT be critical." Recommendation: "If the anyExtendedKeyUsage keyPurposeID is present, conforming CAs SHOULD NOT mark this extension critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 1st para, 2nd sentence Original Text: "The extension SHOULD be non-critical," Recommendation: "Conforming CAs SHOULD mark this extension non-critical," Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 2nd para, 4th sentence Original Text: "...not the CRL issuer, then the cRLIssuer field MUST be present and contain the Name of the CRL issuer." Recommendation: "...not the CRL issuer, then conforming CAs MUST include the cRLIssuer field containing the Name of the CRL issuer." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 2nd para, 5th sentence Original Text: "...is also the CRL issuer, then the cRLIssuer field MUST be omitted and the distributionPoint field MUST be present." Recommendation: "...is also the CRL issuer, then conforming CAs MUST omit the cRLIssuer field and MUST include the distributionPoint field." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 2nd para, last sentence Original Text: "If the distributionPoint field is omitted, cRLIssuer MUST be present and include a Name..." Recommendation: "If the distributionPoint field is omitted, conforming CAs MUST include the cRLIssuer field and include a Name..." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 5th para, last sentence Original Text: "DistributionPointName SHOULD include at least one LDAP or HTTP URI." Recommendation: Add the following sentence. "If both HTTP and LDAP DistributionPointName URI values are specified, the HTTP DistributionPointName SHOULD appear first." Reason: Firewalls are more likely to allow HTTP through, and HTTP typically results in faster access. Applications typically try distribution points in the order in which they appear. Location: 4.2.2.1, 13th para, 2nd sentence Original Text: "...and MAY specify a host name (e.g., ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina ry,crossCertificatePair;binary). Recommendation: remove ",crossCertificatePair;binary" from the example Reason: Attributes containing cross-certificate pairs should not be recommended. There is no way for the client to know whether or not they will be encountering cross-certificate pairs as opposed to certificates, without attempting to decode them and failing. Retrieving only cACertificate attribute should be sufficient if LDAPv3 schema is being followed. Location: 4.2.2.1, 13th para, last sentence Original Text: "The URI MUST list appropriate attribute descriptions for one or more attributes holding DER [X.690] encoded certificates or cross-certificate pairs." Recommendation: remove "or cross-certificate pairs" Reason: Same as above (4.2.2.1, 13th para, 2nd sentence). Location: 4.2.2.1, 16th para Original Text: " .p7c A DER encoded "certs-only" CMS message as specified in [RFC 2797]." Recommendation: " .p7c A DER encoded "certs-only" CMS message as specified in [RFC 2797] which MUST NOT contain self-signed certificates." Reason: Self-signed certificates retrieved externally should not be included because they cannot be trusted, Location: 4.2.2.1, 18th para Original Text: "The semantics of other id-ad-caIssuers accessLocation name forms are not defined." Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP accessLocations are specified, the HTTP accessLocation SHOULD appear first." Reason: Same as above (4.2.1.13, 5th para, last sentence). Location: 4.2.2.2, 9th para, 2nd sentence Original Text: "...and MAY specify a host name (e.g., ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina ry,crossCertificatePair;binary). Recommendation: remove ",crossCertificatePair;binary" from the example Reason: Same as above (4.2.2.1, 13th para, 2nd sentence). Location: 4.2.2.2, 9th para, last sentence Original Text: "The URI MUST list appropriate attribute descriptions for one or more attributes holding DER [X.690] encoded certificates or cross-certificate pairs." Recommendation: remove "or cross-certificate pairs" Reason: Same as above (4.2.2.1, 13th para, 2nd sentence). Location: 4.2.2.2, 12th para Original Text: " .p7c A DER encoded "certs-only" CMS message as specified in [RFC 2797]." Recommendation: " .p7c A DER encoded "certs-only" CMS message as specified in [RFC 2797] which MUST NOT contain self-signed certificates." Reason: Self-signed certificates retrieved externally should not be included because they cannot be trusted, Location: 4.2.2.2, 14th para Original Text: "The semantics of other id-ad-caRepository accessLocation name forms are not defined." Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP accessLocations are specified, the HTTP accessLocation SHOULD appear first." Reason: Same as above (4.2.1.13, 5th para, last sentence). Location: 5.1.2.5, 2nd para, 1st sentence Original Text: "This profile requires inclusion of nextUpdate in all CRLs issued by conforming CRL issuers." Recommendation: "Conforming CRL issuers MUST include the nextUpdate field in all CRLs." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) & normalization of text Location: 5.2.2, 2nd para Original Text: "The issuerAltName extension SHOULD NOT be marked critical." Recommendation: "Conforming CRL issuers SHOULD NOT mark the issuerAltName extension critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.2.3, 1st para Original Text: "The CRL number is a non-critical CRL extension which...MUST include this extension in all CRLs." Recommendation: "The CRL number is a CRL extension which...MUST include this extension in all CRLs and MUST mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) & normalization of text Location: 5.2.4, 1st para Original Text: "The delta CRL indicator is a critical CRL extension that...the local database without reprocessing information." Recommendation: "The delta CRL indicator is a CRL extension that...the local database without reprocessing information. Conforming CRL issuers MUST mark the delta CRL indicator extension critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) & normalization of text Location: 5.2.5, 1st para, 2nd sentence Original Text: "Although the extension is critical, conforming implementations are not required to support this extension." Recommendation: "Conforming CRL Issuers MUST mark this extension critical, but conforming implementations are not required to support this extension." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.2.6, 1st para, 2nd sentence Original Text: "The extension MUST be non-critical." Recommendation: "Conforming CRL issuers must mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.3.1, 1st para, 1st sentence Original Text: "The reasonCode is a non-critical CRL entry extension that identifies the reason for the certificate revocation." Recommendation: "The reasonCode is a CRL entry extension that identifies the reason for the certificate revocation. Conforming CRL issuers MUST mark this entry extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.3.2, 1st para Original Text: "The hold instruction code is a non-critical CRL entry extension that...placed on hold." Recommendation: "The hold instruction code is a CRL entry extension that...placed on hold. Conforming CRL issuers MUST mark this entry extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.3.3, 1st para Original Text: "The invalidity date is a non-critical CRL entry extension that...to share it with CRL users." Recommendation: "The invalidity date is a CRL entry extension that...to share it with CRL users. Conforming CRL issuers MUST mark this entry extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.3.4, 5th para, 1st sentence Original Text: "If used by conforming CRL issuers, this extension MUST always be critical." Recommendation: "If used by conforming CRL issuers, this extension MUST be marked critical." Reason: Normalization of text From owner-ietf-pkix@mail.imc.org Thu May 26 13:17:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14454 for ; Thu, 26 May 2005 13:17:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGRIA6032645; Thu, 26 May 2005 09:27:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGRIoi032644; Thu, 26 May 2005 09:27:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGRHgA032638 for ; Thu, 26 May 2005 09:27:17 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id D7F9D340A7; Fri, 27 May 2005 04:27:16 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29539-25; Fri, 27 May 2005 04:27:16 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 1B95F3482D; Fri, 27 May 2005 04:27:13 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6BBB33774F; Fri, 27 May 2005 04:27:13 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DbLCd-0007nR-00; Fri, 27 May 2005 04:27:23 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: david.cooper@nist.gov, ietf-pkix@imc.org, pmhesse@geminisecurity.com Subject: Re: Comments on / suggested changes for RFC3280bis Cc: chokhani@orionsec.com, GSecrest@CORUS.JNJ.com, guy@strategicidentitygroup.com, mcooper@orionsec.com, MRamos8@CORUS.JNJ.com, RGuida@CORUS.JNJ.com, Terry.Zagar@ngc.com In-Reply-To: <20050526151420.13819114175@nelson.textdrive.com> Message-Id: Date: Fri, 27 May 2005 04:27:23 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Peter Hesse" writes: >Location: 4.2.1.2, 2nd para, last sentence >Original Text: "Applications are not required to verify that key identifiers >match when performing certification path validation." >Recommendation: "Applications SHOULD NOT verify that key identifiers match >when performing certification path validation." >Reason: Key identifier matching is not part of determining whether or not a >certification path is valid. I hate to be the guy who always has to ask the blindingly obvious questions, but if they're not required and SHOULD NOT be used, why are they there in the first place? (I know the answer to this question, but I'm interested in seeing what responses are provided). Peter. From owner-ietf-pkix@mail.imc.org Thu May 26 13:17:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14476 for ; Thu, 26 May 2005 13:17:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGMv3v030651; Thu, 26 May 2005 09:22:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGMv52030650; Thu, 26 May 2005 09:22:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QGMu9Y030632 for ; Thu, 26 May 2005 09:22:57 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 13943 invoked by uid 0); 26 May 2005 16:22:31 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.127.10) by woodstock.binhost.com with SMTP; 26 May 2005 16:22:31 -0000 Message-Id: <6.2.1.2.2.20050526122036.06aa4d50@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 26 May 2005 12:22:30 -0400 To: pgut001@cs.auckland.ac.nz From: Russ Housley Subject: Re: [draft-ietf-pkix-sim-04.txt] Cc: ietf-pkix@imc.org In-Reply-To: References: <6.2.1.2.2.20050526095809.05835eb0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter: SFL uses enhanced SNACC, which is freeware and it only supports the 1988 syntax. I do not think it is laziness. However, I am not going to be dragged down that rat hole. Russ At 10:34 AM 5/26/2005, Peter Gutmann wrote: >Russ Housley writes: > > >It is not fair to abuse new authors for following long-standing PKIX and > >S/MIME WG convention. These WGs have chosen to use the 1988 ASN.1 syntax > >because there are free tools that support it. If you have information > about > >freeware tools that support the later syntax, please let us know. > >These WGs have chosen to use the obsolete 1988 ASN.1 syntax because they >couldn't be bothered learning anything newer. The (un)availability of >freeware tools is merely the most convenient red herring available to support >this position. I'n not aware of a single OSS/freeware project that is >hampered by the unavailability of freeware ASN.1 tools (the only project of >this kind that I know of that even uses one is SFL, and that doesn't seem to >have any problems). > >Peter. From owner-ietf-pkix@mail.imc.org Thu May 26 13:31:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15395 for ; Thu, 26 May 2005 13:31:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGenFY033610; Thu, 26 May 2005 09:40:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGenwE033609; Thu, 26 May 2005 09:40:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGemcM033602 for ; Thu, 26 May 2005 09:40:48 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4QGea8e030549; Thu, 26 May 2005 12:40:38 -0400 From: "Santosh Chokhani" To: "'pgut001'" , , , Cc: , , , , , Subject: RE: Comments on / suggested changes for RFC3280bis Date: Thu, 26 May 2005 12:40:31 -0400 Message-ID: <001201c56211$a4c531c0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QGencM033603 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Peter Guttman, The KIDs are there for us to have fun. No just kidding. They are there for performance enhancement during certification path development and should play no role in path validation. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Thursday, May 26, 2005 12:27 PM To: david.cooper@nist.gov; ietf-pkix@imc.org; pmhesse@geminisecurity.com Cc: chokhani@orionsec.com; GSecrest@CORUS.JNJ.com; guy@strategicidentitygroup.com; mcooper@orionsec.com; MRamos8@CORUS.JNJ.com; RGuida@CORUS.JNJ.com; Terry.Zagar@ngc.com Subject: Re: Comments on / suggested changes for RFC3280bis "Peter Hesse" writes: >Location: 4.2.1.2, 2nd para, last sentence >Original Text: "Applications are not required to verify that key >identifiers match when performing certification path validation." >Recommendation: "Applications SHOULD NOT verify that key identifiers >match when performing certification path validation." >Reason: Key identifier matching is not part of determining whether or >not a certification path is valid. I hate to be the guy who always has to ask the blindingly obvious questions, but if they're not required and SHOULD NOT be used, why are they there in the first place? (I know the answer to this question, but I'm interested in seeing what responses are provided). Peter. From owner-ietf-pkix@mail.imc.org Thu May 26 16:02:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02272 for ; Thu, 26 May 2005 16:02:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QItTtb067863; Thu, 26 May 2005 11:55:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QItTqw067861; Thu, 26 May 2005 11:55:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QItRfb067761 for ; Thu, 26 May 2005 11:55:28 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 May 2005 19:55:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Thu, 26 May 2005 19:55:17 +0100 Message-ID: Thread-Topic: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Thread-Index: AcVhmdJGXS/B7joaTFqHyqHHyaiPzQAic0dg From: "Stefan Santesson" To: "Tom Gindin" Cc: "Santosh Chokhani" , , "Julien Stern" X-OriginalArrivalTime: 26 May 2005 18:55:22.0014 (UTC) FILETIME=[77EAABE0:01C56224] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QItSfb067839 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Tom, Just Speaking as implementer, MS CAPI will quit and fail the validation once it detects a loop like this one. This is also true for indirect loops such as if https access to the CRL requires the target cert to be established. Such CDP will also be regarded as invalid. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com] > Sent: den 25 maj 2005 19:22 > To: Stefan Santesson > Cc: Santosh Chokhani; ietf-pkix@imc.org; Julien Stern > Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > Stefan: > > I can't find any loop control text on this subject in 3280 or > 3280-bis. I don't know what a practical validation library would do with > a potential loop like this, and I doubt if anybody who hasn't written such > a library knows either. One of the things it might do is note that the > certificate is already being validated and assume that its validation > result is sufficient. That avoids the loop, at the cost of letting this > certificate through. Being sure that the library will encounter a loop > depends on the library's author interpreting "Obtain and validate the > certification path for the complete CRL issuer" to include calling a > revocation check on each element in the path and not assuming that a bad > certificate already being validated once will be caught elsewhere in the > algorithm. > On a related issue, the certpathbuild I-D may be just as involved > in our discussions as 3280-bis. Its security considerations section on > CRL signer paths is considerably more elaborate than 3280's discussion, > and does not consider that terminating at the same trust anchor is good > enough. > > Tom Gindin > > > > > > > "Stefan Santesson" > 05/25/2005 02:17 PM > > To: Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" > > cc: , "Julien Stern" > > Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > If the substitution would be successful the validation would go into an > infinite loop and fail. > Validation of S's fake CRL requires validation of C's cross certificate > to S which triggers another validation of S's fake CRL and so on. > > I think we added some text against infinite loops but I don't have it > fresh in my memory. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Tom Gindin > > Sent: den 25 maj 2005 04:50 > > To: Santosh Chokhani > > Cc: ietf-pkix@imc.org; 'Julien Stern' > > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > > > > Santosh: > > > > A relatively concrete example would be the following: > > Assume a trust anchor called A, and CA it has issued a cross > > certificate to called C. Further assume that C uses indirect CRL's, > and > > has issued a cross certificate without name constraints to another CA > > called S. Then assume that S goes rogue and creates a CRL signing > > certificate with the same name as C uses for its indirect CRL's (the > key > > pair in that certificate is hereinafter called the "rogue CRL > signer"). > > Further assume that C finds out about this and creates a CRL listing S > as > > revoked, but that S successfully replaces that CRL in the repository > by > > one signed by the rogue CRL signer. > > Does RFC 3280 path validation consider S invalid? If so, > which > > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what > else > > would be likely to cause S to be recognized as invalid? You could > > probably patch any difficulties by adding "if the certificate whose > > revocation is being checked appears in the path, reject it" to > 6.3.3-f. > > > > Tom Gindin > > > > > > > > > > > > > > "Santosh Chokhani" > > 05/24/2005 06:42 PM > > > > To: Tom Gindin/Watson/IBM@IBMUS, > > cc: "'Julien Stern'" > > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > > extension) > > > > > > Tom, > > > > > > I assume you are talking about CRL certification path solution I > proposed > > will not permit the scenario? I still do not see in your case, if the > > Subject CA (cross certified CA) is revoked, you will verify the path > to it > > in the first place. May be I am not understanding your scenario > properly. > > How does the revoked CA gets verified? > > > > > > Julien, > > > > We have defined and proven the solution for how to do this. The > scenario > > you proposed is not something X.509 worries about (A CA that is still > > valid, > > but has gone bad). > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On > > Behalf Of Julien Stern > > Sent: Tuesday, May 24, 2005 3:49 PM > > To: Stefan Santesson > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > > Tom and Julien, > > > > > > Since this is a repetition of the discussion we had before San Diego > > > and I don't want to repeat it here. I'm not saying that this > > > discussion is invalid; it is just directed towards the wrong draft. > > > > Stefan, > > > > I agree with you. Actually, I would tend to believe that a _real_ > > discussion > > would have to take place at some point regarding the overall security > > model > > of CRL validation, but I have absolutely no objection to the AIA, as > soon > > as > > it is made clear that it's only goal is to simplify path building > > implementations, and not to adress security issues. My very humble > take on > > the subject is that Denis and yourself have been arguing on the list > on > > absolutely valid but different matters. > > > > So, I chose not to comment expect for my last mail (and will not any > more) > > about AIA, but I still think that a discusssion regarding revocation > > validation should take place for RFC3280bis, eventually. > > > > Regards, > > > > -- > > Julien Stern > > > > > > > > As Tom pointed out: > > > > this fraudulently issued CRL will probably be validated whether it > > > > contains an AIA or not. > > > > > > This indicates once again that this is not an issue caused by the > use > > > of AIA in CRLs but a generic CRL validation issue that belongs with > > > RFC 3280bis and not with the CRL-AIA draft. > > > > > > Stefan Santesson > > > Program Manager, Standards Liaison > > > Windows Security > > > > > > > > > > -----Original Message----- > > > > From: owner-ietf-pkix@mail.imc.org > > > [mailto:owner-ietf-pkix@mail.imc.org] > > > > On Behalf Of Julien Stern > > > > Sent: den 24 maj 2005 09:39 > > > > To: Tom Gindin > > > > Cc: ietf-pkix@imc.org > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > > > There is one scenario permitted by the "same trust > anchor" > > > rule > > > > > for CRL signers which seems to me to be a serious security hole. > > > Let us > > > > > assume a valid CA which is a direct subordinate of one of the > RP's > > > trust > > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > > usual > > > way, > > > > > and issues cross certificates. After months or years of > > > > > operation, > > > it > > > > > revokes one of its cross certificates because the subject's > > > > > operator > > > has > > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > > Signing certificate with the DN that the superior certificate > has > > > > > been using > > > to > > > > > sign ARL's, a public key which it has newly generated, and > various > > > > > extensions including an SKID. It then issues an updated copy of > > > > > an > > > old > > > > > ARL under the fraudulent CRL signer's certificate and with an > AKID > > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > > into > > > the > > > > > repository where the CRL is expected, this fraudulently issued > CRL > > > will > > > > > probably be validated whether it contains an AIA or not. It > will > > > > > certainly pass the "same trust anchor" condition. > > > > > This scenario, in which a rogue CA issues an ARL > > > > > certifiying > > > > that > > > > > its primary certificate has not been revoked and gets the ARL > > > accepted, > > > > is > > > > > possible under "same trust anchor" but not under "signed by path > > > > member". > > > > > > > > I agree with the validity of this scenario. I believe this is very > > > > close to the issue I attempted to bring on the list a short time > > > > ago. Of course, it assumes the existence of a rogue CA at some > point > > > > in > > > time. > > > > > > > > Note that the CRL could be directly inserted into a "long term" > > > > signature (according to RFC3126 for example). This does not > require > > > > a repository break-in and makes the "attack" even more realistic. > > > > > > > > Regards. > > > > > > > > -- > > > > Julien Stern > > > > > > > > > > > > > > Tom Gindin > > > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > > ----- > > > > > > > > > > > > > > > Tom Gindin > > > > > 05/23/2005 10:46 PM > > > > > > > > > > To: wpolk@nist.gov > > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > > kent@bbn.com, > > > > > stefans@microsoft.com > > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > > Tim: > > > > > > > > > > I should probably have brought this up earlier, but are > we > > > > certain > > > > > that "same trust anchor" is a strong enough check that the CRL > > > signer is > > > > > the one expected by the issuing CA? While I was not in San > Diego > > > when > > > > > this wording was included in the 3280 series, I do not really > > > > > think > > > that > > > > > that check is strong enough. I would suggest instead that the > CRL > > > > > signer's certificate needs to be directly issued by one of the > > > > > CA's > > > in > > > > the > > > > > certification path back to the trust anchor used for the > > > certificate's > > > > > verification, or by that anchor itself, unless people have > > > > > practical experience with CA structures which that rule would > > > > > prohibit. > > > Forcing > > > > the > > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > > by > > > a > > > > > hierarchical superior, so it is IMHO too strict. > > > > > I am personally not sure, FWIW, that a CRL should be > > > permitted > > > > to > > > > > be signed by a second-cousin certificate of the issuer's > > > certificate. > > > > By > > > > > analogy to the use of the terms in families, "sibling" > > > > > certificates > > > > would > > > > > have the same issuer, "first-cousin" certificates would be > issued > > > > > by siblings, and "second-cousin" certificates would be issued by > > > > > first cousins - so they are both three levels down from the same > > > > > trust > > > anchor, > > > > > or from the last common CA in their paths. This issue is not > > > > > newly > > > > caused > > > > > by CRL AIA, since the same issue can arise with CRL's containing > > > only > > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > > wrong) > > > > more > > > > > quickly. > > > > > In any case, nothing more than a note in Security > > > Considerations > > > > > is appropriate in any of our RFC's other than 3280 and its > > > successor. > > > > > > > > > > Tom Gindin > > > > > P.S. - The above views are mine, and not necessarily those of > my > > > > employer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > > 05/10/2005 05:27 PM > > > > > > > > > > To: ietf-pkix@imc.org > > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > > housley@vigilsec.com > > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > > specification "Internet X.509 Public Key Infrastructure: > Authority > > > > > Information > > > Access > > > > > CRL > > > > > Extension". While some issues raised in the working group are > > > > unresolved, > > > > > > > > > > the editors believe that rough consensus supports the current > > > > > specification. > > > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > > will > > > not > > > > > close before May 24. > > > > > > > > > > Thanks, > > > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Thu May 26 16:19:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08359 for ; Thu, 26 May 2005 16:19:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJGIYx070182; Thu, 26 May 2005 12:16:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJGI3K070181; Thu, 26 May 2005 12:16:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJGIQF070175 for ; Thu, 26 May 2005 12:16:18 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.3]) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DbNpv-00051y-6Q; Thu, 26 May 2005 15:16:07 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Subject:Cc:Content-Type; b=NikbAVUEYzDDoXbX40o4ddoDYMSPePGBd6Xnyrqh7S2qdVN357chAaWLno109VPA; Mime-Version: 1.0 Message-Id: In-Reply-To: <4295D3EB.5010800@cs.tcd.ie> References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> Date: Thu, 26 May 2005 12:15:54 -0700 To: Stephen Farrell , Denis Pinkas From: Hoyt L Kesterson II Subject: Re: 3280bis: key usage (13) Cc: pkix Content-Type: text/plain; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d4781412bc4b56a17d4768d818cffbd49a3004b207c7cc29a54b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephen I am somewhat dismayed at your reaction to the new text in X.509. I am not going to argue with you here (maybe in a bar the next time we run into each other). However, I do want to mention several points. 1) I initiated the change in text because of the various interpretations by implementors that were resulting in non-interoperable implementations. It was a conversation with a PKIXer at a RSA conference a few years ago that caused me to articulate a private concern. 2) The legal community was very confused. There was even a paper castigating the standard developers for mandating that one could not repudiate an action. 3) There were several meetings held where there was significant participation by people in the IETF PKIX group (as well as lawyers). All agreed there was a problem with the published text. Denis and I argued long and hard over wording but we didn't disagree on the need for new text and its general intent. 4) Russ was concerned that change would cause a problem with existing IETF standards and was not too happy with a change to the name of the bit. That's why I put the line in that you referenced. However, that was to grandfather existing text, not to allow new text to continue using the old term and definitions. 5) It is the definition that is important. I recommend that any new text align with the definition in the approved technical corrigenda against the 4th edition and in the upcoming 5th edition. hoyt At 14:49 +0100 5/26/05, Stephen Farrell wrote: >Denis, > > > Please align with the the ISO-ITU text. > >Do you mean we should rename the bits and include the >other new x.509 text? The design team were against >doing that. > >Is there any (good) reason other than alignment to >make such a change? > >Personally, I find the new x.509 text worse, although >it does say: "Note that it is not incorrect to refer to >this keyUsage bit using the identifier nonRepudiation." >So I can argue that we are aligned, just not identical. > >But of course, I'm from the non-repudiation is non-sense >camp so I may not be the best judge. > >Stephen. > >PS: A quibble: > >> The new text in X.509 aligns with the text in RFC 3280. No changes >> are required to 3280bis. A comment has been added to the ASN.1 for >> KeyUsage stating that "recent editions of X.509 have renamed >> [the nonRepudiation] bit to contentCommitment" >> >> This statement is untrue. > >The paragraph to which I assume you refer contains 3 >statements - it'd be easier to close these threads if >you were more precise. (I think I got what you want >by the end of the mail though...) > >PPS: "This statement is untrue." > Are you from Crete after all? :-) > > > > >Denis Pinkas wrote: > >> >>To the list, >> >>The disposition of comments states: >> >> 13) The descriptions of the meanings of the digitalSignature and >> nonRepudiation bits of keyUsage may need to be adjusted based >> on the work in X.509 >> >> The new text in X.509 aligns with the text in RFC 3280. No changes >> are required to 3280bis. A comment has been added to the ASN.1 for >> KeyUsage stating that "recent editions of X.509 have renamed >> [the nonRepudiation] bit to contentCommitment" >> >>This statement is untrue. >> >>The text from X.509 has been published in Corrigendum 3 (04/2004) >>on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >> >>ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >> >>An extract from this text is copied below: >> >>a) digitalSignature: for verifying digital signatures that are used >> with an entity authentication service, a data origin authentication >> service or/and an integrity service; >> >>b) contentCommitment: for verifying digital signatures which are intended >> to signal that the signer is committing to the content being signed. >> The type of commitment the certificate can be used to support may be >> further constrained by the CA, e.g. through a certificate policy. >> The precise type of commitment of the signer e.g. "reviewed and >> approved" or "with the intent to be bound", may be signalled by the >> content being signed, e.g. the signed document itself or some additional >> signed information. >> >> Since a content commitment signing is considered to be a digitally signed >> transaction, the digitalSignature bit need not be set in the certificate. >> If it is set, it does not affect the level of commitment the signer has >> endowed in the signed content. >> >> Note that it is not incorrect to refer to this keyUsage bit using the >> identifier nonRepudiation. However, the use of this identifier has been >> deprecated. Regardless of the identifier used, the semantics of this bit >> are as specified in this Directory Specification. >> >>The text from 3280 is copied below: >> >> The digitalSignature bit is asserted when the subject public key >> is used with a digital signature mechanism to support security >> services other than certificate signing (bit 5), or CRL signing >> (bit 6). Digital signature mechanisms are often used for entity >> authentication and data origin authentication with integrity. >> >> The nonRepudiation bit is asserted when the subject public key is >> used to verify digital signatures used to provide a non- >> repudiation service which protects against the signing entity >> falsely denying some action, excluding certificate or CRL signing. >> In the case of later conflict, a reliable third party may >> determine the authenticity of the signed data. >> >> Further distinctions between the digitalSignature and >> nonRepudiation bits may be provided in specific certificate >> policies. >> >>The text from 3280bis does not align with the ISO-ITU text. >>Please align with the the ISO-ITU text. >> >>Denis From owner-ietf-pkix@mail.imc.org Thu May 26 23:50:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12027 for ; Thu, 26 May 2005 23:50:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R2tB6X088348; Thu, 26 May 2005 19:55:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4R2tBYa088347; Thu, 26 May 2005 19:55:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R2t9Eb088340 for ; Thu, 26 May 2005 19:55:09 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4R2t1qY019770 for ; Thu, 26 May 2005 22:55:01 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4R2t1bY154244 for ; Thu, 26 May 2005 22:55:01 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4R2t1Hq015807 for ; Thu, 26 May 2005 22:55:01 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4R2t18X015801; Thu, 26 May 2005 22:55:01 -0400 In-Reply-To: <00a001c561ea$2c8b37d0$aa02a8c0@hq.orionsec.com> To: "Santosh Chokhani" Cc: ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Thu, 26 May 2005 22:54:56 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/26/2005 22:55:00, Serialize complete at 05/26/2005 22:55:01, Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/26/2005 22:55:01 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh: That is indeed the scenario. I'm glad to hear that both your library and Stefan's do reject paths like this. I didn't say that no one does or understands these things, just that I doubted that people who hadn't implemented a library did (you ran into an infinite loop in this case while testing, which suggests that it hadn't been fully understood before that). If any implementor interpreted 6.1.3-a-3's "not revoked and not on hold status" to not reject cases where his code could not determine the status, they could easily accept this path. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/26/2005 07:57 AM To: cc: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, BTW, we may be putting Peter Guttman and rest of the group to sleep again, which may not be all bad. You need to provide a clear streamlined scenario. From what I discern, you are saying the following. Root R --> C C --> C1 as CRL issuer & C --> S and C asserts in S C1. C1 issues CRL. S goes rouge. C instructs C1 to put S on CRLgood. S --> C1. Now, the new C1 can issue a CRLbad without S on it. In order to verify signature on CRLbad, you need the path R --> C --> S --> C1. But, note that in order to verify signature on C --> S either you will find the correct path and CRL (R --> C --> C1 and CRLgood) or you will have circularity since C-->S require C1 CRL. There is no sense in having this e-mail discussion unless you lay out the scenario precisely as above as to what the various certification paths are. So far, when I fill in the gaps, all I see is circularity issues or what Stefan calls infinite loops. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Wednesday, May 25, 2005 10:22 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: I thought that I had made that particular issue clear. The indirect CRL being retrieved governs C's certificates and its issuer name (call it C1) is supposed to belong to C. Indeed, C has issued a CRL signing certificate with subject name C1. However, S has created another CRL signing certificate with this same subject name and has created a CRL with that key pair. C did not create any circularity. The original certificate for C1 was issued by C and the corresponding private key belongs to an entity under C's control, while the new certificate for C1 was issued by S and the corresponding private key belongs to a malicious subsystem inside S. While certificates are issued to entities, relying parties know the name and the chain but not the entity. No relevant CRL is issued by S. I'm sure that your objection to ' looking at CRL issued by C' actually meant 'issued by S', because you normally verify certificates by looking at CRL's issued by the certificate issuer or its delegate. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/25/2005 08:58 AM To: cc: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, It is not clear from your example who the indirect CRL issuer is and what role the "indirect CRL" plays in the attack. If S is the indirect CRL issuer, C should be smart enough to not create circularity (a good toolkit will not verify path when C issues a certificate to S and points to S as the indirect CRL issuer since it causes circularity and chicken and egg problem). That scenario can be easily rectified within current standard by C not declaring S as the indirect CRL issuer for certificate issued to S. C can declare itself in the CDP or some other issuer. I suspect you do not mean this. Your example may be simpler. To me the attack is still not plausible. Your scenario is not detailed enough to illustrate an attack. It does not seem that there is a way to validate the certificate issued to C by S without looking at CRL issued by C, resulting in circularity, which relying party clients should not accept. (Note that my November presentation to IETF in DC covered the circularity issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to the CRL certification path) -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, May 25, 2005 7:50 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; 'Julien Stern' Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > From owner-ietf-pkix@mail.imc.org Fri May 27 07:04:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00069 for ; Fri, 27 May 2005 07:04:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R9sM3M073979; Fri, 27 May 2005 02:54:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4R9sM9s073977; Fri, 27 May 2005 02:54:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R9sJLK073925 for ; Fri, 27 May 2005 02:54:20 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 075B214C063; Fri, 27 May 2005 10:54:09 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A02C23D287F; Fri, 27 May 2005 10:54:08 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 7D23E14C047; Fri, 27 May 2005 10:54:08 +0100 (IST) Message-ID: <4296EF39.4050202@cs.tcd.ie> Date: Fri, 27 May 2005 10:58:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hoyt L Kesterson II Cc: Denis Pinkas , pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.733) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A12C23D287F Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Hoyt, Hoyt L Kesterson II wrote: > Stephen > > I am somewhat dismayed at your reaction to the new text in X.509. I'm sorry about that, but I guess I'm just fed up with the NR bit, though I can understand how people who've worked hard to try fix it might be dismayed. (BTW: I once suggested that CAs MUST set this bit randomly since that was the only way I could see to kill it off properly. If you can get that into X.509 then I'd be happy for 3280bis to align:-) > I am not going to argue with you here (maybe in a bar the next time > we run into each other). Good idea! > However, I do want to mention several points. > > 1) I initiated the change in text because of the various interpretations > by implementors that were resulting in non-interoperable > implementations. It was a conversation with a PKIXer at a RSA > conference a few years ago that caused me to articulate a private > concern. I agree that everything connected with this bit has been confused and remains so. > 2) The legal community was very confused. There was even a > paper castigating the standard developers for mandating that > one could not repudiate an action. Maybe the mistake was defining a bit that laywers care about? > 3) There were several meetings held where there was significant > participation by people in the IETF PKIX group (as well as > lawyers). All agreed there was a problem with the published text. > Denis and I argued long and hard over wording but we didn't > disagree on the need for new text and its general intent. Fair enough. > 4) Russ was concerned that change would cause a problem > with existing IETF standards and was not too happy with a > change to the name of the bit. That's why I put the line > in that you referenced. However, that was to grandfather > existing text, not to allow new text to continue using > the old term and definitions. Ok. Here's the real reason not to change: Many people use ASN.1 compilers which means that names from the ASN.1 module end up being directly used in higher layer code. Changing the name causes that code not to compile. I'd say that there's quite a lot of 3280 code in the world at this stage. So, if the semantics isn't supposed to have changed (and I assume that is meant to be the case) then this cost just doesn't seem worthwhile. > 5) It is the definition that is important. I recommend > that any new text align with the definition in the approved > technical corrigenda against the 4th edition and in > the upcoming 5th edition. While I'd rather not see any more text added on this, (there's been way too much already) I wouldn't have a big issue with trying to help a reader make sense of the fact that 3280bis and x.509 name this bit differently. However text like the sentence below is IMO almost certain to cause even more confusion: The precise type of commitment of the signer e.g. "reviewed and approved" or "with the intent to be bound", may be signalled by the content being signed, e.g. the signed document itself or some additional signed information. That sounds like the sole purpose of the CC-bit is as a flag to indicate when some other bits somewhere else tell you what the CC-bit means. So in the absence of some better text I think that 3280bis is better off just saying "NR a.k.a. CC" as it currently does. Regards, Stephen. > > At 14:49 +0100 5/26/05, Stephen Farrell wrote: > >>Denis, >> >> >>>Please align with the the ISO-ITU text. >> >>Do you mean we should rename the bits and include the >>other new x.509 text? The design team were against >>doing that. >> >>Is there any (good) reason other than alignment to >>make such a change? >> >>Personally, I find the new x.509 text worse, although >>it does say: "Note that it is not incorrect to refer to >>this keyUsage bit using the identifier nonRepudiation." >>So I can argue that we are aligned, just not identical. >> >>But of course, I'm from the non-repudiation is non-sense >>camp so I may not be the best judge. >> >>Stephen. >> >>PS: A quibble: >> >> >>> The new text in X.509 aligns with the text in RFC 3280. No changes >>> are required to 3280bis. A comment has been added to the ASN.1 for >>> KeyUsage stating that "recent editions of X.509 have renamed >>> [the nonRepudiation] bit to contentCommitment" >>> >>>This statement is untrue. >> >>The paragraph to which I assume you refer contains 3 >>statements - it'd be easier to close these threads if >>you were more precise. (I think I got what you want >>by the end of the mail though...) >> >>PPS: "This statement is untrue." >> Are you from Crete after all? :-) >> >> >> >> >>Denis Pinkas wrote: >> >> >>>To the list, >>> >>>The disposition of comments states: >>> >>>13) The descriptions of the meanings of the digitalSignature and >>> nonRepudiation bits of keyUsage may need to be adjusted based >>> on the work in X.509 >>> >>> The new text in X.509 aligns with the text in RFC 3280. No changes >>> are required to 3280bis. A comment has been added to the ASN.1 for >>> KeyUsage stating that "recent editions of X.509 have renamed >>> [the nonRepudiation] bit to contentCommitment" >>> >>>This statement is untrue. >>> >>>The text from X.509 has been published in Corrigendum 3 (04/2004) >>>on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>> >>>ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>> >>>An extract from this text is copied below: >>> >>>a) digitalSignature: for verifying digital signatures that are used >>> with an entity authentication service, a data origin authentication >>> service or/and an integrity service; >>> >>>b) contentCommitment: for verifying digital signatures which are intended >>> to signal that the signer is committing to the content being signed. >>> The type of commitment the certificate can be used to support may be >>> further constrained by the CA, e.g. through a certificate policy. >>> The precise type of commitment of the signer e.g. "reviewed and >>> approved" or "with the intent to be bound", may be signalled by the >>> content being signed, e.g. the signed document itself or some additional >>> signed information. >>> >>> Since a content commitment signing is considered to be a digitally signed >>> transaction, the digitalSignature bit need not be set in the certificate. >>> If it is set, it does not affect the level of commitment the signer has >>> endowed in the signed content. >>> >>> Note that it is not incorrect to refer to this keyUsage bit using the >>> identifier nonRepudiation. However, the use of this identifier has been >>> deprecated. Regardless of the identifier used, the semantics of this bit >>> are as specified in this Directory Specification. >>> >>>The text from 3280 is copied below: >>> >>> The digitalSignature bit is asserted when the subject public key >>> is used with a digital signature mechanism to support security >>> services other than certificate signing (bit 5), or CRL signing >>> (bit 6). Digital signature mechanisms are often used for entity >>> authentication and data origin authentication with integrity. >>> >>> The nonRepudiation bit is asserted when the subject public key is >>> used to verify digital signatures used to provide a non- >>> repudiation service which protects against the signing entity >>> falsely denying some action, excluding certificate or CRL signing. >>> In the case of later conflict, a reliable third party may >>> determine the authenticity of the signed data. >>> >>> Further distinctions between the digitalSignature and >>> nonRepudiation bits may be provided in specific certificate >>> policies. >>> >>>The text from 3280bis does not align with the ISO-ITU text. >>>Please align with the the ISO-ITU text. >>> >>>Denis > > > From owner-ietf-pkix@mail.imc.org Fri May 27 07:23:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01077 for ; Fri, 27 May 2005 07:23:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RASCgt086751; Fri, 27 May 2005 03:28:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RASCZW086750; Fri, 27 May 2005 03:28:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RASBD2086703 for ; Fri, 27 May 2005 03:28:11 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA70810; Fri, 27 May 2005 12:43:13 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052712280030:1918 ; Fri, 27 May 2005 12:28:00 +0200 Message-ID: <4296F66E.3020406@bull.net> Date: Fri, 27 May 2005 12:29:02 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stephen Farrell CC: Hoyt L Kesterson II , pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/05/2005 12:28:00, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/05/2005 12:28:02, Serialize complete at 27/05/2005 12:28:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stephen, I agree with everything Hoyt said on bit 1. However, there are two sides for this coin : bit 0 and bit 1. Both are again copied below: ISO Corrigendum: a) digitalSignature: for verifying digital signatures that are used with an entity authentication service, a data origin authentication service or/and an integrity service; 3280bis: The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. The current text of 3280bis for bit 0 (ds) is incompatible with the ISO Corrigendum. As Hoyt already said, any new text should align with the definition in the approved technical corrigenda against the 4th edition and in the upcoming 5th edition. Denis > Hi Hoyt, > > Hoyt L Kesterson II wrote: > >> Stephen >> >> I am somewhat dismayed at your reaction to the new text in X.509. > > > I'm sorry about that, but I guess I'm just fed up with the > NR bit, though I can understand how people who've worked > hard to try fix it might be dismayed. > > (BTW: I once suggested that CAs MUST set this bit randomly > since that was the only way I could see to kill it off > properly. If you can get that into X.509 then I'd be happy > for 3280bis to align:-) > > > I am not going to argue with you here (maybe in a bar the next time > > we run into each other). > > Good idea! > >> However, I do want to mention several points. >> >> 1) I initiated the change in text because of the various interpretations > > > by implementors that were resulting in non-interoperable > > implementations. It was a conversation with a PKIXer at a RSA > > conference a few years ago that caused me to articulate a private > > concern. > > I agree that everything connected with this bit has been > confused and remains so. > >> 2) The legal community was very confused. There was even a > > > paper castigating the standard developers for mandating that > > one could not repudiate an action. > > Maybe the mistake was defining a bit that laywers care about? > >> 3) There were several meetings held where there was significant > > > participation by people in the IETF PKIX group (as well as > > lawyers). All agreed there was a problem with the published text. > > Denis and I argued long and hard over wording but we didn't > > disagree on the need for new text and its general intent. > > Fair enough. > >> 4) Russ was concerned that change would cause a problem > > > with existing IETF standards and was not too happy with a > > change to the name of the bit. That's why I put the line > > in that you referenced. However, that was to grandfather > > existing text, not to allow new text to continue using > > the old term and definitions. > > Ok. Here's the real reason not to change: Many people use > ASN.1 compilers which means that names from the ASN.1 > module end up being directly used in higher layer code. > Changing the name causes that code not to compile. I'd > say that there's quite a lot of 3280 code in the world > at this stage. So, if the semantics isn't supposed to > have changed (and I assume that is meant to be the > case) then this cost just doesn't seem worthwhile. > >> 5) It is the definition that is important. I recommend > > > that any new text align with the definition in the approved > > technical corrigenda against the 4th edition and in > > the upcoming 5th edition. > > While I'd rather not see any more text added on this, > (there's been way too much already) I wouldn't have a big > issue with trying to help a reader make sense of the > fact that 3280bis and x.509 name this bit differently. > > However text like the sentence below is IMO almost > certain to cause even more confusion: > > The precise type of commitment of the signer e.g. "reviewed > and approved" or "with the intent to be bound", may be > signalled by the content being signed, e.g. the signed > document itself or some additional signed information. > > That sounds like the sole purpose of the CC-bit is as > a flag to indicate when some other bits somewhere else > tell you what the CC-bit means. > > So in the absence of some better text I think that 3280bis > is better off just saying "NR a.k.a. CC" as it currently > does. > > Regards, > Stephen. > >> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote: >> >>> Denis, >>> >>> >>>> Please align with the the ISO-ITU text. >>> >>> >>> Do you mean we should rename the bits and include the >>> other new x.509 text? The design team were against >>> doing that. >>> >>> Is there any (good) reason other than alignment to >>> make such a change? >>> >>> Personally, I find the new x.509 text worse, although >>> it does say: "Note that it is not incorrect to refer to >>> this keyUsage bit using the identifier nonRepudiation." >>> So I can argue that we are aligned, just not identical. >>> >>> But of course, I'm from the non-repudiation is non-sense >>> camp so I may not be the best judge. >>> >>> Stephen. >>> >>> PS: A quibble: >>> >>> >>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>> KeyUsage stating that "recent editions of X.509 have renamed >>>> [the nonRepudiation] bit to contentCommitment" >>>> >>>> This statement is untrue. >>> >>> >>> The paragraph to which I assume you refer contains 3 >>> statements - it'd be easier to close these threads if >>> you were more precise. (I think I got what you want >>> by the end of the mail though...) >>> >>> PPS: "This statement is untrue." >>> Are you from Crete after all? :-) >>> >>> >>> >>> >>> Denis Pinkas wrote: >>> >>> >>>> To the list, >>>> >>>> The disposition of comments states: >>>> >>>> 13) The descriptions of the meanings of the digitalSignature and >>>> nonRepudiation bits of keyUsage may need to be adjusted based >>>> on the work in X.509 >>>> >>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>> KeyUsage stating that "recent editions of X.509 have renamed >>>> [the nonRepudiation] bit to contentCommitment" >>>> >>>> This statement is untrue. >>>> >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>>> >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>>> >>>> An extract from this text is copied below: >>>> >>>> a) digitalSignature: for verifying digital signatures that are used >>>> with an entity authentication service, a data origin authentication >>>> service or/and an integrity service; >>>> >>>> b) contentCommitment: for verifying digital signatures which are >>>> intended >>>> to signal that the signer is committing to the content being signed. >>>> The type of commitment the certificate can be used to support may be >>>> further constrained by the CA, e.g. through a certificate policy. >>>> The precise type of commitment of the signer e.g. "reviewed and >>>> approved" or "with the intent to be bound", may be signalled by the >>>> content being signed, e.g. the signed document itself or some >>>> additional >>>> signed information. >>>> >>>> Since a content commitment signing is considered to be a digitally >>>> signed >>>> transaction, the digitalSignature bit need not be set in the >>>> certificate. >>>> If it is set, it does not affect the level of commitment the signer >>>> has >>>> endowed in the signed content. >>>> >>>> Note that it is not incorrect to refer to this keyUsage bit using the >>>> identifier nonRepudiation. However, the use of this identifier has >>>> been >>>> deprecated. Regardless of the identifier used, the semantics of >>>> this bit >>>> are as specified in this Directory Specification. >>>> >>>> The text from 3280 is copied below: >>>> >>>> The digitalSignature bit is asserted when the subject public key >>>> is used with a digital signature mechanism to support security >>>> services other than certificate signing (bit 5), or CRL signing >>>> (bit 6). Digital signature mechanisms are often used for entity >>>> authentication and data origin authentication with integrity. >>>> >>>> The nonRepudiation bit is asserted when the subject public key is >>>> used to verify digital signatures used to provide a non- >>>> repudiation service which protects against the signing entity >>>> falsely denying some action, excluding certificate or CRL signing. >>>> In the case of later conflict, a reliable third party may >>>> determine the authenticity of the signed data. >>>> >>>> Further distinctions between the digitalSignature and >>>> nonRepudiation bits may be provided in specific certificate >>>> policies. >>>> >>>> The text from 3280bis does not align with the ISO-ITU text. >>>> Please align with the the ISO-ITU text. >>>> >>>> Denis >>> >> >> >> > > From owner-ietf-pkix@mail.imc.org Fri May 27 09:10:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09088 for ; Fri, 27 May 2005 09:10:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RC6L8s038480; Fri, 27 May 2005 05:06:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RC6LYb038478; Fri, 27 May 2005 05:06:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RC6Gso038396 for ; Fri, 27 May 2005 05:06:17 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 13:06:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 13:06:07 +0100 Message-ID: Thread-Topic: 3280bis: key usage (13) Thread-Index: AcVirx3GaexNZnC4Qoi6SQuzG1QlLQAA1h7A From: "Stefan Santesson" To: "Denis Pinkas" , "Stephen Farrell" Cc: "Hoyt L Kesterson II" , "pkix" X-OriginalArrivalTime: 27 May 2005 12:06:11.0318 (UTC) FILETIME=[78F98160:01C562B4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4RC6Hso038443 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Speaking as implementer and not design team member, I can live with both texts since they allow me to do the same thing. It allows my low level application to add a digital signature supported by the digital signature bit, where the intention of that application is to add integrity and origin authentication, while the use of the signature in practice (higher layers) ends up being used as evidence of some kind of commitment. Example. An e-mail application adds an arbitrary signature supported by the DS bit, while the body of the text reads "Through the digital signature on this e-mail I commit to....). This is now a perfectly valid scenario according to both texts. The real defect that was fixed was that the digital signature bit said that it was for purposes "other" than NR. That is now gone in both standards. I agree to Stephen's rationale to keep the name nonRepudiation. It is not worth the cost to change the name. Stephen's point here was missing in the X.509 discussions of a name change. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 27 maj 2005 12:29 > To: Stephen Farrell > Cc: Hoyt L Kesterson II; pkix > Subject: Re: 3280bis: key usage (13) > > > Stephen, > > I agree with everything Hoyt said on bit 1. > > However, there are two sides for this coin : bit 0 and bit 1. > > Both are again copied below: > > ISO Corrigendum: > > a) digitalSignature: for verifying digital signatures that are used > with an entity authentication service, a data origin > authentication > service or/and an integrity service; > > 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > The current text of 3280bis for bit 0 (ds) is incompatible with the ISO > Corrigendum. > > As Hoyt already said, any new text should align with the definition in the > approved technical corrigenda against the 4th edition and in the upcoming > 5th edition. > > Denis > > > Hi Hoyt, > > > > Hoyt L Kesterson II wrote: > > > >> Stephen > >> > >> I am somewhat dismayed at your reaction to the new text in X.509. > > > > > > I'm sorry about that, but I guess I'm just fed up with the > > NR bit, though I can understand how people who've worked > > hard to try fix it might be dismayed. > > > > (BTW: I once suggested that CAs MUST set this bit randomly > > since that was the only way I could see to kill it off > > properly. If you can get that into X.509 then I'd be happy > > for 3280bis to align:-) > > > > > I am not going to argue with you here (maybe in a bar the next time > > > we run into each other). > > > > Good idea! > > > >> However, I do want to mention several points. > >> > >> 1) I initiated the change in text because of the various > interpretations > > > > > by implementors that were resulting in non-interoperable > > > implementations. It was a conversation with a PKIXer at a RSA > > > conference a few years ago that caused me to articulate a private > > > concern. > > > > I agree that everything connected with this bit has been > > confused and remains so. > > > >> 2) The legal community was very confused. There was even a > > > > > paper castigating the standard developers for mandating that > > > one could not repudiate an action. > > > > Maybe the mistake was defining a bit that laywers care about? > > > >> 3) There were several meetings held where there was significant > > > > > participation by people in the IETF PKIX group (as well as > > > lawyers). All agreed there was a problem with the published text. > > > Denis and I argued long and hard over wording but we didn't > > > disagree on the need for new text and its general intent. > > > > Fair enough. > > > >> 4) Russ was concerned that change would cause a problem > > > > > with existing IETF standards and was not too happy with a > > > change to the name of the bit. That's why I put the line > > > in that you referenced. However, that was to grandfather > > > existing text, not to allow new text to continue using > > > the old term and definitions. > > > > Ok. Here's the real reason not to change: Many people use > > ASN.1 compilers which means that names from the ASN.1 > > module end up being directly used in higher layer code. > > Changing the name causes that code not to compile. I'd > > say that there's quite a lot of 3280 code in the world > > at this stage. So, if the semantics isn't supposed to > > have changed (and I assume that is meant to be the > > case) then this cost just doesn't seem worthwhile. > > > >> 5) It is the definition that is important. I recommend > > > > > that any new text align with the definition in the approved > > > technical corrigenda against the 4th edition and in > > > the upcoming 5th edition. > > > > While I'd rather not see any more text added on this, > > (there's been way too much already) I wouldn't have a big > > issue with trying to help a reader make sense of the > > fact that 3280bis and x.509 name this bit differently. > > > > However text like the sentence below is IMO almost > > certain to cause even more confusion: > > > > The precise type of commitment of the signer e.g. "reviewed > > and approved" or "with the intent to be bound", may be > > signalled by the content being signed, e.g. the signed > > document itself or some additional signed information. > > > > That sounds like the sole purpose of the CC-bit is as > > a flag to indicate when some other bits somewhere else > > tell you what the CC-bit means. > > > > So in the absence of some better text I think that 3280bis > > is better off just saying "NR a.k.a. CC" as it currently > > does. > > > > Regards, > > Stephen. > > > >> > >> At 14:49 +0100 5/26/05, Stephen Farrell wrote: > >> > >>> Denis, > >>> > >>> > >>>> Please align with the the ISO-ITU text. > >>> > >>> > >>> Do you mean we should rename the bits and include the > >>> other new x.509 text? The design team were against > >>> doing that. > >>> > >>> Is there any (good) reason other than alignment to > >>> make such a change? > >>> > >>> Personally, I find the new x.509 text worse, although > >>> it does say: "Note that it is not incorrect to refer to > >>> this keyUsage bit using the identifier nonRepudiation." > >>> So I can argue that we are aligned, just not identical. > >>> > >>> But of course, I'm from the non-repudiation is non-sense > >>> camp so I may not be the best judge. > >>> > >>> Stephen. > >>> > >>> PS: A quibble: > >>> > >>> > >>>> The new text in X.509 aligns with the text in RFC 3280. No changes > >>>> are required to 3280bis. A comment has been added to the ASN.1 for > >>>> KeyUsage stating that "recent editions of X.509 have renamed > >>>> [the nonRepudiation] bit to contentCommitment" > >>>> > >>>> This statement is untrue. > >>> > >>> > >>> The paragraph to which I assume you refer contains 3 > >>> statements - it'd be easier to close these threads if > >>> you were more precise. (I think I got what you want > >>> by the end of the mail though...) > >>> > >>> PPS: "This statement is untrue." > >>> Are you from Crete after all? :-) > >>> > >>> > >>> > >>> > >>> Denis Pinkas wrote: > >>> > >>> > >>>> To the list, > >>>> > >>>> The disposition of comments states: > >>>> > >>>> 13) The descriptions of the meanings of the digitalSignature and > >>>> nonRepudiation bits of keyUsage may need to be adjusted based > >>>> on the work in X.509 > >>>> > >>>> The new text in X.509 aligns with the text in RFC 3280. No changes > >>>> are required to 3280bis. A comment has been added to the ASN.1 for > >>>> KeyUsage stating that "recent editions of X.509 have renamed > >>>> [the nonRepudiation] bit to contentCommitment" > >>>> > >>>> This statement is untrue. > >>>> > >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) > >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called > >>>> > >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). > >>>> > >>>> An extract from this text is copied below: > >>>> > >>>> a) digitalSignature: for verifying digital signatures that are used > >>>> with an entity authentication service, a data origin authentication > >>>> service or/and an integrity service; > >>>> > >>>> b) contentCommitment: for verifying digital signatures which are > >>>> intended > >>>> to signal that the signer is committing to the content being signed. > >>>> The type of commitment the certificate can be used to support may be > >>>> further constrained by the CA, e.g. through a certificate policy. > >>>> The precise type of commitment of the signer e.g. "reviewed and > >>>> approved" or "with the intent to be bound", may be signalled by the > >>>> content being signed, e.g. the signed document itself or some > >>>> additional > >>>> signed information. > >>>> > >>>> Since a content commitment signing is considered to be a digitally > >>>> signed > >>>> transaction, the digitalSignature bit need not be set in the > >>>> certificate. > >>>> If it is set, it does not affect the level of commitment the signer > >>>> has > >>>> endowed in the signed content. > >>>> > >>>> Note that it is not incorrect to refer to this keyUsage bit using > the > >>>> identifier nonRepudiation. However, the use of this identifier has > >>>> been > >>>> deprecated. Regardless of the identifier used, the semantics of > >>>> this bit > >>>> are as specified in this Directory Specification. > >>>> > >>>> The text from 3280 is copied below: > >>>> > >>>> The digitalSignature bit is asserted when the subject public key > >>>> is used with a digital signature mechanism to support security > >>>> services other than certificate signing (bit 5), or CRL signing > >>>> (bit 6). Digital signature mechanisms are often used for entity > >>>> authentication and data origin authentication with integrity. > >>>> > >>>> The nonRepudiation bit is asserted when the subject public key is > >>>> used to verify digital signatures used to provide a non- > >>>> repudiation service which protects against the signing entity > >>>> falsely denying some action, excluding certificate or CRL > signing. > >>>> In the case of later conflict, a reliable third party may > >>>> determine the authenticity of the signed data. > >>>> > >>>> Further distinctions between the digitalSignature and > >>>> nonRepudiation bits may be provided in specific certificate > >>>> policies. > >>>> > >>>> The text from 3280bis does not align with the ISO-ITU text. > >>>> Please align with the the ISO-ITU text. > >>>> > >>>> Denis > >>> > >> > >> > >> > > > > > From owner-ietf-pkix@mail.imc.org Fri May 27 09:11:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09145 for ; Fri, 27 May 2005 09:11:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCIj3r044234; Fri, 27 May 2005 05:18:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RCIjSa044233; Fri, 27 May 2005 05:18:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCIiGx044135 for ; Fri, 27 May 2005 05:18:44 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 5B31514C042; Fri, 27 May 2005 13:18:36 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A063603A50D; Fri, 27 May 2005 13:18:36 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 046EA14C042; Fri, 27 May 2005 13:18:35 +0100 (IST) Message-ID: <42971110.5040008@cs.tcd.ie> Date: Fri, 27 May 2005 13:22:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> <4296F66E.3020406@bull.net> In-Reply-To: <4296F66E.3020406@bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.733) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A163603A50D Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Denis, I've no problem with aligning the DS bit text although I wouldn't say that they're incompatible actually. I like the way 3280 says the DS isn't for certs or CRLs which ISO doesn't seem to include. Would you like to propose an aligned paragraph? I oppose inclusion of new NR/CC text and the name change. Stephen. Denis Pinkas wrote: > Stephen, > > I agree with everything Hoyt said on bit 1. > > However, there are two sides for this coin : bit 0 and bit 1. > > Both are again copied below: > > ISO Corrigendum: > > a) digitalSignature: for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service; > > 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > The current text of 3280bis for bit 0 (ds) is incompatible with the ISO > Corrigendum. > > As Hoyt already said, any new text should align with the definition in > the approved technical corrigenda against the 4th edition and in the > upcoming 5th edition. > > Denis > >> Hi Hoyt, >> >> Hoyt L Kesterson II wrote: >> >>> Stephen >>> >>> I am somewhat dismayed at your reaction to the new text in X.509. >> >> >> >> I'm sorry about that, but I guess I'm just fed up with the >> NR bit, though I can understand how people who've worked >> hard to try fix it might be dismayed. >> >> (BTW: I once suggested that CAs MUST set this bit randomly >> since that was the only way I could see to kill it off >> properly. If you can get that into X.509 then I'd be happy >> for 3280bis to align:-) >> >> > I am not going to argue with you here (maybe in a bar the next time >> > we run into each other). >> >> Good idea! >> >>> However, I do want to mention several points. >>> >>> 1) I initiated the change in text because of the various interpretations >> >> >> > by implementors that were resulting in non-interoperable >> > implementations. It was a conversation with a PKIXer at a RSA >> > conference a few years ago that caused me to articulate a private >> > concern. >> >> I agree that everything connected with this bit has been >> confused and remains so. >> >>> 2) The legal community was very confused. There was even a >> >> >> > paper castigating the standard developers for mandating that >> > one could not repudiate an action. >> >> Maybe the mistake was defining a bit that laywers care about? >> >>> 3) There were several meetings held where there was significant >> >> >> > participation by people in the IETF PKIX group (as well as >> > lawyers). All agreed there was a problem with the published text. >> > Denis and I argued long and hard over wording but we didn't >> > disagree on the need for new text and its general intent. >> >> Fair enough. >> >>> 4) Russ was concerned that change would cause a problem >> >> >> > with existing IETF standards and was not too happy with a >> > change to the name of the bit. That's why I put the line >> > in that you referenced. However, that was to grandfather >> > existing text, not to allow new text to continue using >> > the old term and definitions. >> >> Ok. Here's the real reason not to change: Many people use >> ASN.1 compilers which means that names from the ASN.1 >> module end up being directly used in higher layer code. >> Changing the name causes that code not to compile. I'd >> say that there's quite a lot of 3280 code in the world >> at this stage. So, if the semantics isn't supposed to >> have changed (and I assume that is meant to be the >> case) then this cost just doesn't seem worthwhile. >> >>> 5) It is the definition that is important. I recommend >> >> >> > that any new text align with the definition in the approved >> > technical corrigenda against the 4th edition and in >> > the upcoming 5th edition. >> >> While I'd rather not see any more text added on this, >> (there's been way too much already) I wouldn't have a big >> issue with trying to help a reader make sense of the >> fact that 3280bis and x.509 name this bit differently. >> >> However text like the sentence below is IMO almost >> certain to cause even more confusion: >> >> The precise type of commitment of the signer e.g. "reviewed >> and approved" or "with the intent to be bound", may be >> signalled by the content being signed, e.g. the signed >> document itself or some additional signed information. >> >> That sounds like the sole purpose of the CC-bit is as >> a flag to indicate when some other bits somewhere else >> tell you what the CC-bit means. >> >> So in the absence of some better text I think that 3280bis >> is better off just saying "NR a.k.a. CC" as it currently >> does. >> >> Regards, >> Stephen. >> >>> >>> At 14:49 +0100 5/26/05, Stephen Farrell wrote: >>> >>>> Denis, >>>> >>>> >>>>> Please align with the the ISO-ITU text. >>>> >>>> >>>> >>>> Do you mean we should rename the bits and include the >>>> other new x.509 text? The design team were against >>>> doing that. >>>> >>>> Is there any (good) reason other than alignment to >>>> make such a change? >>>> >>>> Personally, I find the new x.509 text worse, although >>>> it does say: "Note that it is not incorrect to refer to >>>> this keyUsage bit using the identifier nonRepudiation." >>>> So I can argue that we are aligned, just not identical. >>>> >>>> But of course, I'm from the non-repudiation is non-sense >>>> camp so I may not be the best judge. >>>> >>>> Stephen. >>>> >>>> PS: A quibble: >>>> >>>> >>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>> [the nonRepudiation] bit to contentCommitment" >>>>> >>>>> This statement is untrue. >>>> >>>> >>>> >>>> The paragraph to which I assume you refer contains 3 >>>> statements - it'd be easier to close these threads if >>>> you were more precise. (I think I got what you want >>>> by the end of the mail though...) >>>> >>>> PPS: "This statement is untrue." >>>> Are you from Crete after all? :-) >>>> >>>> >>>> >>>> >>>> Denis Pinkas wrote: >>>> >>>> >>>>> To the list, >>>>> >>>>> The disposition of comments states: >>>>> >>>>> 13) The descriptions of the meanings of the digitalSignature and >>>>> nonRepudiation bits of keyUsage may need to be adjusted based >>>>> on the work in X.509 >>>>> >>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>> [the nonRepudiation] bit to contentCommitment" >>>>> >>>>> This statement is untrue. >>>>> >>>>> The text from X.509 has been published in Corrigendum 3 (04/2004) >>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>>>> >>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>>>> >>>>> An extract from this text is copied below: >>>>> >>>>> a) digitalSignature: for verifying digital signatures that are used >>>>> with an entity authentication service, a data origin authentication >>>>> service or/and an integrity service; >>>>> >>>>> b) contentCommitment: for verifying digital signatures which are >>>>> intended >>>>> to signal that the signer is committing to the content being signed. >>>>> The type of commitment the certificate can be used to support may be >>>>> further constrained by the CA, e.g. through a certificate policy. >>>>> The precise type of commitment of the signer e.g. "reviewed and >>>>> approved" or "with the intent to be bound", may be signalled by the >>>>> content being signed, e.g. the signed document itself or some >>>>> additional >>>>> signed information. >>>>> >>>>> Since a content commitment signing is considered to be a digitally >>>>> signed >>>>> transaction, the digitalSignature bit need not be set in the >>>>> certificate. >>>>> If it is set, it does not affect the level of commitment the >>>>> signer has >>>>> endowed in the signed content. >>>>> >>>>> Note that it is not incorrect to refer to this keyUsage bit using the >>>>> identifier nonRepudiation. However, the use of this identifier has >>>>> been >>>>> deprecated. Regardless of the identifier used, the semantics of >>>>> this bit >>>>> are as specified in this Directory Specification. >>>>> >>>>> The text from 3280 is copied below: >>>>> >>>>> The digitalSignature bit is asserted when the subject public key >>>>> is used with a digital signature mechanism to support security >>>>> services other than certificate signing (bit 5), or CRL signing >>>>> (bit 6). Digital signature mechanisms are often used for entity >>>>> authentication and data origin authentication with integrity. >>>>> >>>>> The nonRepudiation bit is asserted when the subject public key is >>>>> used to verify digital signatures used to provide a non- >>>>> repudiation service which protects against the signing entity >>>>> falsely denying some action, excluding certificate or CRL signing. >>>>> In the case of later conflict, a reliable third party may >>>>> determine the authenticity of the signed data. >>>>> >>>>> Further distinctions between the digitalSignature and >>>>> nonRepudiation bits may be provided in specific certificate >>>>> policies. >>>>> >>>>> The text from 3280bis does not align with the ISO-ITU text. >>>>> Please align with the the ISO-ITU text. >>>>> >>>>> Denis >>>> >>>> >>> >>> >>> >> >> > > > From owner-ietf-pkix@mail.imc.org Fri May 27 09:19:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09683 for ; Fri, 27 May 2005 09:19:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCTdRF050275; Fri, 27 May 2005 05:29:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RCTdYt050274; Fri, 27 May 2005 05:29:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCTbr2050230 for ; Fri, 27 May 2005 05:29:38 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA30434; Fri, 27 May 2005 14:44:42 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052714293001:1975 ; Fri, 27 May 2005 14:29:30 +0200 Message-ID: <429712E8.7050708@bull.net> Date: Fri, 27 May 2005 14:30:32 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stephen Farrell CC: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> <4296F66E.3020406@bull.net> <42971110.5040008@cs.tcd.ie> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/05/2005 14:29:30, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/05/2005 14:29:31, Serialize complete at 27/05/2005 14:29:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stephen, Just before leaving my office in a few minutes for a few days, here is a new text proposal for the DS bit: New proposal for 3280bis: The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures that are used with an entity authentication service, a data origin authentication service or/and an integrity service. However, it SHALL not be set when certificate signing (bit 5) or CRL signing (bit 6) is set. Denis > Hi Denis, > > I've no problem with aligning the DS bit text although I > wouldn't say that they're incompatible actually. I like > the way 3280 says the DS isn't for certs or CRLs which > ISO doesn't seem to include. Would you like to propose > an aligned paragraph? > > I oppose inclusion of new NR/CC text and the name change. > > Stephen. > > Denis Pinkas wrote: > >> Stephen, >> >> I agree with everything Hoyt said on bit 1. >> >> However, there are two sides for this coin : bit 0 and bit 1. >> >> Both are again copied below: >> >> ISO Corrigendum: >> >> a) digitalSignature: for verifying digital signatures that are used >> with an entity authentication service, a data origin >> authentication >> service or/and an integrity service; >> >> 3280bis: >> >> The digitalSignature bit is asserted when the subject public key >> is used with a digital signature mechanism to support security >> services other than certificate signing (bit 5), or CRL signing >> (bit 6). Digital signature mechanisms are often used for entity >> authentication and data origin authentication with integrity. >> >> The current text of 3280bis for bit 0 (ds) is incompatible with the ISO >> Corrigendum. >> >> As Hoyt already said, any new text should align with the definition in >> the approved technical corrigenda against the 4th edition and in the >> upcoming 5th edition. >> >> Denis >> >>> Hi Hoyt, >>> >>> Hoyt L Kesterson II wrote: >>> >>>> Stephen >>>> >>>> I am somewhat dismayed at your reaction to the new text in X.509. >>> >>> >>> >>> >>> I'm sorry about that, but I guess I'm just fed up with the >>> NR bit, though I can understand how people who've worked >>> hard to try fix it might be dismayed. >>> >>> (BTW: I once suggested that CAs MUST set this bit randomly >>> since that was the only way I could see to kill it off >>> properly. If you can get that into X.509 then I'd be happy >>> for 3280bis to align:-) >>> >>> > I am not going to argue with you here (maybe in a bar the next time >>> > we run into each other). >>> >>> Good idea! >>> >>>> However, I do want to mention several points. >>>> >>>> 1) I initiated the change in text because of the various >>>> interpretations >>> >>> >>> >>> > by implementors that were resulting in non-interoperable >>> > implementations. It was a conversation with a PKIXer at a RSA >>> > conference a few years ago that caused me to articulate a private >>> > concern. >>> >>> I agree that everything connected with this bit has been >>> confused and remains so. >>> >>>> 2) The legal community was very confused. There was even a >>> >>> >>> >>> > paper castigating the standard developers for mandating that >>> > one could not repudiate an action. >>> >>> Maybe the mistake was defining a bit that laywers care about? >>> >>>> 3) There were several meetings held where there was significant >>> >>> >>> >>> > participation by people in the IETF PKIX group (as well as >>> > lawyers). All agreed there was a problem with the published text. >>> > Denis and I argued long and hard over wording but we didn't >>> > disagree on the need for new text and its general intent. >>> >>> Fair enough. >>> >>>> 4) Russ was concerned that change would cause a problem >>> >>> >>> >>> > with existing IETF standards and was not too happy with a >>> > change to the name of the bit. That's why I put the line >>> > in that you referenced. However, that was to grandfather >>> > existing text, not to allow new text to continue using >>> > the old term and definitions. >>> >>> Ok. Here's the real reason not to change: Many people use >>> ASN.1 compilers which means that names from the ASN.1 >>> module end up being directly used in higher layer code. >>> Changing the name causes that code not to compile. I'd >>> say that there's quite a lot of 3280 code in the world >>> at this stage. So, if the semantics isn't supposed to >>> have changed (and I assume that is meant to be the >>> case) then this cost just doesn't seem worthwhile. >>> >>>> 5) It is the definition that is important. I recommend >>> >>> >>> >>> > that any new text align with the definition in the approved >>> > technical corrigenda against the 4th edition and in >>> > the upcoming 5th edition. >>> >>> While I'd rather not see any more text added on this, >>> (there's been way too much already) I wouldn't have a big >>> issue with trying to help a reader make sense of the >>> fact that 3280bis and x.509 name this bit differently. >>> >>> However text like the sentence below is IMO almost >>> certain to cause even more confusion: >>> >>> The precise type of commitment of the signer e.g. "reviewed >>> and approved" or "with the intent to be bound", may be >>> signalled by the content being signed, e.g. the signed >>> document itself or some additional signed information. >>> >>> That sounds like the sole purpose of the CC-bit is as >>> a flag to indicate when some other bits somewhere else >>> tell you what the CC-bit means. >>> >>> So in the absence of some better text I think that 3280bis >>> is better off just saying "NR a.k.a. CC" as it currently >>> does. >>> >>> Regards, >>> Stephen. >>> >>>> >>>> At 14:49 +0100 5/26/05, Stephen Farrell wrote: >>>> >>>>> Denis, >>>>> >>>>> >>>>>> Please align with the the ISO-ITU text. >>>>> >>>>> >>>>> >>>>> >>>>> Do you mean we should rename the bits and include the >>>>> other new x.509 text? The design team were against >>>>> doing that. >>>>> >>>>> Is there any (good) reason other than alignment to >>>>> make such a change? >>>>> >>>>> Personally, I find the new x.509 text worse, although >>>>> it does say: "Note that it is not incorrect to refer to >>>>> this keyUsage bit using the identifier nonRepudiation." >>>>> So I can argue that we are aligned, just not identical. >>>>> >>>>> But of course, I'm from the non-repudiation is non-sense >>>>> camp so I may not be the best judge. >>>>> >>>>> Stephen. >>>>> >>>>> PS: A quibble: >>>>> >>>>> >>>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>>> [the nonRepudiation] bit to contentCommitment" >>>>>> >>>>>> This statement is untrue. >>>>> >>>>> >>>>> >>>>> >>>>> The paragraph to which I assume you refer contains 3 >>>>> statements - it'd be easier to close these threads if >>>>> you were more precise. (I think I got what you want >>>>> by the end of the mail though...) >>>>> >>>>> PPS: "This statement is untrue." >>>>> Are you from Crete after all? :-) >>>>> >>>>> >>>>> >>>>> >>>>> Denis Pinkas wrote: >>>>> >>>>> >>>>>> To the list, >>>>>> >>>>>> The disposition of comments states: >>>>>> >>>>>> 13) The descriptions of the meanings of the digitalSignature and >>>>>> nonRepudiation bits of keyUsage may need to be adjusted based >>>>>> on the work in X.509 >>>>>> >>>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>>> [the nonRepudiation] bit to contentCommitment" >>>>>> >>>>>> This statement is untrue. >>>>>> >>>>>> The text from X.509 has been published in Corrigendum 3 (04/2004) >>>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>>>>> >>>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>>>>> >>>>>> An extract from this text is copied below: >>>>>> >>>>>> a) digitalSignature: for verifying digital signatures that are used >>>>>> with an entity authentication service, a data origin authentication >>>>>> service or/and an integrity service; >>>>>> >>>>>> b) contentCommitment: for verifying digital signatures which are >>>>>> intended >>>>>> to signal that the signer is committing to the content being signed. >>>>>> The type of commitment the certificate can be used to support may be >>>>>> further constrained by the CA, e.g. through a certificate policy. >>>>>> The precise type of commitment of the signer e.g. "reviewed and >>>>>> approved" or "with the intent to be bound", may be signalled by the >>>>>> content being signed, e.g. the signed document itself or some >>>>>> additional >>>>>> signed information. >>>>>> >>>>>> Since a content commitment signing is considered to be a >>>>>> digitally signed >>>>>> transaction, the digitalSignature bit need not be set in the >>>>>> certificate. >>>>>> If it is set, it does not affect the level of commitment the >>>>>> signer has >>>>>> endowed in the signed content. >>>>>> >>>>>> Note that it is not incorrect to refer to this keyUsage bit using >>>>>> the >>>>>> identifier nonRepudiation. However, the use of this identifier >>>>>> has been >>>>>> deprecated. Regardless of the identifier used, the semantics of >>>>>> this bit >>>>>> are as specified in this Directory Specification. >>>>>> >>>>>> The text from 3280 is copied below: >>>>>> >>>>>> The digitalSignature bit is asserted when the subject public key >>>>>> is used with a digital signature mechanism to support security >>>>>> services other than certificate signing (bit 5), or CRL signing >>>>>> (bit 6). Digital signature mechanisms are often used for entity >>>>>> authentication and data origin authentication with integrity. >>>>>> >>>>>> The nonRepudiation bit is asserted when the subject public key is >>>>>> used to verify digital signatures used to provide a non- >>>>>> repudiation service which protects against the signing entity >>>>>> falsely denying some action, excluding certificate or CRL >>>>>> signing. >>>>>> In the case of later conflict, a reliable third party may >>>>>> determine the authenticity of the signed data. >>>>>> >>>>>> Further distinctions between the digitalSignature and >>>>>> nonRepudiation bits may be provided in specific certificate >>>>>> policies. >>>>>> >>>>>> The text from 3280bis does not align with the ISO-ITU text. >>>>>> Please align with the the ISO-ITU text. >>>>>> >>>>>> Denis >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > From owner-ietf-pkix@mail.imc.org Fri May 27 09:23:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10036 for ; Fri, 27 May 2005 09:23:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCZodM052509; Fri, 27 May 2005 05:35:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RCZoEg052507; Fri, 27 May 2005 05:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCZmbd052465 for ; Fri, 27 May 2005 05:35:48 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 2E09E14C035; Fri, 27 May 2005 13:35:43 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A0688F16512; Fri, 27 May 2005 13:35:43 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id C3C3C14C035; Fri, 27 May 2005 13:35:42 +0100 (IST) Message-ID: <42971517.1010104@cs.tcd.ie> Date: Fri, 27 May 2005 13:39:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> <4296F66E.3020406@bull.net> <42971110.5040008@cs.tcd.ie> <429712E8.7050708@bull.net> In-Reply-To: <429712E8.7050708@bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.733) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A1688F16512 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Denis, Fine by me. Have a nice trip, Stephen. Denis Pinkas wrote: > Stephen, > > Just before leaving my office in a few minutes for a few days, > here is a new text proposal for the DS bit: > > New proposal for 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service. However, it SHALL not be set > when certificate signing (bit 5) or CRL signing (bit 6) is set. > > Denis > >> Hi Denis, >> >> I've no problem with aligning the DS bit text although I >> wouldn't say that they're incompatible actually. I like >> the way 3280 says the DS isn't for certs or CRLs which >> ISO doesn't seem to include. Would you like to propose >> an aligned paragraph? >> >> I oppose inclusion of new NR/CC text and the name change. >> >> Stephen. >> >> Denis Pinkas wrote: >> >>> Stephen, >>> >>> I agree with everything Hoyt said on bit 1. >>> >>> However, there are two sides for this coin : bit 0 and bit 1. >>> >>> Both are again copied below: >>> >>> ISO Corrigendum: >>> >>> a) digitalSignature: for verifying digital signatures that are used >>> with an entity authentication service, a data origin >>> authentication >>> service or/and an integrity service; >>> >>> 3280bis: >>> >>> The digitalSignature bit is asserted when the subject public key >>> is used with a digital signature mechanism to support security >>> services other than certificate signing (bit 5), or CRL signing >>> (bit 6). Digital signature mechanisms are often used for entity >>> authentication and data origin authentication with integrity. >>> >>> The current text of 3280bis for bit 0 (ds) is incompatible with the ISO >>> Corrigendum. >>> >>> As Hoyt already said, any new text should align with the definition >>> in the approved technical corrigenda against the 4th edition and in >>> the upcoming 5th edition. >>> >>> Denis >>> >>>> Hi Hoyt, >>>> >>>> Hoyt L Kesterson II wrote: >>>> >>>>> Stephen >>>>> >>>>> I am somewhat dismayed at your reaction to the new text in X.509. >>>> >>>> >>>> >>>> >>>> >>>> I'm sorry about that, but I guess I'm just fed up with the >>>> NR bit, though I can understand how people who've worked >>>> hard to try fix it might be dismayed. >>>> >>>> (BTW: I once suggested that CAs MUST set this bit randomly >>>> since that was the only way I could see to kill it off >>>> properly. If you can get that into X.509 then I'd be happy >>>> for 3280bis to align:-) >>>> >>>> > I am not going to argue with you here (maybe in a bar the next time >>>> > we run into each other). >>>> >>>> Good idea! >>>> >>>>> However, I do want to mention several points. >>>>> >>>>> 1) I initiated the change in text because of the various >>>>> interpretations >>>> >>>> >>>> >>>> >>>> > by implementors that were resulting in non-interoperable >>>> > implementations. It was a conversation with a PKIXer at a RSA >>>> > conference a few years ago that caused me to articulate a private >>>> > concern. >>>> >>>> I agree that everything connected with this bit has been >>>> confused and remains so. >>>> >>>>> 2) The legal community was very confused. There was even a >>>> >>>> >>>> >>>> >>>> > paper castigating the standard developers for mandating that >>>> > one could not repudiate an action. >>>> >>>> Maybe the mistake was defining a bit that laywers care about? >>>> >>>>> 3) There were several meetings held where there was significant >>>> >>>> >>>> >>>> >>>> > participation by people in the IETF PKIX group (as well as >>>> > lawyers). All agreed there was a problem with the published text. >>>> > Denis and I argued long and hard over wording but we didn't >>>> > disagree on the need for new text and its general intent. >>>> >>>> Fair enough. >>>> >>>>> 4) Russ was concerned that change would cause a problem >>>> >>>> >>>> >>>> >>>> > with existing IETF standards and was not too happy with a >>>> > change to the name of the bit. That's why I put the line >>>> > in that you referenced. However, that was to grandfather >>>> > existing text, not to allow new text to continue using >>>> > the old term and definitions. >>>> >>>> Ok. Here's the real reason not to change: Many people use >>>> ASN.1 compilers which means that names from the ASN.1 >>>> module end up being directly used in higher layer code. >>>> Changing the name causes that code not to compile. I'd >>>> say that there's quite a lot of 3280 code in the world >>>> at this stage. So, if the semantics isn't supposed to >>>> have changed (and I assume that is meant to be the >>>> case) then this cost just doesn't seem worthwhile. >>>> >>>>> 5) It is the definition that is important. I recommend >>>> >>>> >>>> >>>> >>>> > that any new text align with the definition in the approved >>>> > technical corrigenda against the 4th edition and in >>>> > the upcoming 5th edition. >>>> >>>> While I'd rather not see any more text added on this, >>>> (there's been way too much already) I wouldn't have a big >>>> issue with trying to help a reader make sense of the >>>> fact that 3280bis and x.509 name this bit differently. >>>> >>>> However text like the sentence below is IMO almost >>>> certain to cause even more confusion: >>>> >>>> The precise type of commitment of the signer e.g. "reviewed >>>> and approved" or "with the intent to be bound", may be >>>> signalled by the content being signed, e.g. the signed >>>> document itself or some additional signed information. >>>> >>>> That sounds like the sole purpose of the CC-bit is as >>>> a flag to indicate when some other bits somewhere else >>>> tell you what the CC-bit means. >>>> >>>> So in the absence of some better text I think that 3280bis >>>> is better off just saying "NR a.k.a. CC" as it currently >>>> does. >>>> >>>> Regards, >>>> Stephen. >>>> >>>>> >>>>> At 14:49 +0100 5/26/05, Stephen Farrell wrote: >>>>> >>>>>> Denis, >>>>>> >>>>>> >>>>>>> Please align with the the ISO-ITU text. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Do you mean we should rename the bits and include the >>>>>> other new x.509 text? The design team were against >>>>>> doing that. >>>>>> >>>>>> Is there any (good) reason other than alignment to >>>>>> make such a change? >>>>>> >>>>>> Personally, I find the new x.509 text worse, although >>>>>> it does say: "Note that it is not incorrect to refer to >>>>>> this keyUsage bit using the identifier nonRepudiation." >>>>>> So I can argue that we are aligned, just not identical. >>>>>> >>>>>> But of course, I'm from the non-repudiation is non-sense >>>>>> camp so I may not be the best judge. >>>>>> >>>>>> Stephen. >>>>>> >>>>>> PS: A quibble: >>>>>> >>>>>> >>>>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>>>> [the nonRepudiation] bit to contentCommitment" >>>>>>> >>>>>>> This statement is untrue. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The paragraph to which I assume you refer contains 3 >>>>>> statements - it'd be easier to close these threads if >>>>>> you were more precise. (I think I got what you want >>>>>> by the end of the mail though...) >>>>>> >>>>>> PPS: "This statement is untrue." >>>>>> Are you from Crete after all? :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Denis Pinkas wrote: >>>>>> >>>>>> >>>>>>> To the list, >>>>>>> >>>>>>> The disposition of comments states: >>>>>>> >>>>>>> 13) The descriptions of the meanings of the digitalSignature and >>>>>>> nonRepudiation bits of keyUsage may need to be adjusted based >>>>>>> on the work in X.509 >>>>>>> >>>>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>>>> [the nonRepudiation] bit to contentCommitment" >>>>>>> >>>>>>> This statement is untrue. >>>>>>> >>>>>>> The text from X.509 has been published in Corrigendum 3 (04/2004) >>>>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>>>>>> >>>>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>>>>>> >>>>>>> An extract from this text is copied below: >>>>>>> >>>>>>> a) digitalSignature: for verifying digital signatures that are used >>>>>>> with an entity authentication service, a data origin authentication >>>>>>> service or/and an integrity service; >>>>>>> >>>>>>> b) contentCommitment: for verifying digital signatures which are >>>>>>> intended >>>>>>> to signal that the signer is committing to the content being >>>>>>> signed. >>>>>>> The type of commitment the certificate can be used to support >>>>>>> may be >>>>>>> further constrained by the CA, e.g. through a certificate policy. >>>>>>> The precise type of commitment of the signer e.g. "reviewed and >>>>>>> approved" or "with the intent to be bound", may be signalled by the >>>>>>> content being signed, e.g. the signed document itself or some >>>>>>> additional >>>>>>> signed information. >>>>>>> >>>>>>> Since a content commitment signing is considered to be a >>>>>>> digitally signed >>>>>>> transaction, the digitalSignature bit need not be set in the >>>>>>> certificate. >>>>>>> If it is set, it does not affect the level of commitment the >>>>>>> signer has >>>>>>> endowed in the signed content. >>>>>>> >>>>>>> Note that it is not incorrect to refer to this keyUsage bit >>>>>>> using the >>>>>>> identifier nonRepudiation. However, the use of this identifier >>>>>>> has been >>>>>>> deprecated. Regardless of the identifier used, the semantics of >>>>>>> this bit >>>>>>> are as specified in this Directory Specification. >>>>>>> >>>>>>> The text from 3280 is copied below: >>>>>>> >>>>>>> The digitalSignature bit is asserted when the subject public key >>>>>>> is used with a digital signature mechanism to support security >>>>>>> services other than certificate signing (bit 5), or CRL signing >>>>>>> (bit 6). Digital signature mechanisms are often used for entity >>>>>>> authentication and data origin authentication with integrity. >>>>>>> >>>>>>> The nonRepudiation bit is asserted when the subject public >>>>>>> key is >>>>>>> used to verify digital signatures used to provide a non- >>>>>>> repudiation service which protects against the signing entity >>>>>>> falsely denying some action, excluding certificate or CRL >>>>>>> signing. >>>>>>> In the case of later conflict, a reliable third party may >>>>>>> determine the authenticity of the signed data. >>>>>>> >>>>>>> Further distinctions between the digitalSignature and >>>>>>> nonRepudiation bits may be provided in specific certificate >>>>>>> policies. >>>>>>> >>>>>>> The text from 3280bis does not align with the ISO-ITU text. >>>>>>> Please align with the the ISO-ITU text. >>>>>>> >>>>>>> Denis >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> > > > From owner-ietf-pkix@mail.imc.org Fri May 27 10:18:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15310 for ; Fri, 27 May 2005 10:18:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDGhZY066075; Fri, 27 May 2005 06:16:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RDGhbH066074; Fri, 27 May 2005 06:16:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDGgpa066068 for ; Fri, 27 May 2005 06:16:42 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 17FB734759; Sat, 28 May 2005 01:16:41 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14778-15; Sat, 28 May 2005 01:16:40 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id CA7743449E; Sat, 28 May 2005 01:16:34 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CD16737756; Sat, 28 May 2005 01:16:34 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Dbehf-00007Q-00; Sat, 28 May 2005 01:16:43 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, stephen.farrell@cs.tcd.ie Subject: Re: 3280bis: key usage (13) Cc: ietf-pkix@imc.org In-Reply-To: <429712E8.7050708@bull.net> Message-Id: Date: Sat, 28 May 2005 01:16:43 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas writes: >The digitalSignature bit is asserted when the subject public key is used for >verifying digital signatures that are used with an entity authentication >service, a data origin authentication service or/and an integrity service. Wouldn't it be better to say that it's used for purposes other than CC? By saying that DS can only be used for purposes A, B, and C, and CC for purpose D, what happens if someone wants to mark a key for purpose E? Since CC seems to be the more restrictive, it would be better to say that DS is to be used for everything else. If not, we'd need a third signature bit to cover the 'other' category that's explicitly excluded from DS and CC. >However, it SHALL not be set when certificate signing (bit 5) or CRL signing >(bit 6) is set. Why not? The intent of the original text was to say that digitalSignature doesn't mean you can use the cert for cert/CRL signing, now it says something completely different, that a cert-signing cert can never be used for any other purpose. This wording change would make a number of CAs non-compliant, since they do use their CA certs for other purposes (don't ask me why, I just see the things turn up from time to time). The wording should be something like "Setting this bit doesn't mean the cert can be used for cert or CRL signing; for that, you need to set the cert/CRL signing bits". (I realise this stuff should be obvious to anyone, but there are going to be CAs and vendors out there who defend their buggy software by interpreting the text as literally as possible, so it had better not contain any loopholes). Peter. From owner-ietf-pkix@mail.imc.org Fri May 27 10:20:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15652 for ; Fri, 27 May 2005 10:20:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDIx92066235; Fri, 27 May 2005 06:18:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RDIxJU066234; Fri, 27 May 2005 06:18:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDIweb066214 for ; Fri, 27 May 2005 06:18:58 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com) Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id C619E5FEE1; Fri, 27 May 2005 08:18:28 -0500 (CDT) Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id ; Fri, 27 May 2005 08:18:28 -0500 Message-ID: <5.1.0.14.0.20050527090001.00b128d0@172.16.146.192> From: "Kazin, Joel" To: Stefan Santesson , Denis Pinkas , Stephen Farrell Cc: Hoyt L Kesterson II , pkix Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 08:19:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C562BE.91D1CCE2" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C562BE.91D1CCE2 Content-Type: text/plain; charset="iso-8859-1" The core problem is labeling the bit non-repudiation. It goes against the legal idea that you can attempt to repudiate your alleged actions even when your defense is weaker than "the cat ate my homework". To me, non-repudiation is more of a marketing description than a technical, contractual, or legal description of what the signer intended to do. A secondary problem is that the non-repudiation bit doesn't tell a relying party or third party enough. The logical place to look for such information is in the id-ce-certificatePolicies extension. Was the id-ce-certificatePolicies extension part of the original x.509 v1 specification? If that is true, then perhaps the non-repudiation bit is just a holdover from the original x.509 v1 certificate definition? If my arguments are true then we can: 1) keep calling it non-repudiation and strongly deprecate its use, 2) change the name and deprecate its use, 3) change the name and allow its use. I favor 1 over 2 over 3. At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote: Speaking as implementer and not design team member, I can live with both texts since they allow me to do the same thing. It allows my low level application to add a digital signature supported by the digital signature bit, where the intention of that application is to add integrity and origin authentication, while the use of the signature in practice (higher layers) ends up being used as evidence of some kind of commitment. Example. An e-mail application adds an arbitrary signature supported by the DS bit, while the body of the text reads "Through the digital signature on this e-mail I commit to....). This is now a perfectly valid scenario according to both texts. The real defect that was fixed was that the digital signature bit said that it was for purposes "other" than NR. That is now gone in both standards. I agree to Stephen's rationale to keep the name nonRepudiation. It is not worth the cost to change the name. Stephen's point here was missing in the X.509 discussions of a name change. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org ] > On Behalf Of Denis Pinkas > Sent: den 27 maj 2005 12:29 > To: Stephen Farrell > Cc: Hoyt L Kesterson II; pkix > Subject: Re: 3280bis: key usage (13) > > > Stephen, > > I agree with everything Hoyt said on bit 1. > > However, there are two sides for this coin : bit 0 and bit 1. > > Both are again copied below: > > ISO Corrigendum: > > a) digitalSignature: for verifying digital signatures that are used > with an entity authentication service, a data origin > authentication > service or/and an integrity service; > > 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > The current text of 3280bis for bit 0 (ds) is incompatible with the ISO > Corrigendum. > > As Hoyt already said, any new text should align with the definition in the > approved technical corrigenda against the 4th edition and in the upcoming > 5th edition. > > Denis > > > Hi Hoyt, > > > > Hoyt L Kesterson II wrote: > > > >> Stephen > >> > >> I am somewhat dismayed at your reaction to the new text in X.509. > > > > > > I'm sorry about that, but I guess I'm just fed up with the > > NR bit, though I can understand how people who've worked > > hard to try fix it might be dismayed. > > > > (BTW: I once suggested that CAs MUST set this bit randomly > > since that was the only way I could see to kill it off > > properly. If you can get that into X.509 then I'd be happy > > for 3280bis to align:-) > > > > > I am not going to argue with you here (maybe in a bar the next time > > > we run into each other). > > > > Good idea! > > > >> However, I do want to mention several points. > >> > >> 1) I initiated the change in text because of the various > interpretations > > > > > by implementors that were resulting in non-interoperable > > > implementations. It was a conversation with a PKIXer at a RSA > > > conference a few years ago that caused me to articulate a private > > > concern. > > > > I agree that everything connected with this bit has been > > confused and remains so. > > > >> 2) The legal community was very confused. There was even a > > > > > paper castigating the standard developers for mandating that > > > one could not repudiate an action. > > > > Maybe the mistake was defining a bit that laywers care about? > > > >> 3) There were several meetings held where there was significant > > > > > participation by people in the IETF PKIX group (as well as > > > lawyers). All agreed there was a problem with the published text. > > > Denis and I argued long and hard over wording but we didn't > > > disagree on the need for new text and its general intent. > > > > Fair enough. > > > >> 4) Russ was concerned that change would cause a problem > > > > > with existing IETF standards and was not too happy with a > > > change to the name of the bit. That's why I put the line > > > in that you referenced. However, that was to grandfather > > > existing text, not to allow new text to continue using > > > the old term and definitions. > > > > Ok. Here's the real reason not to change: Many people use > > ASN.1 compilers which means that names from the ASN.1 > > module end up being directly used in higher layer code. > > Changing the name causes that code not to compile. I'd > > say that there's quite a lot of 3280 code in the world > > at this stage. So, if the semantics isn't supposed to > > have changed (and I assume that is meant to be the > > case) then this cost just doesn't seem worthwhile. > > > >> 5) It is the definition that is important. I recommend > > > > > that any new text align with the definition in the approved > > > technical corrigenda against the 4th edition and in > > > the upcoming 5th edition. > > > > While I'd rather not see any more text added on this, > > (there's been way too much already) I wouldn't have a big > > issue with trying to help a reader make sense of the > > fact that 3280bis and x.509 name this bit differently. > > > > However text like the sentence below is IMO almost > > certain to cause even more confusion: > > > > The precise type of commitment of the signer e.g. "reviewed > > and approved" or "with the intent to be bound", may be > > signalled by the content being signed, e.g. the signed > > document itself or some additional signed information. > > > > That sounds like the sole purpose of the CC-bit is as > > a flag to indicate when some other bits somewhere else > > tell you what the CC-bit means. > > > > So in the absence of some better text I think that 3280bis > > is better off just saying "NR a.k.a. CC" as it currently > > does. > > > > Regards, > > Stephen. > > > >> > >> At 14:49 +0100 5/26/05, Stephen Farrell wrote: > >> > >>> Denis, > >>> > >>> > >>>> Please align with the the ISO-ITU text. > >>> > >>> > >>> Do you mean we should rename the bits and include the > >>> other new x.509 text? The design team were against > >>> doing that. > >>> > >>> Is there any (good) reason other than alignment to > >>> make such a change? > >>> > >>> Personally, I find the new x.509 text worse, although > >>> it does say: "Note that it is not incorrect to refer to > >>> this keyUsage bit using the identifier nonRepudiation." > >>> So I can argue that we are aligned, just not identical. > >>> > >>> But of course, I'm from the non-repudiation is non-sense > >>> camp so I may not be the best judge. > >>> > >>> Stephen. > >>> > >>> PS: A quibble: > >>> > >>> > >>>> The new text in X.509 aligns with the text in RFC 3280. No changes > >>>> are required to 3280bis. A comment has been added to the ASN.1 for > >>>> KeyUsage stating that "recent editions of X.509 have renamed > >>>> [the nonRepudiation] bit to contentCommitment" > >>>> > >>>> This statement is untrue. > >>> > >>> > >>> The paragraph to which I assume you refer contains 3 > >>> statements - it'd be easier to close these threads if > >>> you were more precise. (I think I got what you want > >>> by the end of the mail though...) > >>> > >>> PPS: "This statement is untrue." > >>> Are you from Crete after all? :-) > >>> > >>> > >>> > >>> > >>> Denis Pinkas wrote: > >>> > >>> > >>>> To the list, > >>>> > >>>> The disposition of comments states: > >>>> > >>>> 13) The descriptions of the meanings of the digitalSignature and > >>>> nonRepudiation bits of keyUsage may need to be adjusted based > >>>> on the work in X.509 > >>>> > >>>> The new text in X.509 aligns with the text in RFC 3280. No changes > >>>> are required to 3280bis. A comment has been added to the ASN.1 for > >>>> KeyUsage stating that "recent editions of X.509 have renamed > >>>> [the nonRepudiation] bit to contentCommitment" > >>>> > >>>> This statement is untrue. > >>>> > >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) > >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called > >>>> > >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). > >>>> > >>>> An extract from this text is copied below: > >>>> > >>>> a) digitalSignature: for verifying digital signatures that are used > >>>> with an entity authentication service, a data origin authentication > >>>> service or/and an integrity service; > >>>> > >>>> b) contentCommitment: for verifying digital signatures which are > >>>> intended > >>>> to signal that the signer is committing to the content being signed. > >>>> The type of commitment the certificate can be used to support may be > >>>> further constrained by the CA, e.g. through a certificate policy. > >>>> The precise type of commitment of the signer e.g. "reviewed and > >>>> approved" or "with the intent to be bound", may be signalled by the > >>>> content being signed, e.g. the signed document itself or some > >>>> additional > >>>> signed information. > >>>> > >>>> Since a content commitment signing is considered to be a digitally > >>>> signed > >>>> transaction, the digitalSignature bit need not be set in the > >>>> certificate. > >>>> If it is set, it does not affect the level of commitment the signer > >>>> has > >>>> endowed in the signed content. > >>>> > >>>> Note that it is not incorrect to refer to this keyUsage bit using > the > >>>> identifier nonRepudiation. However, the use of this identifier has > >>>> been > >>>> deprecated. Regardless of the identifier used, the semantics of > >>>> this bit > >>>> are as specified in this Directory Specification. > >>>> > >>>> The text from 3280 is copied below: > >>>> > >>>> The digitalSignature bit is asserted when the subject public key > >>>> is used with a digital signature mechanism to support security > >>>> services other than certificate signing (bit 5), or CRL signing > >>>> (bit 6). Digital signature mechanisms are often used for entity > >>>> authentication and data origin authentication with integrity. > >>>> > >>>> The nonRepudiation bit is asserted when the subject public key is > >>>> used to verify digital signatures used to provide a non- > >>>> repudiation service which protects against the signing entity > >>>> falsely denying some action, excluding certificate or CRL > signing. > >>>> In the case of later conflict, a reliable third party may > >>>> determine the authenticity of the signed data. > >>>> > >>>> Further distinctions between the digitalSignature and > >>>> nonRepudiation bits may be provided in specific certificate > >>>> policies. > >>>> > >>>> The text from 3280bis does not align with the ISO-ITU text. > >>>> Please align with the the ISO-ITU text. > >>>> > >>>> Denis > >>> > >> > >> > >> > > > > > Joel S. Kazin CPA, CISA, CISSP, CISM Senior Consultant Atos Origin 40 Old Sleepy Hollow Road Pleasantville, New York 10570-3802 USA Phone +1 914-769-8780 Mobile +1 914-564-1484 email joel.kazin@atosorigin.com www.atosorigin.com ------_=_NextPart_001_01C562BE.91D1CCE2 Content-Type: text/html; charset="iso-8859-1" The core problem is labeling the bit non-repudiation.  It goes against the legal idea that you can attempt to repudiate your alleged actions even when your defense is weaker than "the cat ate my homework".  To me, non-repudiation is more of a marketing description than a technical, contractual, or legal description of what the signer intended to do. 

A secondary problem is that the non-repudiation bit doesn't tell a relying party or third party enough.  The logical place to look for such information is in the id-ce-certificatePolicies extension.  Was the id-ce-certificatePolicies extension part of the original x.509 v1 specification?  If that is true, then perhaps the non-repudiation bit is just a holdover from the original x.509 v1 certificate definition?  If my arguments are true then we can: 1) keep calling it non-repudiation and strongly deprecate its use, 2) change the name and deprecate its use, 3) change the name and allow its use. I favor 1 over 2 over 3. 


At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote:

Speaking as implementer and not design team member, I can live with both
texts since they allow me to do the same thing.

It allows my low level application to add a digital signature supported
by the digital signature bit, where the intention of that application is
to add integrity and origin authentication, while the use of the
signature in practice (higher layers) ends up being used as evidence of
some kind of commitment.

Example. An e-mail application adds an arbitrary signature supported by
the DS bit, while the body of the text reads "Through the digital
signature on this e-mail I commit to....). This is now a perfectly valid
scenario according to both texts.

The real defect that was fixed was that the digital signature bit said
that it was for purposes "other" than NR. That is now gone in both
standards.

I agree to Stephen's rationale to keep the name nonRepudiation. It is
not worth the cost to change the name. Stephen's point here was missing
in the X.509 discussions of a name change.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: den 27 maj 2005 12:29
> To: Stephen Farrell
> Cc: Hoyt L Kesterson II; pkix
> Subject: Re: 3280bis: key usage (13)
>
>
> Stephen,
>
> I agree with everything Hoyt said on bit 1.
>
> However, there are two sides for this coin : bit 0 and bit 1.
>
> Both are again copied below:
>
> ISO Corrigendum:
>
>      a) digitalSignature: for verifying digital signatures that are
used
>         with an entity authentication service, a data origin
> authentication
>         service or/and an integrity service;
>
> 3280bis:
>
>      The digitalSignature bit is asserted when the subject public key
>      is used with a digital signature mechanism to support security
>      services other than certificate signing (bit 5), or CRL signing
>      (bit 6).  Digital signature mechanisms are often used for entity
>      authentication and data origin authentication with integrity.
>
> The current text of 3280bis for bit 0 (ds) is incompatible with the
ISO
> Corrigendum.
>
> As Hoyt already said, any new text should align with the definition in
the
> approved technical corrigenda against the 4th edition and in the
upcoming
> 5th edition.
>
> Denis
>
> > Hi Hoyt,
> >
> > Hoyt L Kesterson II wrote:
> >
> >> Stephen
> >>
> >> I am somewhat dismayed at your reaction to the new text in X.509.
> >
> >
> > I'm sorry about that, but I guess I'm just fed up with the
> > NR bit, though I can understand how people who've worked
> > hard to try fix it might be dismayed.
> >
> > (BTW: I once suggested that CAs MUST set this bit randomly
> > since that was the only way I could see to kill it off
> > properly. If you can get that into X.509 then I'd be happy
> > for 3280bis to align:-)
> >
> >  > I am not going to argue with you here (maybe in a bar the next
time
> >  > we run into each other).
> >
> > Good idea!
> >
> >> However, I do want to mention several points.
> >>
> >> 1) I initiated the change in text because of the various
> interpretations
> >
> >  > by implementors that were resulting in non-interoperable
> >  > implementations. It was a conversation with a PKIXer at a RSA
> >  > conference a few years ago that caused me to articulate a private
> >  > concern.
> >
> > I agree that everything connected with this bit has been
> > confused and remains so.
> >
> >> 2) The legal community was very confused. There was even a
> >
> >  > paper castigating the standard developers for mandating that
> >  > one could not repudiate an action.
> >
> > Maybe the mistake was defining a bit that laywers care about?
> >
> >> 3) There were several meetings held where there was significant
> >
> >  > participation by people in the IETF PKIX group (as well as
> >  > lawyers). All agreed there was a problem with the published text.
> >  > Denis and I argued long and hard over wording but we didn't
> >  > disagree on the need for new text and its general intent.
> >
> > Fair enough.
> >
> >> 4) Russ was concerned that change would cause a problem
> >
> >  > with existing IETF standards and was not too happy with a
> >  > change to the name of the bit. That's why I put the line
> >  > in that you referenced. However, that was to grandfather
> >  > existing text, not to allow new text to continue using
> >  > the old term and definitions.
> >
> > Ok. Here's the real reason not to change: Many people use
> > ASN.1 compilers which means that names from the ASN.1
> > module end up being directly used in higher layer code.
> > Changing the name causes that code not to compile. I'd
> > say that there's quite a lot of 3280 code in the world
> > at this stage. So, if the semantics isn't supposed to
> > have changed (and I assume that is meant to be the
> > case) then this cost just doesn't seem worthwhile.
> >
> >> 5) It is the definition that is important. I recommend
> >
> >  > that any new text align with the definition in the approved
> >  > technical corrigenda against the 4th edition and in
> >  > the upcoming 5th edition.
> >
> > While I'd rather not see any more text added on this,
> > (there's been way too much already) I wouldn't have a big
> > issue with trying to help a reader make sense of the
> > fact that 3280bis and x.509 name this bit differently.
> >
> > However text like the sentence below is IMO almost
> > certain to cause even more confusion:
> >
> >   The precise type of commitment of the signer e.g. "reviewed
> >   and approved" or "with the intent to be bound", may be
> >   signalled by the content being signed, e.g. the signed
> >   document itself or some additional signed information.
> >
> > That sounds like the sole purpose of the CC-bit is as
> > a flag to indicate when some other bits somewhere else
> > tell you what the CC-bit means.
> >
> > So in the absence of some better text I think that 3280bis
> > is better off just saying "NR a.k.a. CC" as it currently
> > does.
> >
> > Regards,
> > Stephen.
> >
> >>
> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
> >>
> >>> Denis,
> >>>
> >>>
> >>>> Please align with the the ISO-ITU text.
> >>>
> >>>
> >>> Do you mean we should rename the bits and include the
> >>> other new x.509 text? The design team were against
> >>> doing that.
> >>>
> >>> Is there any (good) reason other than alignment to
> >>> make such a change?
> >>>
> >>> Personally, I find the new x.509 text worse, although
> >>> it does say: "Note that it is not incorrect to refer to
> >>> this keyUsage bit using the identifier nonRepudiation."
> >>> So I can argue that we are aligned, just not identical.
> >>>
> >>> But of course, I'm from the non-repudiation is non-sense
> >>> camp so I may not be the best judge.
> >>>
> >>> Stephen.
> >>>
> >>> PS: A quibble:
> >>>
> >>>
> >>>>  The new text in X.509 aligns with the text in RFC 3280.  No
changes
> >>>>  are required to 3280bis.  A comment has been added to the ASN.1
for
> >>>>  KeyUsage stating that "recent editions of X.509 have renamed
> >>>>  [the nonRepudiation] bit to contentCommitment"
> >>>>
> >>>> This statement is untrue.
> >>>
> >>>
> >>> The paragraph to which I assume you refer contains 3
> >>> statements - it'd be easier to close these threads if
> >>> you were more precise. (I think I got what you want
> >>> by the end of the mail though...)
> >>>
> >>> PPS: "This statement is untrue."
> >>>    Are you from Crete after all? :-)
> >>>
> >>>
> >>>
> >>>
> >>> Denis Pinkas wrote:
> >>>
> >>>
> >>>> To the list,
> >>>>
> >>>> The disposition of comments states:
> >>>>
> >>>> 13) The descriptions of the meanings of the digitalSignature and
> >>>>    nonRepudiation bits of keyUsage may need to be adjusted based
> >>>>    on the work in X.509
> >>>>
> >>>> The new text in X.509 aligns with the text in RFC 3280.  No
changes
> >>>> are required to 3280bis.  A comment has been added to the ASN.1
for
> >>>> KeyUsage stating that "recent editions of X.509 have renamed
> >>>> [the nonRepudiation] bit to contentCommitment"
> >>>>
> >>>> This statement is untrue.
> >>>>
> >>>> The text from X.509 has been published in Corrigendum 3 (04/2004)
> >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
> >>>>
> >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
> >>>>
> >>>> An extract from this text is copied below:
> >>>>
> >>>> a) digitalSignature: for verifying digital signatures that are
used
> >>>>  with an entity authentication service, a data origin
authentication
> >>>>  service or/and an integrity service;
> >>>>
> >>>> b) contentCommitment: for verifying digital signatures which are
> >>>> intended
> >>>>  to signal that the signer is committing to the content being
signed.
> >>>>  The type of commitment the certificate can be used to support
may be
> >>>>  further constrained by the CA, e.g. through a certificate
policy.
> >>>>  The precise type of commitment of the signer e.g. "reviewed and
> >>>>  approved" or "with the intent to be bound", may be signalled by
the
> >>>>  content being signed, e.g. the signed document itself or some
> >>>> additional
> >>>>  signed information.
> >>>>
> >>>>  Since a content commitment signing is considered to be a
digitally
> >>>> signed
> >>>>  transaction, the digitalSignature bit need not be set in the
> >>>> certificate.
> >>>>  If it is set, it does not affect the level of commitment the
signer
> >>>> has
> >>>>  endowed in the signed content.
> >>>>
> >>>>  Note that it is not incorrect to refer to this keyUsage bit
using
> the
> >>>>  identifier nonRepudiation. However, the use of this identifier
has
> >>>> been
> >>>>  deprecated. Regardless of the identifier used, the semantics of
> >>>> this bit
> >>>>  are as specified in this Directory Specification.
> >>>>
> >>>> The text from 3280 is copied below:
> >>>>
> >>>>     The digitalSignature bit is asserted when the subject public
key
> >>>>     is used with a digital signature mechanism to support
security
> >>>>     services other than certificate signing (bit 5), or CRL
signing
> >>>>     (bit 6).  Digital signature mechanisms are often used for
entity
> >>>>     authentication and data origin authentication with integrity.
> >>>>
> >>>>     The nonRepudiation bit is asserted when the subject public
key is
> >>>>     used to verify digital signatures used to provide a non-
> >>>>     repudiation service which protects against the signing entity
> >>>>     falsely denying some action, excluding certificate or CRL
> signing.
> >>>>     In the case of later conflict, a reliable third party may
> >>>>     determine the authenticity of the signed data.
> >>>>
> >>>>     Further distinctions between the digitalSignature and
> >>>>     nonRepudiation bits may be provided in specific certificate
> >>>>     policies.
> >>>>
> >>>> The text from 3280bis does not align with the ISO-ITU text.
> >>>> Please align with the the ISO-ITU text.
> >>>>
> >>>> Denis
> >>>
> >>
> >>
> >>
> >
> >
>


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    joel.kazin@atosorigin.com
www.atosorigin.com
 ------_=_NextPart_001_01C562BE.91D1CCE2-- From owner-ietf-pkix@mail.imc.org Fri May 27 10:36:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17042 for ; Fri, 27 May 2005 10:36:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDpa9E068685; Fri, 27 May 2005 06:51:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RDpasL068684; Fri, 27 May 2005 06:51:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDpLI7068668 for ; Fri, 27 May 2005 06:51:35 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4RDpAra002230; Fri, 27 May 2005 09:51:11 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4RDoS6u021243; Fri, 27 May 2005 09:50:28 -0400 (EDT) Message-ID: <429725BB.4000105@nist.gov> Date: Fri, 27 May 2005 09:50:51 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas CC: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> <4296F66E.3020406@bull.net> <42971110.5040008@cs.tcd.ie> <429712E8.7050708@bull.net> In-Reply-To: <429712E8.7050708@bull.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Denis, I do not agree with your proposal for the digitalSignature bit. Here is the current text: The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. This text merely states that setting the digitalSignature bit, by itself, does not authorize relying parties to use the subject public key to verify signatures on certificates or CRLs. It does not prevent a CA from setting digitalSignature, keyCertSign, and cRLSign in the same certificate. Imposing this restriction would, for example, prevent a CA from using its certificate signing key to also sign OCSP responses. Denis Pinkas wrote: > Stephen, > > Just before leaving my office in a few minutes for a few days, > here is a new text proposal for the DS bit: > > New proposal for 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service. However, it SHALL not be set > when certificate signing (bit 5) or CRL signing (bit 6) is set. > > Denis From owner-ietf-pkix@mail.imc.org Fri May 27 11:46:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21825 for ; Fri, 27 May 2005 11:46:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REhutQ074306; Fri, 27 May 2005 07:43:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4REhurc074305; Fri, 27 May 2005 07:43:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REhtRc074298 for ; Fri, 27 May 2005 07:43:55 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4REhq8e021374 for ; Fri, 27 May 2005 10:43:53 -0400 From: "Santosh Chokhani" To: "'pkix'" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 10:43:47 -0400 Message-ID: <003001c562ca$803aa510$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C562A8.F9290510" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <5.1.0.14.0.20050527090001.00b128d0@172.16.146.192> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C562A8.F9290510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X.509 V1 or V2 did not have any extensions. Thus, neither key usage nor certificate policies were part of v1 or v2. These extensions came about = in v3. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Kazin, Joel Sent: Friday, May 27, 2005 9:20 AM To: Stefan Santesson; Denis Pinkas; Stephen Farrell Cc: Hoyt L Kesterson II; pkix Subject: RE: 3280bis: key usage (13) The core problem is labeling the bit non-repudiation. It goes against = the legal idea that you can attempt to repudiate your alleged actions even = when your defense is weaker than "the cat ate my homework". To me, non-repudiation is more of a marketing description than a technical, contractual, or legal description of what the signer intended to do. =20 A secondary problem is that the non-repudiation bit doesn't tell a = relying party or third party enough. The logical place to look for such = information is in the id-ce-certificatePolicies extension. Was the id-ce-certificatePolicies extension part of the original x.509 v1 specification? If that is true, then perhaps the non-repudiation bit is just a holdover from the original x.509 v1 certificate definition? If = my arguments are true then we can: 1) keep calling it non-repudiation and strongly deprecate its use, 2) change the name and deprecate its use, 3) change the name and allow its use. I favor 1 over 2 over 3. =20 At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote: Speaking as implementer and not design team member, I can live with both = texts since they allow me to do the same thing.=20 It allows my low level application to add a digital signature supported=20 by the digital signature bit, where the intention of that application is = to add integrity and origin authentication, while the use of the=20 signature in practice (higher layers) ends up being used as evidence of=20 some kind of commitment.=20 Example. An e-mail application adds an arbitrary signature supported by=20 the DS bit, while the body of the text reads "Through the digital=20 signature on this e-mail I commit to....). This is now a perfectly valid = scenario according to both texts.=20 The real defect that was fixed was that the digital signature bit said=20 that it was for purposes "other" than NR. That is now gone in both=20 standards.=20 I agree to Stephen's rationale to keep the name nonRepudiation. It is=20 not worth the cost to change the name. Stephen's point here was missing=20 in the X.509 discussions of a name change.=20 Stefan Santesson=20 Program Manager, Standards Liaison=20 Windows Security=20 =20 > -----Original Message-----=20 > From: owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org]=20 > On Behalf Of Denis Pinkas=20 > Sent: den 27 maj 2005 12:29=20 > To: Stephen Farrell=20 > Cc: Hoyt L Kesterson II; pkix=20 > Subject: Re: 3280bis: key usage (13)=20 >=20 >=20 > Stephen,=20 >=20 > I agree with everything Hoyt said on bit 1.=20 >=20 > However, there are two sides for this coin : bit 0 and bit 1.=20 >=20 > Both are again copied below:=20 >=20 > ISO Corrigendum:=20 >=20 > a) digitalSignature: for verifying digital signatures that are=20 used=20 > with an entity authentication service, a data origin=20 > authentication=20 > service or/and an integrity service;=20 >=20 > 3280bis:=20 >=20 > The digitalSignature bit is asserted when the subject public key=20 > is used with a digital signature mechanism to support security=20 > services other than certificate signing (bit 5), or CRL signing=20 > (bit 6). Digital signature mechanisms are often used for entity=20 > authentication and data origin authentication with integrity.=20 >=20 > The current text of 3280bis for bit 0 (ds) is incompatible with the=20 ISO=20 > Corrigendum.=20 >=20 > As Hoyt already said, any new text should align with the definition in = the=20 > approved technical corrigenda against the 4th edition and in the=20 upcoming=20 > 5th edition.=20 >=20 > Denis=20 >=20 > > Hi Hoyt,=20 > >=20 > > Hoyt L Kesterson II wrote:=20 > >=20 > >> Stephen=20 > >>=20 > >> I am somewhat dismayed at your reaction to the new text in X.509.=20 > >=20 > >=20 > > I'm sorry about that, but I guess I'm just fed up with the=20 > > NR bit, though I can understand how people who've worked=20 > > hard to try fix it might be dismayed.=20 > >=20 > > (BTW: I once suggested that CAs MUST set this bit randomly=20 > > since that was the only way I could see to kill it off=20 > > properly. If you can get that into X.509 then I'd be happy=20 > > for 3280bis to align:-)=20 > >=20 > > > I am not going to argue with you here (maybe in a bar the next=20 time=20 > > > we run into each other).=20 > >=20 > > Good idea!=20 > >=20 > >> However, I do want to mention several points.=20 > >>=20 > >> 1) I initiated the change in text because of the various=20 > interpretations=20 > >=20 > > > by implementors that were resulting in non-interoperable=20 > > > implementations. It was a conversation with a PKIXer at a RSA=20 > > > conference a few years ago that caused me to articulate a private = > > > concern.=20 > >=20 > > I agree that everything connected with this bit has been=20 > > confused and remains so.=20 > >=20 > >> 2) The legal community was very confused. There was even a=20 > >=20 > > > paper castigating the standard developers for mandating that=20 > > > one could not repudiate an action.=20 > >=20 > > Maybe the mistake was defining a bit that laywers care about?=20 > >=20 > >> 3) There were several meetings held where there was significant=20 > >=20 > > > participation by people in the IETF PKIX group (as well as=20 > > > lawyers). All agreed there was a problem with the published text. = > > > Denis and I argued long and hard over wording but we didn't=20 > > > disagree on the need for new text and its general intent.=20 > >=20 > > Fair enough.=20 > >=20 > >> 4) Russ was concerned that change would cause a problem=20 > >=20 > > > with existing IETF standards and was not too happy with a=20 > > > change to the name of the bit. That's why I put the line=20 > > > in that you referenced. However, that was to grandfather=20 > > > existing text, not to allow new text to continue using=20 > > > the old term and definitions.=20 > >=20 > > Ok. Here's the real reason not to change: Many people use=20 > > ASN.1 compilers which means that names from the ASN.1=20 > > module end up being directly used in higher layer code.=20 > > Changing the name causes that code not to compile. I'd=20 > > say that there's quite a lot of 3280 code in the world=20 > > at this stage. So, if the semantics isn't supposed to=20 > > have changed (and I assume that is meant to be the=20 > > case) then this cost just doesn't seem worthwhile.=20 > >=20 > >> 5) It is the definition that is important. I recommend=20 > >=20 > > > that any new text align with the definition in the approved=20 > > > technical corrigenda against the 4th edition and in=20 > > > the upcoming 5th edition.=20 > >=20 > > While I'd rather not see any more text added on this,=20 > > (there's been way too much already) I wouldn't have a big=20 > > issue with trying to help a reader make sense of the=20 > > fact that 3280bis and x.509 name this bit differently.=20 > >=20 > > However text like the sentence below is IMO almost=20 > > certain to cause even more confusion:=20 > >=20 > > The precise type of commitment of the signer e.g. "reviewed=20 > > and approved" or "with the intent to be bound", may be=20 > > signalled by the content being signed, e.g. the signed=20 > > document itself or some additional signed information.=20 > >=20 > > That sounds like the sole purpose of the CC-bit is as=20 > > a flag to indicate when some other bits somewhere else=20 > > tell you what the CC-bit means.=20 > >=20 > > So in the absence of some better text I think that 3280bis=20 > > is better off just saying "NR a.k.a. CC" as it currently=20 > > does.=20 > >=20 > > Regards,=20 > > Stephen.=20 > >=20 > >>=20 > >> At 14:49 +0100 5/26/05, Stephen Farrell wrote:=20 > >>=20 > >>> Denis,=20 > >>>=20 > >>>=20 > >>>> Please align with the the ISO-ITU text.=20 > >>>=20 > >>>=20 > >>> Do you mean we should rename the bits and include the=20 > >>> other new x.509 text? The design team were against=20 > >>> doing that.=20 > >>>=20 > >>> Is there any (good) reason other than alignment to=20 > >>> make such a change?=20 > >>>=20 > >>> Personally, I find the new x.509 text worse, although=20 > >>> it does say: "Note that it is not incorrect to refer to=20 > >>> this keyUsage bit using the identifier nonRepudiation."=20 > >>> So I can argue that we are aligned, just not identical.=20 > >>>=20 > >>> But of course, I'm from the non-repudiation is non-sense=20 > >>> camp so I may not be the best judge.=20 > >>>=20 > >>> Stephen.=20 > >>>=20 > >>> PS: A quibble:=20 > >>>=20 > >>>=20 > >>>> The new text in X.509 aligns with the text in RFC 3280. No=20 changes=20 > >>>> are required to 3280bis. A comment has been added to the ASN.1=20 for=20 > >>>> KeyUsage stating that "recent editions of X.509 have renamed=20 > >>>> [the nonRepudiation] bit to contentCommitment"=20 > >>>>=20 > >>>> This statement is untrue.=20 > >>>=20 > >>>=20 > >>> The paragraph to which I assume you refer contains 3=20 > >>> statements - it'd be easier to close these threads if=20 > >>> you were more precise. (I think I got what you want=20 > >>> by the end of the mail though...)=20 > >>>=20 > >>> PPS: "This statement is untrue."=20 > >>> Are you from Crete after all? :-)=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Denis Pinkas wrote:=20 > >>>=20 > >>>=20 > >>>> To the list,=20 > >>>>=20 > >>>> The disposition of comments states:=20 > >>>>=20 > >>>> 13) The descriptions of the meanings of the digitalSignature and=20 > >>>> nonRepudiation bits of keyUsage may need to be adjusted based=20 > >>>> on the work in X.509=20 > >>>>=20 > >>>> The new text in X.509 aligns with the text in RFC 3280. No=20 changes=20 > >>>> are required to 3280bis. A comment has been added to the ASN.1=20 for=20 > >>>> KeyUsage stating that "recent editions of X.509 have renamed=20 > >>>> [the nonRepudiation] bit to contentCommitment"=20 > >>>>=20 > >>>> This statement is untrue.=20 > >>>>=20 > >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) = > >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called=20 > >>>>=20 > >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).=20 > >>>>=20 > >>>> An extract from this text is copied below:=20 > >>>>=20 > >>>> a) digitalSignature: for verifying digital signatures that are=20 used=20 > >>>> with an entity authentication service, a data origin=20 authentication=20 > >>>> service or/and an integrity service;=20 > >>>>=20 > >>>> b) contentCommitment: for verifying digital signatures which are=20 > >>>> intended=20 > >>>> to signal that the signer is committing to the content being=20 signed.=20 > >>>> The type of commitment the certificate can be used to support=20 may be=20 > >>>> further constrained by the CA, e.g. through a certificate=20 policy.=20 > >>>> The precise type of commitment of the signer e.g. "reviewed and=20 > >>>> approved" or "with the intent to be bound", may be signalled by=20 the=20 > >>>> content being signed, e.g. the signed document itself or some=20 > >>>> additional=20 > >>>> signed information.=20 > >>>>=20 > >>>> Since a content commitment signing is considered to be a=20 digitally=20 > >>>> signed=20 > >>>> transaction, the digitalSignature bit need not be set in the=20 > >>>> certificate.=20 > >>>> If it is set, it does not affect the level of commitment the=20 signer=20 > >>>> has=20 > >>>> endowed in the signed content.=20 > >>>>=20 > >>>> Note that it is not incorrect to refer to this keyUsage bit=20 using=20 > the=20 > >>>> identifier nonRepudiation. However, the use of this identifier=20 has=20 > >>>> been=20 > >>>> deprecated. Regardless of the identifier used, the semantics of=20 > >>>> this bit=20 > >>>> are as specified in this Directory Specification.=20 > >>>>=20 > >>>> The text from 3280 is copied below:=20 > >>>>=20 > >>>> The digitalSignature bit is asserted when the subject public=20 key=20 > >>>> is used with a digital signature mechanism to support=20 security=20 > >>>> services other than certificate signing (bit 5), or CRL=20 signing=20 > >>>> (bit 6). Digital signature mechanisms are often used for=20 entity=20 > >>>> authentication and data origin authentication with integrity. = > >>>>=20 > >>>> The nonRepudiation bit is asserted when the subject public=20 key is=20 > >>>> used to verify digital signatures used to provide a non-=20 > >>>> repudiation service which protects against the signing entity = > >>>> falsely denying some action, excluding certificate or CRL=20 > signing.=20 > >>>> In the case of later conflict, a reliable third party may=20 > >>>> determine the authenticity of the signed data.=20 > >>>>=20 > >>>> Further distinctions between the digitalSignature and=20 > >>>> nonRepudiation bits may be provided in specific certificate=20 > >>>> policies.=20 > >>>>=20 > >>>> The text from 3280bis does not align with the ISO-ITU text.=20 > >>>> Please align with the the ISO-ITU text.=20 > >>>>=20 > >>>> Denis=20 > >>>=20 > >>=20 > >>=20 > >>=20 > >=20 > >=20 >=20 Joel S. Kazin CPA, CISA, CISSP, CISM Senior Consultant Atos Origin 40 Old Sleepy Hollow Road Pleasantville, New York 10570-3802 USA Phone +1 914-769-8780 Mobile +1 914-564-1484 email joel.kazin@atosorigin.com www.atosorigin.com =20 ------=_NextPart_000_0031_01C562A8.F9290510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

X.509 V1 or V2 did not have any = extensions.  Thus,=20 neither key usage nor certificate policies were part of v1 or v2.  = These=20 extensions came about in v3.
-----Original Message-----
From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On=20 Behalf Of Kazin, Joel
Sent: Friday, May 27, 2005 9:20=20 AM
To: Stefan Santesson; Denis Pinkas; Stephen = Farrell
Cc:=20 Hoyt L Kesterson II; pkix
Subject: RE: 3280bis: key usage=20 (13)

The core problem is labeling the bit=20 non-repudiation.  It goes against the legal idea that you can = attempt to=20 repudiate your alleged actions even when your defense is weaker than = "the cat=20 ate my homework".  To me, non-repudiation is more of a marketing=20 description than a technical, contractual, or legal description of = what the=20 signer intended to do. 

A secondary problem is that the=20 non-repudiation bit doesn't tell a relying party or third party = enough. =20 The logical place to look for such information is in the=20 id-ce-certificatePolicies extension.  Was the = id-ce-certificatePolicies=20 extension part of the original x.509 v1 specification?  If that = is true,=20 then perhaps the non-repudiation bit is just a holdover from the = original=20 x.509 v1 certificate definition?  If my arguments are true then = we can:=20 1) keep calling it non-repudiation and strongly deprecate its use, 2) = change=20 the name and deprecate its use, 3) change the name and allow its use. = I favor=20 1 over 2 over 3. 


At 07:06 AM 5/27/2005 -0500, Stefan = Santesson wrote:

Speaking as=20 implementer and not design team member, I can live with both=20
texts since they allow me to do the same = thing.=20

It allows my low level application to add a = digital=20 signature supported
by the digital = signature bit,=20 where the intention of that application is
to add=20 integrity and origin authentication, while the use of the =
signature in practice (higher layers) ends up being used as = evidence=20 of
some kind of commitment. =

Example. An e-mail application adds an arbitrary signature = supported=20 by
the DS bit, while the body of the text = reads=20 "Through the digital
signature on this = e-mail I=20 commit to....). This is now a perfectly valid
scenario according to both texts.

The=20 real defect that was fixed was that the digital signature bit = said=20
that it was for purposes "other" than NR. That is = now gone=20 in both
standards.

I=20 agree to Stephen's rationale to keep the name nonRepudiation. It = is=20
not worth the cost to change the name. Stephen's = point here=20 was missing
in the X.509 discussions of a = name=20 change.

Stefan Santesson =
Program Manager, Standards Liaison
Windows=20 Security
 

>=20 -----Original Message-----
> From:=20 owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.= imc.org]=20
> On Behalf Of Denis Pinkas
>=20 Sent: den 27 maj 2005 12:29
> To: = Stephen=20 Farrell
> Cc: Hoyt L Kesterson II; = pkix=20
> Subject: Re: 3280bis: key usage (13) =
>
>
>=20 Stephen,
>
> I agree=20 with everything Hoyt said on bit 1.
>=20
> However, there are two sides for this = coin :=20 bit 0 and bit 1.
>
>=20 Both are again copied below:
> =
> ISO Corrigendum:
> =
>      a) digitalSignature: for = verifying=20 digital signatures that are
used =
>         with = an entity=20 authentication service, a data origin
> = authentication
>         = service or/and=20 an integrity service;
> =
> 3280bis:
> =
>      The digitalSignature bit = is=20 asserted when the subject public key
>      is used with a digital = signature=20 mechanism to support security
>      services other than = certificate=20 signing (bit 5), or CRL signing
>      (bit 6).  Digital = signature=20 mechanisms are often used for entity
>      authentication and data = origin=20 authentication with integrity.
> =
> The current text of 3280bis for bit 0 (ds) is = incompatible with=20 the
ISO
>=20 Corrigendum.
>
> As=20 Hoyt already said, any new text should align with the definition = in=20
the
> approved = technical=20 corrigenda against the 4th edition and in the
upcoming
> 5th edition. =
>
> Denis
>=20
> > Hi Hoyt,
>=20 >
> > Hoyt L Kesterson II = wrote:=20
> >
> >> = Stephen
> >>
>=20 >> I am somewhat dismayed at your reaction to the new text in=20 X.509.
> >
>=20 >
> > I'm sorry about that, but I = guess I'm=20 just fed up with the
> > NR bit, = though I can=20 understand how people who've worked
> = > hard=20 to try fix it might be dismayed.
> = >=20
> > (BTW: I once suggested that CAs MUST = set this bit=20 randomly
> > since that was the only = way I=20 could see to kill it off
> > = properly. If you=20 can get that into X.509 then I'd be happy
> >=20 for 3280bis to align:-)
> > =
> >  > I am not going to argue with you here = (maybe in=20 a bar the next
time
>=20 >  > we run into each other).
>=20 >
> > Good idea!
> >
> >> However, = I do want to=20 mention several points.
> = >>=20
> >> 1) I initiated the change in text = because of=20 the various
> interpretations =
> >
> >  > by = implementors that were resulting in non-interoperable =
> >  > implementations. It was a conversation = with a=20 PKIXer at a RSA
> >  > = conference a=20 few years ago that caused me to articulate a private =
> >  > concern.
>=20 >
> > I agree that everything = connected=20 with this bit has been
> > confused = and=20 remains so.
> >
>=20 >> 2) The legal community was very confused. There was even = a=20
> >
> = >  >=20 paper castigating the standard developers for mandating that=20
> >  > one could not repudiate an=20 action.
> >
> >=20 Maybe the mistake was defining a bit that laywers care about? =
> >
> >> = 3) There=20 were several meetings held where there was significant =
> >
> >  > = participation=20 by people in the IETF PKIX group (as well as
>=20 >  > lawyers). All agreed there was a problem with the = published=20 text.
> >  > Denis and I = argued long=20 and hard over wording but we didn't
> = > =20 > disagree on the need for new text and its general = intent.=20
> >
> > = Fair=20 enough.
> >
>=20 >> 4) Russ was concerned that change would cause a = problem=20
> >
> = >  > with=20 existing IETF standards and was not too happy with a =
> >  > change to the name of the bit. That's = why I put=20 the line
> >  > in that you=20 referenced. However, that was to grandfather
>=20 >  > existing text, not to allow new text to continue=20 using
> >  > the old term = and=20 definitions.
> >
>=20 > Ok. Here's the real reason not to change: Many people = use=20
> > ASN.1 compilers which means that names = from the=20 ASN.1
> > module end up being = directly used in=20 higher layer code.
> > Changing the = name=20 causes that code not to compile. I'd
> = > say=20 that there's quite a lot of 3280 code in the world
> > at this stage. So, if the semantics isn't = supposed=20 to
> > have changed (and I assume = that is=20 meant to be the
> > case) then this = cost just=20 doesn't seem worthwhile.
> > =
> >> 5) It is the definition that is important. I=20 recommend
> >
>=20 >  > that any new text align with the definition in the=20 approved
> >  > technical = corrigenda=20 against the 4th edition and in
> = >  >=20 the upcoming 5th edition.
> > =
> > While I'd rather not see any more text added on=20 this,
> > (there's been way too much = already)=20 I wouldn't have a big
> > issue with = trying to=20 help a reader make sense of the
> > = fact that=20 3280bis and x.509 name this bit differently.
>=20 >
> > However text like the = sentence below=20 is IMO almost
> > certain to cause = even more=20 confusion:
> >
>=20 >   The precise type of commitment of the signer e.g.=20 "reviewed
> >   and = approved" or=20 "with the intent to be bound", may be
> = >   signalled by the content being signed, e.g. the=20 signed
> >   document = itself or some=20 additional signed information.
> = >=20
> > That sounds like the sole purpose of = the CC-bit=20 is as
> > a flag to indicate when = some other=20 bits somewhere else
> > tell you = what the=20 CC-bit means.
> >
>=20 > So in the absence of some better text I think that = 3280bis=20
> > is better off just saying "NR a.k.a. = CC" as it=20 currently
> > does.
> >
> > = Regards,
> > Stephen.
> = >
> >>
> >> At = 14:49 +0100=20 5/26/05, Stephen Farrell wrote:
> = >>=20
> >>> Denis,
>=20 >>>
> >>> =
> >>>> Please align with the the ISO-ITU = text.=20
> >>>
>=20 >>>
> >>> Do you mean = we should=20 rename the bits and include the
> = >>>=20 other new x.509 text? The design team were against
> >>> doing that.
>=20 >>>
> >>> Is there = any (good)=20 reason other than alignment to
> = >>>=20 make such a change?
> = >>>=20
> >>> Personally, I find the new = x.509 text=20 worse, although
> >>> it does = say: "Note=20 that it is not incorrect to refer to
>=20 >>> this keyUsage bit using the identifier = nonRepudiation."=20
> >>> So I can argue that we are = aligned, just=20 not identical.
> >>> =
> >>> But of course, I'm from the = non-repudiation is=20 non-sense
> >>> camp so I may = not be the=20 best judge.
> >>> =
> >>> Stephen.
>=20 >>>
> >>> PS: A = quibble:=20
> >>>
>=20 >>>
> >>>>  = The new=20 text in X.509 aligns with the text in RFC 3280.  No =
changes
> = >>>>  are=20 required to 3280bis.  A comment has been added to the = ASN.1=20
for
> = >>>> =20 KeyUsage stating that "recent editions of X.509 have renamed=20
> >>>>  [the nonRepudiation] = bit to=20 contentCommitment"
> = >>>>=20
> >>>> This statement is = untrue.=20
> >>>
>=20 >>>
> >>> The = paragraph to=20 which I assume you refer contains 3
>=20 >>> statements - it'd be easier to close these threads = if=20
> >>> you were more precise. (I think = I got=20 what you want
> >>> by the end = of the=20 mail though...)
> >>> =
> >>> PPS: "This statement is untrue." =
> >>>    Are you from Crete = after all?=20 :-)
> >>>
>=20 >>>
> >>> =
> >>>
> = >>> Denis=20 Pinkas wrote:
> >>> =
> >>>
> = >>>> To=20 the list,
> >>>> =
> >>>> The disposition of comments = states:=20
> >>>>
>=20 >>>> 13) The descriptions of the meanings of the=20 digitalSignature and
>=20 >>>>    nonRepudiation bits of keyUsage = may need=20 to be adjusted based
>=20 >>>>    on the work in X.509 =
> >>>>
> = >>>>=20 The new text in X.509 aligns with the text in RFC 3280.  = No=20
changes
> = >>>> are=20 required to 3280bis.  A comment has been added to the = ASN.1=20
for
> = >>>> KeyUsage=20 stating that "recent editions of X.509 have renamed
> >>>> [the nonRepudiation] bit to=20 contentCommitment"
> = >>>>=20
> >>>> This statement is = untrue.=20
> >>>>
>=20 >>>> The text from X.509 has been published in = Corrigendum 3=20 (04/2004)
> >>>> on pages 4 = and 5=20 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
>=20 >>>>
> >>>> = ITU-T Rec.=20 X.509 (2000)/Cor.3 (04/2004)).
>=20 >>>>
> >>>> An = extract=20 from this text is copied below:
>=20 >>>>
> >>>> a)=20 digitalSignature: for verifying digital signatures that are =
used
> >>>>  = with an=20 entity authentication service, a data origin
authentication
> = >>>> =20 service or/and an integrity service;
>=20 >>>>
> >>>> b)=20 contentCommitment: for verifying digital signatures which are =
> >>>> intended
>=20 >>>>  to signal that the signer is committing to = the=20 content being
signed.
>=20 >>>>  The type of commitment the certificate can be = used to=20 support
may be
>=20 >>>>  further constrained by the CA, e.g. through a = certificate
policy.
>=20 >>>>  The precise type of commitment of the signer = e.g.=20 "reviewed and
> >>>>  = approved"=20 or "with the intent to be bound", may be signalled by =
the
> >>>>  = content being=20 signed, e.g. the signed document itself or some
>=20 >>>> additional
>=20 >>>>  signed information.
>=20 >>>>
> = >>>>  Since a=20 content commitment signing is considered to be a
digitally
> >>>> = signed=20
> >>>>  transaction, the=20 digitalSignature bit need not be set in the
>=20 >>>> certificate.
>=20 >>>>  If it is set, it does not affect the level of = commitment the
signer
>=20 >>>> has
> = >>>> =20 endowed in the signed content.
>=20 >>>>
> = >>>>  Note=20 that it is not incorrect to refer to this keyUsage bit =
using
> the
>=20 >>>>  identifier nonRepudiation. However, the use = of this=20 identifier
has
>=20 >>>> been
> = >>>> =20 deprecated. Regardless of the identifier used, the semantics = of=20
> >>>> this bit
>=20 >>>>  are as specified in this Directory=20 Specification.
> = >>>>=20
> >>>> The text from 3280 is = copied=20 below:
> >>>> =
> >>>>     The = digitalSignature=20 bit is asserted when the subject public
key=20
> >>>>     is = used with=20 a digital signature mechanism to support
security
>=20 >>>>     services other than = certificate=20 signing (bit 5), or CRL
signing =
> >>>>     (bit = 6).  Digital=20 signature mechanisms are often used for
entity
>=20 >>>>     authentication and data = origin=20 authentication with integrity.
>=20 >>>>
>=20 >>>>     The nonRepudiation bit is = asserted=20 when the subject public
key is =
> >>>>     used to = verify digital=20 signatures used to provide a non-
>=20 >>>>     repudiation service which = protects=20 against the signing entity
>=20 >>>>     falsely denying some = action,=20 excluding certificate or CRL
> = signing.=20
> >>>>     In = the case=20 of later conflict, a reliable third party may
>=20 >>>>     determine the authenticity = of the=20 signed data.
> >>>> =
> >>>>     Further = distinctions=20 between the digitalSignature and
>=20 >>>>     nonRepudiation bits may be = provided=20 in specific certificate
>=20 >>>>     policies.
> >>>>
> = >>>>=20 The text from 3280bis does not align with the ISO-ITU text. =
> >>>> Please align with the the ISO-ITU = text.=20
> >>>>
>=20 >>>> Denis
> = >>>=20
> >>
> = >>=20
> >>
> = >=20
> >
>=20


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior=20 Consultant
Atos Origin
40 Old Sleepy Hollow = Road
Pleasantville, New=20 York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  = +1=20 914-564-1484
email   =20 joel.kazin@atosorigin.com
www.atosorigin.com

------=_NextPart_000_0031_01C562A8.F9290510-- From owner-ietf-pkix@mail.imc.org Fri May 27 11:53:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22127 for ; Fri, 27 May 2005 11:53:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REwfmB076175; Fri, 27 May 2005 07:58:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4REwftT076174; Fri, 27 May 2005 07:58:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REweja076150 for ; Fri, 27 May 2005 07:58:40 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4REwb8e004613 for ; Fri, 27 May 2005 10:58:39 -0400 From: "Santosh Chokhani" To: "'pkix'" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 10:58:32 -0400 Message-ID: <003d01c562cc$90550ab0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <429725BB.4000105@nist.gov> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I agree with David Cooper. In addition to David's argument, Dennis's proposal will also break many known PKI implementation for no security or interoperability reasons. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper Sent: Friday, May 27, 2005 9:51 AM To: Denis Pinkas Cc: pkix Subject: Re: 3280bis: key usage (13) Denis, I do not agree with your proposal for the digitalSignature bit. Here is the current text: The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. This text merely states that setting the digitalSignature bit, by itself, does not authorize relying parties to use the subject public key to verify signatures on certificates or CRLs. It does not prevent a CA from setting digitalSignature, keyCertSign, and cRLSign in the same certificate. Imposing this restriction would, for example, prevent a CA from using its certificate signing key to also sign OCSP responses. Denis Pinkas wrote: > Stephen, > > Just before leaving my office in a few minutes for a few days, here is > a new text proposal for the DS bit: > > New proposal for 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service. However, it SHALL not be set > when certificate signing (bit 5) or CRL signing (bit 6) is set. > > Denis From owner-ietf-pkix@mail.imc.org Fri May 27 11:54:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22182 for ; Fri, 27 May 2005 11:54:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REtfr9075214; Fri, 27 May 2005 07:55:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4REtfVk075213; Fri, 27 May 2005 07:55:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REtec3075180 for ; Fri, 27 May 2005 07:55:40 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id BBEA114C067; Fri, 27 May 2005 15:55:32 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A01EA0B5AB8; Fri, 27 May 2005 15:55:32 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id 8DC6B14C067; Fri, 27 May 2005 15:55:32 +0100 (IST) Message-ID: <429735DB.9010905@cs.tcd.ie> Date: Fri, 27 May 2005 15:59:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: 3280bis: key usage (13) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.733) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A11EA0B5AB8 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, Peter Gutmann wrote: > Wouldn't it be better to say that it's used for purposes other than CC? By > saying that DS can only be used for purposes A, B, and C, and CC for purpose > D, what happens if someone wants to mark a key for purpose E? Since CC seems > to be the more restrictive, it would be better to say that DS is to be used > for everything else. If not, we'd need a third signature bit to cover the > 'other' category that's explicitly excluded from DS and CC. You're kidding, right? There's a bit (NR/CC) whose meaning has been the subject of loads and loads of rambling discussion for ages and ages, and you want to define DS=NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a bad idea. >>However, it SHALL not be set when certificate signing (bit 5) or CRL signing >>(bit 6) is set. > > Why not? The intent of the original text was to say that > digitalSignature doesn't mean you can use the cert for cert/CRL > signing, now it says something completely different, that a > cert-signing cert can never be used for any other purpose. This > wording change would make a number of CAs non-compliant, since > they do use their CA certs for other purposes (don't ask me why, > I just see the things turn up from time to time). The wording > should be something like "Setting this bit doesn't mean the > cert can be used for cert or CRL signing; for that, you need > to set the cert/CRL signing bits". You're right there (as is David C.) So we should replace Denis' last sentence with something like yours, giving maybe: The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures that are used with an entity authentication service, a data origin authentication service or/and an integrity service. Note that a certificate with only the digitalSignature bit set MUST NOT be used for verifying certificate or CRL signatures. And the certificate and CRL signing bits are described elsewhere. Stephen. From owner-ietf-pkix@mail.imc.org Fri May 27 12:03:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22671 for ; Fri, 27 May 2005 12:03:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFFvXS078622; Fri, 27 May 2005 08:15:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RFFv9j078621; Fri, 27 May 2005 08:15:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFFtdV078612 for ; Fri, 27 May 2005 08:15:55 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id DA4A334B2C; Sat, 28 May 2005 03:15:54 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06518-25; Sat, 28 May 2005 03:15:54 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 98EA4349B4; Sat, 28 May 2005 03:15:54 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 249A837756; Sat, 28 May 2005 03:15:54 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DbgZ9-0000B3-00; Sat, 28 May 2005 03:16:03 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, stephen.farrell@cs.tcd.ie Subject: Re: 3280bis: key usage (13) Cc: Denis.Pinkas@bull.net, ietf-pkix@imc.org In-Reply-To: <429735DB.9010905@cs.tcd.ie> Message-Id: Date: Sat, 28 May 2005 03:16:03 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephen Farrell writes: >There's a bit (NR/CC) whose meaning has been the subject of loads and loads >of rambling discussion for ages and ages, and you want to define DS= >NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a >bad idea. Oh was that what all that was about? I'd gone off to reorganise my sock drawer and sort my packets of alphabet soup after the first 800 or so messages went by, so I probably missed some bits. The motivation for the comment was that we've just gone through the keyEncipherment vs. dataEncipherment debate where no-one's quite sure which bits to set for what occasion, and now in an attempt to fix the equally- problematic DS vs. NR we're creating a similar problem: what do you do in situations where neither the DS nor CC/NR bits fit? I don't really care how the bits are defined, as long as it doesn't end up creating un-uses that can't be clearly signified with either DS or CC/NR. Without this, we'll get another situation like the dataEncipherment one where something doesn't fall easily into either choice, so users and CAs claim that their choice of DS or CC applies, whatever happens to coincide with what their software does. > The digitalSignature bit is asserted when the subject public key > is used for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service. Note that a certificate > with only the digitalSignature bit set MUST NOT be used for > verifying certificate or CRL signatures. Sounds good to me. Peter. From owner-ietf-pkix@mail.imc.org Fri May 27 12:05:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22765 for ; Fri, 27 May 2005 12:05:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFDgbm078382; Fri, 27 May 2005 08:13:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RFDgis078381; Fri, 27 May 2005 08:13:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFDfxK078355 for ; Fri, 27 May 2005 08:13:41 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 16:13:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 16:13:33 +0100 Message-ID: Thread-Topic: 3280bis: key usage (13) Thread-Index: AcViylkAK5peyTz2SUqD3Eki9N1xcAAA9amQ From: "Stefan Santesson" To: "David A. Cooper" , "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 27 May 2005 15:13:35.0616 (UTC) FILETIME=[A7193800:01C562CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4RFDfxK078375 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Agree with David. We need to preserve the old logic in this regard. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of David A. Cooper > Sent: den 27 maj 2005 15:51 > To: Denis Pinkas > Cc: pkix > Subject: Re: 3280bis: key usage (13) > > > Denis, > > I do not agree with your proposal for the digitalSignature bit. Here is > the current text: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > This text merely states that setting the digitalSignature bit, by > itself, does not authorize relying parties to use the subject public key > to verify signatures on certificates or CRLs. It does not prevent a CA > from setting digitalSignature, keyCertSign, and cRLSign in the same > certificate. > > Imposing this restriction would, for example, prevent a CA from using > its certificate signing key to also sign OCSP responses. > > Denis Pinkas wrote: > > > Stephen, > > > > Just before leaving my office in a few minutes for a few days, > > here is a new text proposal for the DS bit: > > > > New proposal for 3280bis: > > > > The digitalSignature bit is asserted when the subject public key > > is used for verifying digital signatures that are used > > with an entity authentication service, a data origin authentication > > service or/and an integrity service. However, it SHALL not be set > > when certificate signing (bit 5) or CRL signing (bit 6) is set. > > > > Denis From owner-ietf-pkix@mail.imc.org Fri May 27 12:12:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23204 for ; Fri, 27 May 2005 12:12:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFLa69078973; Fri, 27 May 2005 08:21:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RFLZux078972; Fri, 27 May 2005 08:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFLYOR078962 for ; Fri, 27 May 2005 08:21:35 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 17BE414C029; Fri, 27 May 2005 16:21:29 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A0285F0B713; Fri, 27 May 2005 16:21:29 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id E935A14C029; Fri, 27 May 2005 16:21:28 +0100 (IST) Message-ID: <42973BF1.1080207@cs.tcd.ie> Date: Fri, 27 May 2005 16:25:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: 3280bis: key usage (13) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.734) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A1285F0B713 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, > The motivation for the comment was that we've just gone through the > keyEncipherment vs. dataEncipherment debate where no-one's quite sure which > bits to set for what occasion, and now in an attempt to fix the equally- > problematic DS vs. NR we're creating a similar problem: [...] Fair enough. Problem is we'll apparently never get agreement on what NR/CC means:-( >> The digitalSignature bit is asserted when the subject public key >> is used for verifying digital signatures that are used >> with an entity authentication service, a data origin authentication >> service or/and an integrity service. Note that a certificate >> with only the digitalSignature bit set MUST NOT be used for >> verifying certificate or CRL signatures. > > Sounds good to me. Cool. Let's see what happens when Denis get back so, Stephen. From owner-ietf-pkix@mail.imc.org Fri May 27 13:34:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01225 for ; Fri, 27 May 2005 13:34:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RGmbUl091491; Fri, 27 May 2005 09:48:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RGmbl3091490; Fri, 27 May 2005 09:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RGmacA091477 for ; Fri, 27 May 2005 09:48:36 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 17:48:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 17:48:28 +0100 Message-ID: Thread-Topic: 3280bis: key usage (13) Thread-Index: AcVi19RLqFejCjjSQrGHpadVO9E7XgAAhYoA From: "Stefan Santesson" To: "Stephen Farrell" , "Peter Gutmann" Cc: , X-OriginalArrivalTime: 27 May 2005 16:48:30.0818 (UTC) FILETIME=[E9B41420:01C562DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4RGmbcA091484 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit The problem is partly to understand what NR/CC is but the real issue why they can be mutually exclusive is that they define properties of different abstraction layers. Applications on the message layer only understand signing within the concept of data origin authentication and content integrity, they have no clue whether the signature they process is going to be used for CC/NR or not. Example: e-mail client with S/MIME signing will never know the purpose of signing. Application on the higher application layers may however know exactly why you are signing. E.g. web service enabling you to pay an invoice. This application will know whether the purpose is CC/NR and can pick the appropriate cert. So in summary, if you define DS = all signing except CC/NR, they you confuse all lower layer applications operating on the message layer who don't have a clue whether their signatures are being used for CC/NR in any higher layer context. To the text proposed by Stephen: It is not quite correct. That text forbids cert and CRL validation when only DS is set, which is close bon not exactly right. E.g. it does not prevent Cert and CRL validation when DS+NR/CC are set. I think you need to move closer to the original RFC 3280 def. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Stephen Farrell > Sent: den 27 maj 2005 17:26 > To: Peter Gutmann > Cc: Denis.Pinkas@bull.net; ietf-pkix@imc.org > Subject: Re: 3280bis: key usage (13) > > > > Peter, > > > The motivation for the comment was that we've just gone through the > > keyEncipherment vs. dataEncipherment debate where no-one's quite sure > which > > bits to set for what occasion, and now in an attempt to fix the equally- > > problematic DS vs. NR we're creating a similar problem: [...] > > Fair enough. Problem is we'll apparently never get agreement > on what NR/CC means:-( > > >> The digitalSignature bit is asserted when the subject public key > >> is used for verifying digital signatures that are used > >> with an entity authentication service, a data origin authentication > >> service or/and an integrity service. Note that a certificate > >> with only the digitalSignature bit set MUST NOT be used for > >> verifying certificate or CRL signatures. > > > > Sounds good to me. > > Cool. Let's see what happens when Denis get back so, > Stephen. > From owner-ietf-pkix@mail.imc.org Fri May 27 13:40:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02312 for ; Fri, 27 May 2005 13:40:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RGqMXK092941; Fri, 27 May 2005 09:52:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RGqMoc092940; Fri, 27 May 2005 09:52:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RGqLHb092934 for ; Fri, 27 May 2005 09:52:21 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4RGqC9v019687; Fri, 27 May 2005 12:52:13 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4RGpV6u006218; Fri, 27 May 2005 12:51:31 -0400 (EDT) Message-ID: <4297502A.804@nist.gov> Date: Fri, 27 May 2005 12:51:54 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas CC: pkix Subject: Re: 3280bis: CRL validation References: <42958C32.8020706@bull.net> In-Reply-To: <42958C32.8020706@bull.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Denis, You have been saying for some time that "CRL validation is NOT specified in RFC 3280". But, the more you post about CRL validation, the more clear it becomes that the problem is that you do not understand how CRL validation works in X.509. Further, it is not clear that the problem is with the text of X.509 or RFC 3280 or if it is just that X.509 does not work the way you believe (or want) it to work. X.509 was designed based on a model in which names are globally unique. In November on the X.500 mail list, you tried to argue otherwise, but it was demonstrated quite convincingly that this is what X.509 says: X.509, clause 8.3.2.1 (subject alternative name extension): The values in the alternatives of the GeneralName type are names of various forms as follows: – directoryName is a directory name defined in accordance with ITU-T Rec. X.501 | ISO/IEC 9594-2; (NOTE that directoryName is of type Name, which is the also the type used to define the issuer and subject fields) X.501, clause 9.1 (Definitions): 9.1.4 (directory) name: A construct that singles out a particular object from all other objects. A name shall be unambiguous (that is, denote just one object), however it need not be unique (that is, be the only name which unambiguously denotes the object). X.501, clause 9.2 (Names in General): A (directory) name is a construct that identifies a particular object from among the set of all objects. A name shall be unambiguous, that is, denotes just one object. However, a name need not be unique, that is, be the only name that unambiguously denotes the object. A (directory) name also identifies an entry. This entry is either an object entry that represents the object or an alias entry which contains information that helps the Directory to locate the entry that represents the object. An object can be assigned a distinguished name without being represented by an entry in the Directory, but this name is then the name its object entry would have had were it represented in the Directory. Syntactically, each name for an object or entry is an ordered sequence of relative distinguished names (see 9.3). Name ::= CHOICE { -- only one possibility for now -- rdnSequence RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName DistinguishedName ::= RDNSequence Note that I am not try to argue that it is impossible for two entities within a PKI to be assigned the same name, just that this would be inconsistent with the model upon which X.509 was developed. In a message to the PKIX list on April 11 about the CRL AIA draft, you wrote: > In order to build a path, a relying party needs to make sure of the > name of the CRL Issuer, which means not simply knowing the DN of the > CRL issuer but also all the other DNs from the upper CAs up to a root > key. As noted above, in X.509 an object is uniquely identified by its DN. There is no notion of forming that "name" of an object by creating a sequence of DNs. In the context of your comment above, you seem to be suggesting that the "name" of the CRL Issuer consists of the sequence of names from the certificates forming a certification path that starts at a "root" and ends with the CRL Issuer. But, this does not make sense for two reasons. First, in the X.500 series, naming is defined in X.501. That is, the concept of PKI is not used in defining naming. Second, a naming scheme like this could only work if PKIs were limited to being hierarchies, which they are not. In the same message on April 11, you wrote: > Let us consider two different scenarios where this new extension [AIA > extension in a CRL] would be considered. > > Scenario A: The relying party does not trust any CRL issuer in > particular and will simply use the CRL Issuer designated by the > Certificate Issuer by means of the CRL DP extension. > > Scenario B: The relying party trusts at least a specific CRL issuer > and will get the CRLs from that CRL Issuer and then will make sure > that the information contained in them matches with the designation of > the Certificate Issuer. X.509/RFC 3280 does not allow for scenario B. With OCSP a relying party may choose to accept status information from a locally trusted OCSP server. With CRLs, a CRL may only be used to verify the status of a certificate if the certificate explicitly indicates that CRLs from that issuer may be used. This can be done in two ways. Either (1) the certificate issuer and CRL issuer are the same entity (i.e., the issuer fields in the certificate and CRL contain the same name) or (2) the certificate includes a cRLDistributionPoints extension in which the cRLIssuer field is present and contains the name of the CRL issuer. This is covered in RFC 3280 in section 6.3.3, step (b)(1): 6.3.3 CRL Processing (b) Verify the issuer and scope of the complete CRL as follows: (1) If the DP includes cRLIssuer, then verify that the issuer field in the complete CRL matches cRLIssuer in the DP and that the complete CRL contains an issuing distribution point extension with the indrectCRL boolean asserted. Otherwise, verify that the CRL issuer matches the certificate issuer. As to your specific comments below: For issue 33, you are misinterpreting the certificateIssuer extension. The certificateIssuer extension is defined as GeneralNames so that one can include more than one name for the certificate issuer (e.g., the name from the issuer field of the certificate and one or more names from the issuerAltName extension of the certificate). That is it is a sequence (or logically a set) of names for a single entity. It is not intended to specify a certification path. As for issue 43, as I argued above, whether you like it or not, X.509 was designed based on the assumption that name collisions will not occur. (Of course a "rogue" CA could issue such certificates, but X.509 assumes that rogue CAs are untrusted (either they are never issued a certificate or certificates issued to them are revoked) so that any name collisions they create will not affect the security of the PKI). Again, you may believe that it was a bad idea to make such an assumption, but this doesn't change the fact that this assumption was used in the design of X.509. Recently, a number of people on the PKIX list, including you, have argued that it is unsafe to assume that no two authorities (e.g., CA and/or CRL issuer) will issue certificates and/or CRLs under the same name. In particular, they are concerned that at some point there will be two trusted authorities that belong to the same PKI that are issuing certificates and CRLs under the same name, that no one will detect this, and that this may result in a relying party using a CRL issued by one of the authorities to validate a certificate issued by the other authority. Since the CRL does not actually cover the certificate, it will not provide accurate information about the status of the certificate. At the IETF meeting in November, Santosh presented a proposal for a restricted version of the certification path validation algorithm that would prevent a relying party from using a CRL issued by the wrong authority to validate the status of a certificate, even if name collisions occurred, so long as no trusted CA issued two certificates to different entities with the same subject DN. At the meeting, the concern was expressed that incorporating this new algorithm into 3280bis would be too big of a change from RFC 3280 and so trying to incorporate it into 3280bis would unacceptably delay the completion of 3280bis. So, it was suggested that Santosh's proposal should be advanced in a separate document. At the same time, several people felt that if name collisions between authorities were ever going to be seen, it would be as a result of two authorities in two different PKIs using the same name, but with both authorities being trusted by a relying party as a result of the relying party using multiple trust anchors. Indicating that the certification path for a certificate and the corresponding CRL should start at the same trust anchor would prevent the use of the wrong CRL in this case. So, the initial agreement that came out of the November IETF meeting was to include a note in the security requirements section of 3280bis about the use of a common trust anchor in order to mitigate the risk that might result if a name collision ever did occur and to leave any further work on this issue to another document. Note that I am personally in favor of Santosh's proposal, mainly because I believe that imposing such restrictions on the certification path for the CRL will limit the search space for the certification path and will thus lead to more efficient implementations. While I am not particularly concerned about the name collision risk, I do not think that the restrictions that Santosh's algorithm imposes pose any problems either. However, PKIX standards, including 3280bis, are developed by consensus; I cannot simply write my own personal views into the standard. Dave Denis Pinkas wrote: > To the list, > > I changed the name of the thread which is now under 3280bis. > > As Tim mentioned: "it is clear that the current content of 3280bis > with respect to CRL validation does not enjoy consensus within the > working group". > > Issues 33 and 43 are directly related to this topic. They are both > copied below: > > 33) The certificateIssuer CRL entry extension contains a GeneralNames. > While RFC 3280 does not state this, there seems to be general > agreement that the certificateIssuer extension should only contain the > DN from the issuer field of the certificate being revoked. > > 3280bis states: "Conforming CRL issuers MUST include in [the > certificateIssuer] extension the distinguished name (DN) from the > issuer field of the certificate that corresponds to this CRL entry. > The encoding of the DN MUST be identical to the encoding used in the > certificate." > > > 43) It should be noted in 3280bis that there is a risk that two > different > CAs (or a CA and a CRL issuer) may issue certificates and CRLs under > the same name and that if this happens there is a risk that a > relying > party will validate a certificate issued by one of these entities > using a CRL issued by the other. > > The security considerations section of 3280bis states that CAs and CRL > issuers should be formed in a way that reduces the likelihood of name > collisions. It also states that implementations validating CRLs MUST > ensure that the certification path of the target certificate and the > CRL issuer certification path used to validate the target certificate > terminate at the same trust anchor. > > Both statements are incorrect. > > For issue 43: name collisions are possible and a design cannot be > based on the assumption that name collisions, whether accidental or > intentional, will never happen. This means that chosing names to > "reduce the likehood of name collisions" is not a way to solve the > issue. Termination at the same trust anchor without additional details > does not solve the issue either. > > For issue 33: the certificateIssuer extension is defined as : > > certificateIssuer ::= GeneralNames > > with > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > It is not defined as: > > certificateIssuer ::= GeneralName > > ... and this is NOT an error. > > To go directly to the point, certificateIssuer may contain in practice > either: > > - one name, or > - a sequence of names. > > If it contains one name, this means that this name MUST be certified > by the CA that has issued the certificate where the extension appears. > > If it contains a sequence of names, this means that the certification > path of the CRL issuer certificate formed using that sequence of names > MUST also terminate at the trust anchor of the target certificate. > > This is secure and avoids any name collision, either deliberate or > intentional. > > Denis From owner-ietf-pkix@mail.imc.org Fri May 27 15:27:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18852 for ; Fri, 27 May 2005 15:27:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RIb0ob003468; Fri, 27 May 2005 11:37:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RIb0so003467; Fri, 27 May 2005 11:37:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RIaxwl003459 for ; Fri, 27 May 2005 11:37:00 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200505271835.j4RIZ1xD022249@stingray.missi.ncsc.mil> Date: Fri, 27 May 2005 14:36:53 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: 3280bis: key usage (13) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2005 18:36:53.0530 (UTC) FILETIME=[0D9F2FA0:01C562EB] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit David Chadwick and I argued within X.509 that if there are going to be two (or four) bits, then those bits should specify non-overlapping purposes (i.e. DS for purpose A, NR/CC/?? for purpose B, Cert-S for purpose C and CRL-S for purpose D, where A, B, C and D are mutually exclusive and collectively exhaustive). The suggestion at the time was to consider ephemeral signatures (entity authentication w/ liveness) to be purpose A, and persistent signatures (data origin authentication / integrity with no implication of presence/liveness) to be purpose B. That view was roundly rejected by all present, who subscribed to Stefan's theory of contagious fuzziness. So given that the decision has been made to create a fuzzy non-implementable definition for NR/CC, I believe PKIX should adopt Stephen's suggestion that CA's MUST set this bit to a random value. Dave Peter Gutmann wrote: >Stephen Farrell writes: > > > >>There's a bit (NR/CC) whose meaning has been the subject of loads and loads >>of rambling discussion for ages and ages, and you want to define DS= >>NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a >>bad idea. >> >> > >Oh was that what all that was about? I'd gone off to reorganise my sock >drawer and sort my packets of alphabet soup after the first 800 or so messages >went by, so I probably missed some bits. > >The motivation for the comment was that we've just gone through the >keyEncipherment vs. dataEncipherment debate where no-one's quite sure which >bits to set for what occasion, and now in an attempt to fix the equally- >problematic DS vs. NR we're creating a similar problem: what do you do in >situations where neither the DS nor CC/NR bits fit? I don't really care how >the bits are defined, as long as it doesn't end up creating un-uses that can't >be clearly signified with either DS or CC/NR. Without this, we'll get another >situation like the dataEncipherment one where something doesn't fall easily >into either choice, so users and CAs claim that their choice of DS or CC >applies, whatever happens to coincide with what their software does. > > > >> The digitalSignature bit is asserted when the subject public key >> is used for verifying digital signatures that are used >> with an entity authentication service, a data origin authentication >> service or/and an integrity service. Note that a certificate >> with only the digitalSignature bit set MUST NOT be used for >> verifying certificate or CRL signatures. >> >> > >Sounds good to me. > >Peter. > > > > From owner-ietf-pkix@mail.imc.org Sat May 28 17:16:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04386 for ; Sat, 28 May 2005 17:16:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4SKcGD2082132; Sat, 28 May 2005 13:38:16 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4SKcGPF082131; Sat, 28 May 2005 13:38:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (STRATTON-THREE-SIXTY-NINE.MIT.EDU [18.187.6.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4SKcFrV082123 for ; Sat, 28 May 2005 13:38:16 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 87EBDE0063; Sat, 28 May 2005 16:38:13 -0400 (EDT) To: Russ Housley Cc: timmoore@microsoft.com, ietf-pkix@imc.org Subject: Re: AD Review for draft-ietf-pkix-rfc3770bis References: <6.2.1.2.2.20050524104606.03fab960@mail.binhost.com> From: Sam Hartman Date: Sat, 28 May 2005 16:38:13 -0400 In-Reply-To: <6.2.1.2.2.20050524104606.03fab960@mail.binhost.com> (Russ Housley's message of "Tue, 24 May 2005 11:35:10 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Russ. These changes look good to me and I agree they address my comments. There doesn't seem to be any disagreement from the WG, so let's send in a new draft unless we get an objection from the chairs. I believe I'm still waiting for a proto writeup from Tim. From owner-ietf-pkix@mail.imc.org Mon May 30 06:17:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02459 for ; Mon, 30 May 2005 06:17:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U9Jlf8018229; Mon, 30 May 2005 02:19:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4U9Jl46018228; Mon, 30 May 2005 02:19:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U9JkD2018217 for ; Mon, 30 May 2005 02:19:46 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 070CF34F63; Mon, 30 May 2005 21:19:46 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03711-21; Mon, 30 May 2005 21:19:45 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id D8850340D3; Mon, 30 May 2005 21:19:44 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CAA2637748; Mon, 30 May 2005 21:19:44 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DcgR2-0002RO-00; Mon, 30 May 2005 21:19:48 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dpkemp@missi.ncsc.mil, ietf-pkix@imc.org Subject: Re: 3280bis: key usage (13) In-Reply-To: <200505271835.j4RIZ1xD022249@stingray.missi.ncsc.mil> Message-Id: Date: Mon, 30 May 2005 21:19:48 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David P. Kemp" writes: >The suggestion at the time was to consider ephemeral signatures (entity >authentication w/ liveness) to be purpose A, and persistent signatures (data >origin authentication / integrity with no implication of presence/liveness) >to be purpose B. That view was roundly rejected by all present, who >subscribed to Stefan's theory of contagious fuzziness. Uhh, just for the record, I've always supported this interpretation, it's simple, straightforward, and easy to understand. From private discussions in the past that there are others here who support this as well, but they tend to fall into the class of PKI app developers/implementors, who have mostly abandoned this list or use it purely in read-only mode. Peter. From owner-ietf-pkix@mail.imc.org Mon May 30 06:19:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02530 for ; Mon, 30 May 2005 06:19:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U94EZb012758; Mon, 30 May 2005 02:04:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4U94Eok012756; Mon, 30 May 2005 02:04:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U94D4Z012735 for ; Mon, 30 May 2005 02:04:14 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 2E76B3544C for ; Mon, 30 May 2005 21:04:12 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27262-27 for ; Mon, 30 May 2005 21:04:12 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 15D5634F63 for ; Mon, 30 May 2005 21:04:11 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B5E6A37748 for ; Mon, 30 May 2005 21:04:11 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DcgBz-0002Qr-00 for ; Mon, 30 May 2005 21:04:15 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Absent keyUsage in certificates Message-Id: Date: Mon, 30 May 2005 21:04:15 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If anyone from Verisign-called-Thawte is reading this, could you please fix your certs to include the keyUsage extension? They're currently being issued without any keyUsage indication (or at least some of them are), which is causing some debate about how to apply them (the contact details I have for someone at Verisign seem to be out of date). Also, could the current wording around keyUsage in bride-of-3280 be improved to indicate what the correct usage is if the extension is absent? Squinting at the text sideways, it currently says that the key can be used for anything *except* cert and CRL verification, a rather strange allow-some/deny-some interpretation when it's more normal to have a default of either allow-all or deny-all (fail-open/fail-closed) in the absence of any further instructions, but this is quite hard to see for anyone who doesn't already know in advance how keyUsage works. The sentence "Conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs" is particularly obtuse. I would suggest adding either: Conforming CAs MUST include this extension in all certificates. (by far the simplest solution, there's no reason not to include this in a cert, it's at the same level as basicConstraints, and virtually every CA in existence does it anyway), or at least: Where this extension is absent, the certificate may be used for all purposes that the public-key algorithm is capable of except certificate and CRL signing and validation. Peter. From owner-ietf-pkix@mail.imc.org Mon May 30 11:24:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22164 for ; Mon, 30 May 2005 11:24:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UEP2iH036681; Mon, 30 May 2005 07:25:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UEP2hI036680; Mon, 30 May 2005 07:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4UEOxfY036670 for ; Mon, 30 May 2005 07:25:01 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 53F5D100A8 for ; Mon, 30 May 2005 10:24:58 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08340-49 for ; Mon, 30 May 2005 10:24:44 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 5285110090 for ; Mon, 30 May 2005 10:24:44 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005053010235216-47701 ; Mon, 30 May 2005 10:23:52 -0400 Date: Mon, 30 May 2005 10:24:42 -0400 From: Sam Roberts To: ietf-pkix@imc.org Subject: Re: Absent keyUsage in certificates Message-ID: <20050530142442.GA2272@certicom.com> Mail-Followup-To: ietf-pkix@imc.org References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/30/2005 10:23:52 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/30/2005 10:23:53 AM, Serialize complete at 05/30/2005 10:23:53 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Peter Gutmann , on Mon, May 30, 2005 at 09:04:15PM +1200: > If anyone from Verisign-called-Thawte is reading this, could you please fix > your certs to include the keyUsage extension? They're currently being issued > without any keyUsage indication (or at least some of them are), which is > causing some debate about how to apply them (the contact details I have for > someone at Verisign seem to be out of date). > > Also, could the current wording around keyUsage in bride-of-3280 be improved > to indicate what the correct usage is if the extension is absent? Squinting > at the text sideways, it currently says that the key can be used for anything > *except* cert and CRL verification, a rather strange allow-some/deny-some > interpretation when it's more normal to have a default of either allow-all or > deny-all (fail-open/fail-closed) in the absence of any further instructions, I agree that allow-all or deny-all is sensible, and special-casing two of the bits would be weird, but isn't allow-all what is specified now? This interpretation is based on the validation rules, section 6.1.4, rule (n): If a key usage extension is present, verify that the keyCertSign bit is set. I can't see anything that says that absence of Key Usage should trigger chain validation failure. Its a long RFC, an you point to the text you are "squinting sideways" at? > but this is quite hard to see for anyone who doesn't already know in advance > how keyUsage works. The sentence "Conforming CAs MUST include this extension > in certificates that contain public keys that are used to validate digital > signatures on other public key certificates or CRLs" is particularly obtuse. > > I would suggest adding either: > > Conforming CAs MUST include this extension in all certificates. Why MUST an end-entity cert include a Key Usage, not including it is a good way of specifying allow-all. You want to forbid allow-all? Cheers, Sam -- http://www.certicom.com From owner-ietf-pkix@mail.imc.org Mon May 30 13:21:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28499 for ; Mon, 30 May 2005 13:21:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGUVtQ044565; Mon, 30 May 2005 09:30:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UGUVMF044564; Mon, 30 May 2005 09:30:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGUUXB044556 for ; Mon, 30 May 2005 09:30:30 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 66104343A7; Tue, 31 May 2005 04:30:29 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17495-13; Tue, 31 May 2005 04:30:29 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 4B9FF34330; Tue, 31 May 2005 04:30:29 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0FA8337749; Tue, 31 May 2005 04:30:29 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Dcn9v-0002lU-00; Tue, 31 May 2005 04:30:35 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, sroberts@certicom.com Subject: Re: Absent keyUsage in certificates In-Reply-To: <20050530142442.GA2272@certicom.com> Message-Id: Date: Tue, 31 May 2005 04:30:35 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Roberts writes: >I agree that allow-all or deny-all is sensible, and special-casing two of the >bits would be weird, but isn't allow-all what is specified now? Nope. See below. >This interpretation is based on the validation rules, section 6.1.4, rule >(n): > > If a key usage extension is present, verify that the keyCertSign bit > is set. Oh, section 6 contradicts section 4 in a number of places, I take section 4 as definitive since it specifies the intent of the spec whereas section 6 only contains an attempt at implementing that intent. (Another proposed improvement for bride-of-3280, indicate which of section 4 or 6 is definitive in the case of conflict). >I can't see anything that says that absence of Key Usage should trigger chain >validation failure. The exact text I quoted earlier, i.e: Conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. >Its a long RFC, an you point to the text you are "squinting sideways" at? The keyUsage text, which covers the use of keyUsage in a very obtuse way. What the above is trying to say in a very roundabout way is: CA certificates must include a keyUsage extension with keyCertSign or crlSign bits set as appropriate. >Why MUST an end-entity cert include a Key Usage, not including it is a good >way of specifying allow-all. You want to forbid allow-all? No, I want to make it explicit. As your message shows, at least one PKIX member (not to mention an unknown but significant number of non-PKIX people) find the current text/usage quite confusing :-). Since virtually all CAs already include keyUsage, explicitly requiring it would fix the problem at virtually zero cost to implementors. Peter. From owner-ietf-pkix@mail.imc.org Tue May 31 02:52:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10201 for ; Tue, 31 May 2005 02:52:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V5x7pI025532; Mon, 30 May 2005 22:59:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4V5x7IQ025531; Mon, 30 May 2005 22:59:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V5x5As025487 for ; Mon, 30 May 2005 22:59:06 -0700 (PDT) (envelope-from dcross@microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 May 2005 22:58:01 -0700 Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 May 2005 22:58:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Absent keyUsage in certificates Date: Mon, 30 May 2005 22:57:58 -0700 Message-ID: <3C69AE30038D9A4590F5EC20DCD41F6806974716@RED-MSG-41.redmond.corp.microsoft.com> Thread-Topic: Absent keyUsage in certificates Thread-Index: AcVlLyJra6ejgDTPQHOh1hfjFoWoAgAYetKA From: "David Cross" To: "Sam Roberts" , X-OriginalArrivalTime: 31 May 2005 05:58:05.0341 (UTC) FILETIME=[B65BDCD0:01C565A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4V5x6As025519 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I agree for CA certificates, the Key Usage extension MUST be asserted. However, in client (end entity) certificates, this is extremely disadvantageous as it makes deployments and future application consumption difficult. In fact, many many companies and oragnizations have demanded the acceptance and usage by applications EE certs with this extension absent to indicate all purposes. David B. Cross -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sam Roberts Sent: Monday, May 30, 2005 7:25 AM To: ietf-pkix@imc.org Subject: Re: Absent keyUsage in certificates Wrote Peter Gutmann , on Mon, May 30, 2005 at 09:04:15PM +1200: > If anyone from Verisign-called-Thawte is reading this, could you > please fix your certs to include the keyUsage extension? They're > currently being issued without any keyUsage indication (or at least > some of them are), which is causing some debate about how to apply > them (the contact details I have for someone at Verisign seem to be out of date). > > Also, could the current wording around keyUsage in bride-of-3280 be > improved to indicate what the correct usage is if the extension is > absent? Squinting at the text sideways, it currently says that the > key can be used for anything > *except* cert and CRL verification, a rather strange > allow-some/deny-some interpretation when it's more normal to have a > default of either allow-all or deny-all (fail-open/fail-closed) in the > absence of any further instructions, I agree that allow-all or deny-all is sensible, and special-casing two of the bits would be weird, but isn't allow-all what is specified now? This interpretation is based on the validation rules, section 6.1.4, rule (n): If a key usage extension is present, verify that the keyCertSign bit is set. I can't see anything that says that absence of Key Usage should trigger chain validation failure. Its a long RFC, an you point to the text you are "squinting sideways" at? > but this is quite hard to see for anyone who doesn't already know in > advance how keyUsage works. The sentence "Conforming CAs MUST include > this extension in certificates that contain public keys that are used > to validate digital signatures on other public key certificates or CRLs" is particularly obtuse. > > I would suggest adding either: > > Conforming CAs MUST include this extension in all certificates. Why MUST an end-entity cert include a Key Usage, not including it is a good way of specifying allow-all. You want to forbid allow-all? Cheers, Sam -- http://www.certicom.com From owner-ietf-pkix@mail.imc.org Tue May 31 06:04:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23351 for ; Tue, 31 May 2005 06:04:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8wVXn092146; Tue, 31 May 2005 01:58:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4V8wVtE092145; Tue, 31 May 2005 01:58:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8wOfS092109 for ; Tue, 31 May 2005 01:58:25 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 09:58:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Absent keyUsage in certificates Date: Tue, 31 May 2005 09:58:07 +0100 Message-ID: Thread-Topic: Absent keyUsage in certificates Thread-Index: AcVlPLddOVfqhHUIQE2B/sqYjbi52gAgS1iA From: "Stefan Santesson" To: "Peter Gutmann" , , X-OriginalArrivalTime: 31 May 2005 08:58:16.0793 (UTC) FILETIME=[E27C8490:01C565BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4V8wPfS092128 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I'm not sure I get the problem or what has to be fixed. This extension defines the use of the public key in the certificate. So obviously, in absence of this extension the usage is simply undefined in the context of this extension. The use of the public key may however still be constrained by other means, such as certificate policy, EKU, Basic Constraints etc. So it is not correct to define that absent key usage extension = all usages. The key usage extension is already required for CA certs. /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Peter Gutmann > Sent: den 30 maj 2005 18:31 > To: ietf-pkix@imc.org; sroberts@certicom.com > Subject: Re: Absent keyUsage in certificates > > > Sam Roberts writes: > > >I agree that allow-all or deny-all is sensible, and special-casing two of > the > >bits would be weird, but isn't allow-all what is specified now? > > Nope. See below. > > >This interpretation is based on the validation rules, section 6.1.4, rule > >(n): > > > > If a key usage extension is present, verify that the keyCertSign bit > > is set. > > Oh, section 6 contradicts section 4 in a number of places, I take section > 4 as > definitive since it specifies the intent of the spec whereas section 6 > only > contains an attempt at implementing that intent. > > (Another proposed improvement for bride-of-3280, indicate which of section > 4 > or 6 is definitive in the case of conflict). > > >I can't see anything that says that absence of Key Usage should trigger > chain > >validation failure. > > The exact text I quoted earlier, i.e: > > Conforming CAs MUST include this extension in certificates that contain > public keys that are used to validate digital signatures on other public > key > certificates or CRLs. > > >Its a long RFC, an you point to the text you are "squinting sideways" at? > > The keyUsage text, which covers the use of keyUsage in a very obtuse way. > What the above is trying to say in a very roundabout way is: > > CA certificates must include a keyUsage extension with keyCertSign or > crlSign bits set as appropriate. > > >Why MUST an end-entity cert include a Key Usage, not including it is a > good > >way of specifying allow-all. You want to forbid allow-all? > > No, I want to make it explicit. As your message shows, at least one PKIX > member (not to mention an unknown but significant number of non-PKIX > people) > find the current text/usage quite confusing :-). Since virtually all CAs > already include keyUsage, explicitly requiring it would fix the problem at > virtually zero cost to implementors. > > Peter. From owner-ietf-pkix@mail.imc.org Tue May 31 06:10:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23860 for ; Tue, 31 May 2005 06:10:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8ukp8091694; Tue, 31 May 2005 01:56:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4V8ukRi091693; Tue, 31 May 2005 01:56:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8ujBe091677 for ; Tue, 31 May 2005 01:56:45 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id DEC493403C; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25382-02; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id C69983402A; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 917D237742; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Dd2YN-00016k-00; Tue, 31 May 2005 20:56:51 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dcross@microsoft.com, ietf-pkix@imc.org, sroberts@certicom.com Subject: RE: Absent keyUsage in certificates In-Reply-To: <3C69AE30038D9A4590F5EC20DCD41F6806974716@RED-MSG-41.redmond.corp.microsoft.com> Message-Id: Date: Tue, 31 May 2005 20:56:51 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David Cross" writes: >I agree for CA certificates, the Key Usage extension MUST be asserted. >However, in client (end entity) certificates, this is extremely >disadvantageous as it makes deployments and future application consumption >difficult. In what way? Why can't you just set all the flags that make sense (e.g. all encryption and signing flags for an RSA key)? At the moment the few certs I've seen with keyUsage absent seem to be more an indication of CA error than an intent to allow them to be used for any purpose (e.g. ones that have no X.509 keyUsage but do have a Netscape keyUsage that doesn't match an all- purpose usage, or ones where the CA, when questioned, admitted that that wasn't at all what they'd intended). Making keyUsage mandatory everywhere would make the CA's intent explicit. >In fact, many many companies and oragnizations have demanded the acceptance >and usage by applications EE certs with this extension absent to indicate all >purposes. All purposes except cert/CRL signing, you mean. Or do they really want to use them for all purposes, including cert/CRL signing/verification? Peter. From owner-ietf-pkix@mail.imc.org Tue May 31 10:18:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13147 for ; Tue, 31 May 2005 10:18:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VD5DYL079804; Tue, 31 May 2005 06:05:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VD5Dcd079803; Tue, 31 May 2005 06:05:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VD5BZ6079756 for ; Tue, 31 May 2005 06:05:12 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 14:05:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Absent keyUsage in certificates Date: Tue, 31 May 2005 14:05:01 +0100 Message-ID: Thread-Topic: Absent keyUsage in certificates Thread-Index: AcVlyi8zZEoN/dETS96aqt/ykZjh3wAFo0+w From: "Stefan Santesson" To: "Peter Gutmann" , "David Cross" , , X-OriginalArrivalTime: 31 May 2005 13:05:06.0060 (UTC) FILETIME=[5D7F54C0:01C565E1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4VD5CZ6079790 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Peter, > >In fact, many many companies and oragnizations have demanded the > acceptance > >and usage by applications EE certs with this extension absent to indicate > all > >purposes. > > All purposes except cert/CRL signing, you mean. Or do they really want to > use them for all purposes, including cert/CRL signing/verification? All purposes that is consistent with the rest of the certificate. Since Basic Constraints MUST be present in CA certificates, this automatically excludes CRL/Cert signing for EE certs. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Peter Gutmann > Sent: den 31 maj 2005 10:57 > To: David Cross; ietf-pkix@imc.org; sroberts@certicom.com > Subject: RE: Absent keyUsage in certificates > > > "David Cross" writes: > > >I agree for CA certificates, the Key Usage extension MUST be asserted. > >However, in client (end entity) certificates, this is extremely > >disadvantageous as it makes deployments and future application > consumption > >difficult. > > In what way? Why can't you just set all the flags that make sense (e.g. > all > encryption and signing flags for an RSA key)? At the moment the few certs > I've seen with keyUsage absent seem to be more an indication of CA error > than > an intent to allow them to be used for any purpose (e.g. ones that have no > X.509 keyUsage but do have a Netscape keyUsage that doesn't match an all- > purpose usage, or ones where the CA, when questioned, admitted that that > wasn't at all what they'd intended). Making keyUsage mandatory everywhere > would make the CA's intent explicit. > > >In fact, many many companies and oragnizations have demanded the > acceptance > >and usage by applications EE certs with this extension absent to indicate > all > >purposes. > > All purposes except cert/CRL signing, you mean. Or do they really want to > use them for all purposes, including cert/CRL signing/verification? > > Peter. From owner-ietf-pkix@mail.imc.org Tue May 31 10:31:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14107 for ; Tue, 31 May 2005 10:31:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDZa28083026; Tue, 31 May 2005 06:35:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VDZaLB083025; Tue, 31 May 2005 06:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx.ditec.sk (mx.ditec.sk [62.65.178.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDZVLI083000 for ; Tue, 31 May 2005 06:35:33 -0700 (PDT) (envelope-from vittek@ditec.sk) Received: from apps.intra.ditec.sk ([172.24.1.23] RDNS failed) by mx.ditec.sk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 15:35:25 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: CRL sequence issues Date: Tue, 31 May 2005 15:35:24 +0200 Message-ID: Thread-Topic: CRL sequence issues Thread-Index: AcVl5ZlgsStKfeuXRrmdg5PyOywmPA== From: "Vittek Robert" To: X-OriginalArrivalTime: 31 May 2005 13:35:25.0171 (UTC) FILETIME=[99C5A430:01C565E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4VDZaLI083018 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dear gentlemen, I am involved in development of a system that is supposed to process electronically signed documents (possibly ten thousands per hour) while the response time (on the question if the signature is valid or not) should be "as low as possible". At the same time, it is crucial that the response is correct because a mistake can have serious legal consequences. I have questions concerning certificate status validation when CRLs are the revocation mechanism. All of the references are made to RFC 3280. CRL Validation algorithm described in 6.3 assumes usage of a local cache and somehow alibistically "assumes that all of the needed CRLs are available in a local cache". In 6.3.3, there are some rules to be followed on fetching all needed CRLs, one of them being very interesting. (2) If the current time is before the value of the next update field and use-deltas is set, then obtain the current delta CRL that can be used to update the locally cached complete CRL as specified in section 5.2.4. There is no rule specified if use-deltas is not set. At the same time description of Next Update field (5.1.2.5) says: This field indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. So, there is a possibility that a complete CRL has been issued invalidating the one in local cache for the time in question (e.g. from Time Stamp Token) and this CRL should be downloaded. I think that the above mentioned paragraph in 6.3.3 should be modified to obtain a complete CRL in any case or at least make a check. Anyway, it's been kind of a theoretical problem so far. In real world it is not feasible to make HTTP or FTP call to CA for every validated signature at the rate "ten thousands per hour". Even if it was, how can I be sure (using untrusted HTTP or FTP communication with most of CAs) that some traitor did not fetch my request and did not provided me with older CRL which still has next update field greater than time from TST. I can not. My uncertainty will disappear only after a CRL with ThisUpdate greater than TST is issued and I have downloaded all CRLs issued so far. Btw, CRL with ThisUpdate greater than TST is sometimes the first CRL that can invalidate a revoked certificate which makes the rules for fetching CRLs in algorithm for CRL Validation all erroneous. So, this leads me to a question what mechanism can be exploited to ensure that I have downloaded a complete set of CRLs issued so far. First, I thought that crlNumber is sufficient. But crlNumbers must convey only monotonically increasing sequence - NOT LINEAR sequence. That means, some of the numbers can be omitted and I have no means to determine it. Do you have any suggestions? Moreover, it may be critical to be sure to download the next CRL issued right after TST, because RFC 3280 states that: A complete CRL lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope. An entry is added to the CRL as part of the next update following notification of revocation. An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. If TST < Cert.validTo < CRL(n).thisUpdate then CRL(n) is crucial for certificate status validation with respect to Time Stamp Token. Another reason to have a mechanism for a check if I am missing some CRL from sequence or not. Otherwise, there are cases when one is not able to say if a certificate was valid at TST time or not, hence if the signature is valid wrt. TST. Maybe, I am just missing something in RFC 3280 (or any other) that will suddenly make everything clear to me. In that case I apologize to the readers of this forum. Sincerely, Mgr. Robert Vittek DITEC, a.s. Bratislava Business Center V Plynárenská 7/C 821 09 Bratislava voice: +421 2 58 222 487 fax: +421 2 58 222 777 cell: +421 908 797 827 e-mail: vittek@ditec.sk From owner-ietf-pkix@mail.imc.org Tue May 31 10:37:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14569 for ; Tue, 31 May 2005 10:37:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDmUIr083945; Tue, 31 May 2005 06:48:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VDmUtZ083944; Tue, 31 May 2005 06:48:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDmTRp083937 for ; Tue, 31 May 2005 06:48:29 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4VDm7fC012295; Tue, 31 May 2005 09:48:21 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4VDlg6u021880; Tue, 31 May 2005 09:47:42 -0400 (EDT) Message-ID: <429C6B1F.5070506@nist.gov> Date: Tue, 31 May 2005 09:48:15 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: pkix Subject: Re: Absent keyUsage in certificates References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, This seems to be an issue that has caused confusion for several people, as Sam Roberts pointed out to me in another forum (http://cio.nist.gov/esd/emaildir/lists/pkits/msg00108.html). When the keyUsage extension is absent, then the key can be used for any purpose (except as restricted by the basicConstraints, extendedKeyUsage, certificatePolicies, etc. extensions as Stefan mentioned). The text that you quoted was intentionally written as "Conforming CAs MUST ..." because it is a requirement that ONLY applies to CAs. So, section 4 and 6 are not contradictory. The text from section 4 that you quoted imposes a requirement on CAs, but does not apply to relying parties. The text that Sam quoted from section 6 is part of the path validation algorithm, which is used by relying parties but not CAs. The basic idea is that while the PKIX Certificate and CRL profile (RFC 3280, 3280bis) imposes stricter certificate and CRL generation requirements than X.509 does, there is no requirement to reject a certification path that is valid under X.509 simply because it was not issued in conformance with the PKIX profile. While it would be nice if every CA followed the PKIX profile of X.509, I don't think PKIX should mandate that certificates be rejected simply because they were issued in accordance with a profile of X.509 that does not conform to the PKIX profile. This is the reason that the path validation algorithm in RFC 3280 and 3280bis was designed to accept any certification path that is valid under X.509 and it does not include checks to verify that certificates were issued in conformance to the PKIX profile. So, even if PKIX required all certificates to include a keyUsage extension, this could only be a requirement for conforming CAs, not relying parties. Sam suggested that I add text to section 6 of 3280bis clearly stating that the PKIX path validation algorithm is designed to accept any certification path that is valid under X.509, not just those that were issued in conformance with the PKIX profile. He made the suggestion a few days after the -00 draft was originally submitted, but I intend to include this text in the -01 draft. As to your question about whether section 4 takes precedence over section 6 or vice versa, I don't think there is a real answer. In general, section 6 provides the definitive explanation of how to perform certification path validation. However, section 6 does not repeat all of the details from section 4. For example, section 6.1.3 steps (b) and (c) and section 6.1.4 step (g) discuss the processing of name constraints, but one must read section 4.2.1.10 to understand the rules for applying name constraints to each name form. On the other hand, while section 4.2.1.11 provides a good textual description of the policyConstraints extension, this section does not provide enough detail to implement the path validation algorithm. So, if you want a general understanding of the extension, read section 4. If you want to implement the code to process the extension, read section 6. BTW, if there are places where section 6 contradicts section 4, please point them out so that they can be fixed. But remember that the algorithm in section 6 was not intended to verify that CAs issued certificates and CRLs in conformance with section 4. So, if there is a requirement in section 4 of the form "conforming CAs MUST ...", there may not be a corresponding requirement imposed in relying parties. Dave Peter Gutmann wrote: > Sam Roberts writes: > >> agree that allow-all or deny-all is sensible, and special-casing two >> of the >> bits would be weird, but isn't allow-all what is specified now? > > Nope. See below. > >> This interpretation is based on the validation rules, section 6.1.4, rule >> (n): >> >> If a key usage extension is present, verify that the keyCertSign bit >> is set. > > Oh, section 6 contradicts section 4 in a number of places, I take > section 4 as > definitive since it specifies the intent of the spec whereas section 6 > only > contains an attempt at implementing that intent. > > (Another proposed improvement for bride-of-3280, indicate which of > section 4 > or 6 is definitive in the case of conflict). > >> I can't see anything that says that absence of Key Usage should >> trigger chain >> validation failure. > > The exact text I quoted earlier, i.e: > > Conforming CAs MUST include this extension in certificates that contain > public keys that are used to validate digital signatures on other > public key > certificates or CRLs. > >> Its a long RFC, an you point to the text you are "squinting sideways" at? > > The keyUsage text, which covers the use of keyUsage in a very obtuse way. > What the above is trying to say in a very roundabout way is: > > CA certificates must include a keyUsage extension with keyCertSign or > crlSign bits set as appropriate. > >> Why MUST an end-entity cert include a Key Usage, not including it is >> a good >> way of specifying allow-all. You want to forbid allow-all? > > No, I want to make it explicit. As your message shows, at least one PKIX > member (not to mention an unknown but significant number of non-PKIX > people) > find the current text/usage quite confusing :-). Since virtually all CAs > already include keyUsage, explicitly requiring it would fix the problem at > virtually zero cost to implementors. > > Peter. From owner-ietf-pkix@mail.imc.org Tue May 31 10:43:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15325 for ; Tue, 31 May 2005 10:43:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDisnf083699; Tue, 31 May 2005 06:44:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VDisXS083698; Tue, 31 May 2005 06:44:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4VDir4X083689 for ; Tue, 31 May 2005 06:44:53 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id CCCC4100C5 for ; Tue, 31 May 2005 09:44:47 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12999-36 for ; Tue, 31 May 2005 09:44:34 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id F00F4100C1 for ; Tue, 31 May 2005 09:44:33 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005053109434147-63918 ; Tue, 31 May 2005 09:43:41 -0400 Date: Tue, 31 May 2005 09:44:33 -0400 From: Sam Roberts To: ietf-pkix@imc.org Subject: Re: Absent keyUsage in certificates Message-ID: <20050531134433.GA30174@certicom.com> Mail-Followup-To: ietf-pkix@imc.org References: <3C69AE30038D9A4590F5EC20DCD41F6806974716@RED-MSG-41.redmond.corp.microsoft.com> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/31/2005 09:43:41 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/31/2005 09:43:41 AM, Serialize complete at 05/31/2005 09:43:41 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Peter Gutmann , on Tue, May 31, 2005 at 08:56:51PM +1200: > "David Cross" writes: > >In fact, many many companies and oragnizations have demanded the acceptance > >and usage by applications EE certs with this extension absent to indicate all > >purposes. > > All purposes except cert/CRL signing, you mean. Or do they really want to > use them for all purposes, including cert/CRL signing/verification? cert signing requires a BasicConstraints, so its disallowed for other reasons even if the KeyUsage is absent. I don't see the problem you would like to fix. Are you saying that its easier for a CA to mistakenly not include a KeyUsage than it is to mistakenly include a KeyUsage with all bits set? Since I regularly see certs that don't obey PKIX MUST encoding rules, and we have to be able to "work" with them anyhow, other than allowing us to gripe about certs we see that are wrong, I don't see how this change will help or hinder implementors. So, I'll bow out of the discussion. Cheers, Sam -- http://www.certicom.com From owner-ietf-pkix@mail.imc.org Tue May 31 11:21:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18128 for ; Tue, 31 May 2005 11:21:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VEUnEw087238; Tue, 31 May 2005 07:30:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VEUnq8087237; Tue, 31 May 2005 07:30:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VEUmLC087227 for ; Tue, 31 May 2005 07:30:48 -0700 (PDT) (envelope-from shanna@funk.com) Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KNB9WPQY; Tue, 31 May 2005 10:29:17 -0400 Message-ID: <429C750D.7000005@funk.com> Date: Tue, 31 May 2005 10:30:37 -0400 From: Steve Hanna User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David A. Cooper" CC: Peter Gutmann , pkix Subject: Re: Absent keyUsage in certificates References: <429C6B1F.5070506@nist.gov> In-Reply-To: <429C6B1F.5070506@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is a good example of Jon Postel's advice: Be liberal in what you accept, and conservative in what you send. CAs should set keyUsage but relying parties should not require it to be set (unless explicitly configured to do so). Of course, there must be limits to an RP's "liberalism". An RP should not accept a purported CA certificate that contains a keyUsage extension that doesn't have the keyCertSign bit set. Thanks, Steve David A. Cooper wrote: > > Peter, > > This seems to be an issue that has caused confusion for several people, > as Sam Roberts pointed out to me in another forum > (http://cio.nist.gov/esd/emaildir/lists/pkits/msg00108.html). > > When the keyUsage extension is absent, then the key can be used for any > purpose (except as restricted by the basicConstraints, extendedKeyUsage, > certificatePolicies, etc. extensions as Stefan mentioned). > > The text that you quoted was intentionally written as "Conforming CAs > MUST ..." because it is a requirement that ONLY applies to CAs. So, > section 4 and 6 are not contradictory. The text from section 4 that you > quoted imposes a requirement on CAs, but does not apply to relying > parties. The text that Sam quoted from section 6 is part of the path > validation algorithm, which is used by relying parties but not CAs. > > The basic idea is that while the PKIX Certificate and CRL profile (RFC > 3280, 3280bis) imposes stricter certificate and CRL generation > requirements than X.509 does, there is no requirement to reject a > certification path that is valid under X.509 simply because it was not > issued in conformance with the PKIX profile. While it would be nice if > every CA followed the PKIX profile of X.509, I don't think PKIX should > mandate that certificates be rejected simply because they were issued in > accordance with a profile of X.509 that does not conform to the PKIX > profile. This is the reason that the path validation algorithm in RFC > 3280 and 3280bis was designed to accept any certification path that is > valid under X.509 and it does not include checks to verify that > certificates were issued in conformance to the PKIX profile. So, even > if PKIX required all certificates to include a keyUsage extension, this > could only be a requirement for conforming CAs, not relying parties. > > Sam suggested that I add text to section 6 of 3280bis clearly stating > that the PKIX path validation algorithm is designed to accept any > certification path that is valid under X.509, not just those that were > issued in conformance with the PKIX profile. He made the suggestion a > few days after the -00 draft was originally submitted, but I intend to > include this text in the -01 draft. > > As to your question about whether section 4 takes precedence over > section 6 or vice versa, I don't think there is a real answer. In > general, section 6 provides the definitive explanation of how to perform > certification path validation. However, section 6 does not repeat all > of the details from section 4. For example, section 6.1.3 steps (b) and > (c) and section 6.1.4 step (g) discuss the processing of name > constraints, but one must read section 4.2.1.10 to understand the rules > for applying name constraints to each name form. On the other hand, > while section 4.2.1.11 provides a good textual description of the > policyConstraints extension, this section does not provide enough detail > to implement the path validation algorithm. So, if you want a general > understanding of the extension, read section 4. If you want to > implement the code to process the extension, read section 6. > > BTW, if there are places where section 6 contradicts section 4, please > point them out so that they can be fixed. But remember that the > algorithm in section 6 was not intended to verify that CAs issued > certificates and CRLs in conformance with section 4. So, if there is a > requirement in section 4 of the form "conforming CAs MUST ...", there > may not be a corresponding requirement imposed in relying parties. > > Dave > > Peter Gutmann wrote: > >> Sam Roberts writes: >> >>> agree that allow-all or deny-all is sensible, and special-casing two >>> of the >>> bits would be weird, but isn't allow-all what is specified now? >> >> >> Nope. See below. >> >>> This interpretation is based on the validation rules, section 6.1.4, >>> rule >>> (n): >>> >>> If a key usage extension is present, verify that the keyCertSign bit >>> is set. >> >> >> Oh, section 6 contradicts section 4 in a number of places, I take >> section 4 as >> definitive since it specifies the intent of the spec whereas section 6 >> only >> contains an attempt at implementing that intent. >> >> (Another proposed improvement for bride-of-3280, indicate which of >> section 4 >> or 6 is definitive in the case of conflict). >> >>> I can't see anything that says that absence of Key Usage should >>> trigger chain >>> validation failure. >> >> >> The exact text I quoted earlier, i.e: >> >> Conforming CAs MUST include this extension in certificates that contain >> public keys that are used to validate digital signatures on other >> public key >> certificates or CRLs. >> >>> Its a long RFC, an you point to the text you are "squinting sideways" >>> at? >> >> >> The keyUsage text, which covers the use of keyUsage in a very obtuse way. >> What the above is trying to say in a very roundabout way is: >> >> CA certificates must include a keyUsage extension with keyCertSign or >> crlSign bits set as appropriate. >> >>> Why MUST an end-entity cert include a Key Usage, not including it is >>> a good >>> way of specifying allow-all. You want to forbid allow-all? >> >> >> No, I want to make it explicit. As your message shows, at least one PKIX >> member (not to mention an unknown but significant number of non-PKIX >> people) >> find the current text/usage quite confusing :-). Since virtually all CAs >> already include keyUsage, explicitly requiring it would fix the >> problem at >> virtually zero cost to implementors. >> >> Peter. From owner-ietf-pkix@mail.imc.org Tue May 31 19:19:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09664 for ; Tue, 31 May 2005 19:19:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VMDjBO020168; Tue, 31 May 2005 15:13:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VMDjUS020166; Tue, 31 May 2005 15:13:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VMDfEV020157 for ; Tue, 31 May 2005 15:13:42 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4VMDC8a005965; Tue, 31 May 2005 18:13:17 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4VMC76v000531; Tue, 31 May 2005 18:12:07 -0400 (EDT) Message-Id: <5.1.0.14.2.20050531133953.039ad7f0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 May 2005 18:13:42 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: WG Last Call is closed: AIA CRL extension Cc: Denis Pinkas , Stefan Santesson , Russ Housley , kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, The WG has achieved rough consensus on the AIA CRL extension ID. The editors will be submitting a new ID incorporating the changes agreed to on list. When that ID appears, I will forward it to the appropriate Area Director for progression. Thanks, Tim Polk At 04:36 PM 5/25/2005 +0200, Denis Pinkas wrote: >Stefan and Russ, > >>Denis, > >>I discussed this with Russ and our conclusion is that if this resolves >>your last call issues, then we can live with deleting these sentences. > >If so, my concern is solved. > >Thanks, > >Denis > >PS: Stefan, we do not need to meet anymore next week on this topic, > and we can spend more time to enjoy some good food on the > French Riviera. :-) > >>Stefan Santesson >>Program Manager, Standards Liaison >>Windows Security >> >> >>>-----Original Message----- >>>From: owner-ietf-pkix@mail.imc.org >>[mailto:owner-ietf-pkix@mail.imc.org] >> >>>On Behalf Of Denis Pinkas >>>Sent: den 25 maj 2005 00:47 >>>To: Russ Housley >>>Cc: ietf-pkix@imc.org >>>Subject: Re: WG Last Call: AIA CRL extension >>> >>> >>>Russ, >>> >>>Two points: >>> >>>1. The current text in the security considerations section contains >>> text which suggest a solution to the problem but which is not. >>> At least the two following sentences SHALL be deleted: >>> >>> " As means of reducing problems and security issues related to >>issuer >> >>> name collisions, CA names SHOULD be formed in a way that reduce >>the >> >>> likelihood of name collisions. Implementations validating CRLs >>> MUST ensure that the certification path of the target certificate >>> and the CRL issuer certification path used to validate the target >>> certificate, terminate at the same trust anchor". >>> >>>2. We strongly agree that 3280bis MUST address this issue and >>currently >> >>> it does not do it correctly (otherwise we would not have this >>> loooong discussion), ... that we can continue within the scope >>> of 3280bis. >>> >>>Denis >>> >>> >>>>Julien & Tom: >>>> >>>>Two points: >>>> >>>>1. I understand this scenario. The change that you advocate as a >>>>countermeasure will prevent Indirect CRLs from working in scenarios >>that >> >>>>are intended. >>>> >>>>2. This observation has noting to do with the CRL AIA extension. >>The >> >>>>attacker is inserting the bogus revocation information into the >>>>repository. Any relying party that uses that repository (when using >>the >> >>>>CRL AIA extension or any other configuration information to locate >>it) >> >>>>will get the bogus revocation information. >>>> >>>>If this is a concern, then it needs to be addressed in RFC3280bis, >>not >> >>>>here. >>>> >>>>Russ >>>> >>>>At 12:38 PM 5/24/2005, Julien Stern wrote: >>>> >>>> >>>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: >>>>> >>>>>> There is one scenario permitted by the "same trust >>anchor" >> >>>rule >>> >>>>>>for CRL signers which seems to me to be a serious security hole. >>>>> >>>>>Let us >>>>> >>>>>>assume a valid CA which is a direct subordinate of one of the >>RP's >> >>>>>trust >>>>> >>>>>>anchors. This CA issues separate CRL's and ARL's, in a quite >>usual >> >>>>>way, >>>>> >>>>>>and issues cross certificates. After months or years of >>operation, >> >>>it >>> >>>>>>revokes one of its cross certificates because the subject's >>operator >> >>>>>has >>>>> >>>>>>gone rogue. That rogue subject then issues a fraudulent CRL >>Signing >> >>>>>>certificate with the DN that the superior certificate has been >>using >> >>>to >>> >>>>>>sign ARL's, a public key which it has newly generated, and >>various >> >>>>>>extensions including an SKID. It then issues an updated copy of >>an >> >>>old >>> >>>>>>ARL under the fraudulent CRL signer's certificate and with an >>AKID >> >>>>>>matching the fraudulent signer's SKID. If the rogue can break >>into >> >>>the >>> >>>>>>repository where the CRL is expected, this fraudulently issued >>CRL >> >>>will >>> >>>>>>probably be validated whether it contains an AIA or not. It will >>>>>>certainly pass the "same trust anchor" condition. >>>>>> This scenario, in which a rogue CA issues an ARL >>certifiying >> >>>>>that >>>>> >>>>>>its primary certificate has not been revoked and gets the ARL >>>>> >>>>>accepted, is >>>>> >>>>>>possible under "same trust anchor" but not under "signed by path >>>>> >>>>>member". >>>>> >>>>>I agree with the validity of this scenario. I believe this is very >>>>>close to the issue I attempted to bring on the list a short time >>ago. >> >>>>>Of course, it assumes the existence of a rogue CA at some point in >>>time. >>> >>>>>Note that the CRL could be directly inserted into a "long term" >>>>>signature (according to RFC3126 for example). This does not require >>>>>a repository break-in and makes the "attack" even more realistic. >>>>> >>>>>Regards. >>>>> >>>>>-- >>>>>Julien Stern >>>>> >>>>> >>>>>> Tom Gindin >>>>>> >>>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM >>----- >> >>>>>> >>>>>>Tom Gindin >>>>>>05/23/2005 10:46 PM >>>>>> >>>>>> To: wpolk@nist.gov >>>>>> cc: housley@vigilsec.com, ietf-pkix@imc.org, >>>kent@bbn.com, >>> >>>>>>stefans@microsoft.com >>>>>> From: Tom Gindin/Watson/IBM@IBMUS >>>>>> Subject: Re: WG Last Call: AIA CRL extension >>>>>> >>>>>> Tim: >>>>>> >>>>>> I should probably have brought this up earlier, but are >>we >> >>>>>certain >>>>> >>>>>>that "same trust anchor" is a strong enough check that the CRL >>>>> >>>>>signer is >>>>> >>>>>>the one expected by the issuing CA? While I was not in San Diego >>>when >>> >>>>>>this wording was included in the 3280 series, I do not really >>think >> >>>>>that >>>>> >>>>>>that check is strong enough. I would suggest instead that the >>CRL >> >>>>>>signer's certificate needs to be directly issued by one of the >>CA's >> >>>>>in the >>>>> >>>>>>certification path back to the trust anchor used for the >>>certificate's >>> >>>>>>verification, or by that anchor itself, unless people have >>practical >> >>>>>>experience with CA structures which that rule would prohibit. >>>>> >>>>>Forcing the >>>>> >>>>>>CRL to be issued by the CA itself (as I understand Denis to have >>>>>>suggested) prohibits the reasonable case where the CRL is issued >>by a >> >>>>>>hierarchical superior, so it is IMHO too strict. >>>>>> I am personally not sure, FWIW, that a CRL should be >>>>> >>>>>permitted to >>>>> >>>>>>be signed by a second-cousin certificate of the issuer's >>>>> >>>>>certificate. By >>>>> >>>>>>analogy to the use of the terms in families, "sibling" >>certificates >> >>>>>would >>>>> >>>>>>have the same issuer, "first-cousin" certificates would be issued >>by >> >>>>>>siblings, and "second-cousin" certificates would be issued by >>first >> >>>>>>cousins - so they are both three levels down from the same trust >>>>> >>>>>anchor, >>>>> >>>>>>or from the last common CA in their paths. This issue is not >>newly >> >>>>>caused >>>>> >>>>>>by CRL AIA, since the same issue can arise with CRL's containing >>only >> >>>>>>AKID. AIA only allows RP's to build a path (whether right or >>wrong) >> >>>>>more >>>>> >>>>>>quickly. >>>>>> In any case, nothing more than a note in Security >>>>> >>>>>Considerations >>>>> >>>>>>is appropriate in any of our RFC's other than 3280 and its >>successor. >> >>>>>> Tom Gindin >>>>>>P.S. - The above views are mine, and not necessarily those of my >>>>> >>>>>employer >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>Tim Polk >>>>>>Sent by: owner-ietf-pkix@mail.imc.org >>>>>>05/10/2005 05:27 PM >>>>>> >>>>>> To: ietf-pkix@imc.org >>>>>> cc: kent@bbn.com, stefans@microsoft.com, >>>>> >>>>>housley@vigilsec.com >>>>> >>>>>> Subject: WG Last Call: AIA CRL extension >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>This message initiates working group Last Call for the >>specification >> >>>>>>"Internet X.509 Public Key Infrastructure: Authority Information >>>Access >>> >>>>>>CRL >>>>>>Extension". While some issues raised in the working group are >>>>> >>>>>unresolved, >>>>> >>>>>>the editors believe that rough consensus supports the current >>>>>>specification. >>>>>> >>>>>>The URL for this Internet-Draft is: >>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt >>>>>> >>>>>>Last Call will run for (at least) two weeks. That is, Last Call >>will >> >>>>>not >>>>> >>>>>>close before May 24. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Tim Polk >>>>>> >>>> > From owner-ietf-pkix@mail.imc.org Tue May 31 20:30:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13220 for ; Tue, 31 May 2005 20:30:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VNVPNi024614; Tue, 31 May 2005 16:31:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VNVPnh024613; Tue, 31 May 2005 16:31:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VNVJ5U024603 for ; Tue, 31 May 2005 16:31:19 -0700 (PDT) (envelope-from dcross@microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 16:31:14 -0700 Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 16:31:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Absent keyUsage in certificates Date: Tue, 31 May 2005 16:31:08 -0700 Message-ID: <3C69AE30038D9A4590F5EC20DCD41F68069C6418@RED-MSG-41.redmond.corp.microsoft.com> Thread-Topic: Absent keyUsage in certificates Thread-Index: AcVlyfpgFzKfVf9UQsSfyg1ej9xvMAAbqw3g From: "David Cross" To: "Peter Gutmann" , , X-OriginalArrivalTime: 31 May 2005 23:31:13.0712 (UTC) FILETIME=[D5901B00:01C56638] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4VNVJ5U024606 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sorry for delayed reply, I am travelling. Yes, you are correct, they don't want to use EE certs for CRL or cetr signing which also require basic constraints to be set. But many companies don't want to anticipate the purpose when they issue a 5 year smartcard, etc. David B. Cross -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Peter Gutmann Sent: Tuesday, May 31, 2005 1:57 AM To: David Cross; ietf-pkix@imc.org; sroberts@certicom.com Subject: RE: Absent keyUsage in certificates "David Cross" writes: >I agree for CA certificates, the Key Usage extension MUST be asserted. >However, in client (end entity) certificates, this is extremely >disadvantageous as it makes deployments and future application >consumption difficult. In what way? Why can't you just set all the flags that make sense (e.g. all encryption and signing flags for an RSA key)? At the moment the few certs I've seen with keyUsage absent seem to be more an indication of CA error than an intent to allow them to be used for any purpose (e.g. ones that have no X.509 keyUsage but do have a Netscape keyUsage that doesn't match an all- purpose usage, or ones where the CA, when questioned, admitted that that wasn't at all what they'd intended). Making keyUsage mandatory everywhere would make the CA's intent explicit. >In fact, many many companies and oragnizations have demanded the >acceptance and usage by applications EE certs with this extension >absent to indicate all purposes. All purposes except cert/CRL signing, you mean. Or do they really want to use them for all purposes, including cert/CRL signing/verification? Peter. From owner-ietf-pkix@mail.imc.org Sat Jun 4 13:20:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18204 for ; Sat, 4 Jun 2005 13:20:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j54GNisv026122; Sat, 4 Jun 2005 09:23:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j54GNiOP026121; Sat, 4 Jun 2005 09:23:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from receive6.inner-21cn.com ([202.105.45.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j54GNasu026109 for ; Sat, 4 Jun 2005 09:23:42 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from above.proper.com([10.2.100.6]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm106429c7b93; Tue, 31 May 2005 17:07:01 +0800 Received: from above.proper.com([208.184.76.39]) by 21cn.com(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 31 May 2005 16:58:34 +0800 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8ukp8091694; Tue, 31 May 2005 01:56:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4V8ukRi091693; Tue, 31 May 2005 01:56:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8ujBe091677 for ; Tue, 31 May 2005 01:56:45 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id DEC493403C; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25382-02; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id C69983402A; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 917D237742; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Dd2YN-00016k-00; Tue, 31 May 2005 20:56:51 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dcross@microsoft.com, ietf-pkix@imc.org, sroberts@certicom.com Subject: RE: Absent keyUsage in certificates In-Reply-To: <3C69AE30038D9A4590F5EC20DCD41F6806974716@RED-MSG-41.redmond.corp.microsoft.com> Message-Id: Date: Tue, 31 May 2005 20:56:51 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz List-Archive: List-ID: List-Unsubscribe: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-pkix@mail.imc.org Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David Cross" writes: >I agree for CA certificates, the Key Usage extension MUST be asserted. >However, in client (end entity) certificates, this is extremely >disadvantageous as it makes deployments and future application consumption >difficult. In what way? Why can't you just set all the flags that make sense (e.g. all encryption and signing flags for an RSA key)? At the moment the few certs I've seen with keyUsage absent seem to be more an indication of CA error than an intent to allow them to be used for any purpose (e.g. ones that have no X.509 keyUsage but do have a Netscape keyUsage that doesn't match an all- purpose usage, or ones where the CA, when questioned, admitted that that wasn't at all what they'd intended). Making keyUsage mandatory everywhere would make the CA's intent explicit. >In fact, many many companies and oragnizations have demanded the acceptance >and usage by applications EE certs with this extension absent to indicate all >purposes. All purposes except cert/CRL signing, you mean. Or do they really want to use them for all purposes, including cert/CRL signing/verification? Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VNVPNi024614; Tue, 31 May 2005 16:31:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VNVPnh024613; Tue, 31 May 2005 16:31:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VNVJ5U024603 for ; Tue, 31 May 2005 16:31:19 -0700 (PDT) (envelope-from dcross@microsoft.com) Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 16:31:14 -0700 Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 16:31:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Absent keyUsage in certificates Date: Tue, 31 May 2005 16:31:08 -0700 Message-ID: <3C69AE30038D9A4590F5EC20DCD41F68069C6418@RED-MSG-41.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Absent keyUsage in certificates Thread-Index: AcVlyfpgFzKfVf9UQsSfyg1ej9xvMAAbqw3g From: "David Cross" To: "Peter Gutmann" , , X-OriginalArrivalTime: 31 May 2005 23:31:13.0712 (UTC) FILETIME=[D5901B00:01C56638] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4VNVJ5U024606 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry for delayed reply, I am travelling. Yes, you are correct, they don't want to use EE certs for CRL or cetr signing which also require basic constraints to be set. But many companies don't want to anticipate the purpose when they issue a 5 year smartcard, etc. David B. Cross -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Peter Gutmann Sent: Tuesday, May 31, 2005 1:57 AM To: David Cross; ietf-pkix@imc.org; sroberts@certicom.com Subject: RE: Absent keyUsage in certificates "David Cross" writes: >I agree for CA certificates, the Key Usage extension MUST be asserted. >However, in client (end entity) certificates, this is extremely >disadvantageous as it makes deployments and future application >consumption difficult. In what way? Why can't you just set all the flags that make sense (e.g. all encryption and signing flags for an RSA key)? At the moment the few certs I've seen with keyUsage absent seem to be more an indication of CA error than an intent to allow them to be used for any purpose (e.g. ones that have no X.509 keyUsage but do have a Netscape keyUsage that doesn't match an all- purpose usage, or ones where the CA, when questioned, admitted that that wasn't at all what they'd intended). Making keyUsage mandatory everywhere would make the CA's intent explicit. >In fact, many many companies and oragnizations have demanded the >acceptance and usage by applications EE certs with this extension >absent to indicate all purposes. All purposes except cert/CRL signing, you mean. Or do they really want to use them for all purposes, including cert/CRL signing/verification? Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VMDjBO020168; Tue, 31 May 2005 15:13:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VMDjUS020166; Tue, 31 May 2005 15:13:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VMDfEV020157 for ; Tue, 31 May 2005 15:13:42 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4VMDC8a005965; Tue, 31 May 2005 18:13:17 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4VMC76v000531; Tue, 31 May 2005 18:12:07 -0400 (EDT) Message-Id: <5.1.0.14.2.20050531133953.039ad7f0@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 31 May 2005 18:13:42 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: WG Last Call is closed: AIA CRL extension Cc: Denis Pinkas , Stefan Santesson , Russ Housley , kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, The WG has achieved rough consensus on the AIA CRL extension ID. The editors will be submitting a new ID incorporating the changes agreed to on list. When that ID appears, I will forward it to the appropriate Area Director for progression. Thanks, Tim Polk At 04:36 PM 5/25/2005 +0200, Denis Pinkas wrote: >Stefan and Russ, > >>Denis, > >>I discussed this with Russ and our conclusion is that if this resolves >>your last call issues, then we can live with deleting these sentences. > >If so, my concern is solved. > >Thanks, > >Denis > >PS: Stefan, we do not need to meet anymore next week on this topic, > and we can spend more time to enjoy some good food on the > French Riviera. :-) > >>Stefan Santesson >>Program Manager, Standards Liaison >>Windows Security >> >> >>>-----Original Message----- >>>From: owner-ietf-pkix@mail.imc.org >>[mailto:owner-ietf-pkix@mail.imc.org] >> >>>On Behalf Of Denis Pinkas >>>Sent: den 25 maj 2005 00:47 >>>To: Russ Housley >>>Cc: ietf-pkix@imc.org >>>Subject: Re: WG Last Call: AIA CRL extension >>> >>> >>>Russ, >>> >>>Two points: >>> >>>1. The current text in the security considerations section contains >>> text which suggest a solution to the problem but which is not. >>> At least the two following sentences SHALL be deleted: >>> >>> " As means of reducing problems and security issues related to >>issuer >> >>> name collisions, CA names SHOULD be formed in a way that reduce >>the >> >>> likelihood of name collisions. Implementations validating CRLs >>> MUST ensure that the certification path of the target certificate >>> and the CRL issuer certification path used to validate the target >>> certificate, terminate at the same trust anchor". >>> >>>2. We strongly agree that 3280bis MUST address this issue and >>currently >> >>> it does not do it correctly (otherwise we would not have this >>> loooong discussion), ... that we can continue within the scope >>> of 3280bis. >>> >>>Denis >>> >>> >>>>Julien & Tom: >>>> >>>>Two points: >>>> >>>>1. I understand this scenario. The change that you advocate as a >>>>countermeasure will prevent Indirect CRLs from working in scenarios >>that >> >>>>are intended. >>>> >>>>2. This observation has noting to do with the CRL AIA extension. >>The >> >>>>attacker is inserting the bogus revocation information into the >>>>repository. Any relying party that uses that repository (when using >>the >> >>>>CRL AIA extension or any other configuration information to locate >>it) >> >>>>will get the bogus revocation information. >>>> >>>>If this is a concern, then it needs to be addressed in RFC3280bis, >>not >> >>>>here. >>>> >>>>Russ >>>> >>>>At 12:38 PM 5/24/2005, Julien Stern wrote: >>>> >>>> >>>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: >>>>> >>>>>> There is one scenario permitted by the "same trust >>anchor" >> >>>rule >>> >>>>>>for CRL signers which seems to me to be a serious security hole. >>>>> >>>>>Let us >>>>> >>>>>>assume a valid CA which is a direct subordinate of one of the >>RP's >> >>>>>trust >>>>> >>>>>>anchors. This CA issues separate CRL's and ARL's, in a quite >>usual >> >>>>>way, >>>>> >>>>>>and issues cross certificates. After months or years of >>operation, >> >>>it >>> >>>>>>revokes one of its cross certificates because the subject's >>operator >> >>>>>has >>>>> >>>>>>gone rogue. That rogue subject then issues a fraudulent CRL >>Signing >> >>>>>>certificate with the DN that the superior certificate has been >>using >> >>>to >>> >>>>>>sign ARL's, a public key which it has newly generated, and >>various >> >>>>>>extensions including an SKID. It then issues an updated copy of >>an >> >>>old >>> >>>>>>ARL under the fraudulent CRL signer's certificate and with an >>AKID >> >>>>>>matching the fraudulent signer's SKID. If the rogue can break >>into >> >>>the >>> >>>>>>repository where the CRL is expected, this fraudulently issued >>CRL >> >>>will >>> >>>>>>probably be validated whether it contains an AIA or not. It will >>>>>>certainly pass the "same trust anchor" condition. >>>>>> This scenario, in which a rogue CA issues an ARL >>certifiying >> >>>>>that >>>>> >>>>>>its primary certificate has not been revoked and gets the ARL >>>>> >>>>>accepted, is >>>>> >>>>>>possible under "same trust anchor" but not under "signed by path >>>>> >>>>>member". >>>>> >>>>>I agree with the validity of this scenario. I believe this is very >>>>>close to the issue I attempted to bring on the list a short time >>ago. >> >>>>>Of course, it assumes the existence of a rogue CA at some point in >>>time. >>> >>>>>Note that the CRL could be directly inserted into a "long term" >>>>>signature (according to RFC3126 for example). This does not require >>>>>a repository break-in and makes the "attack" even more realistic. >>>>> >>>>>Regards. >>>>> >>>>>-- >>>>>Julien Stern >>>>> >>>>> >>>>>> Tom Gindin >>>>>> >>>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM >>----- >> >>>>>> >>>>>>Tom Gindin >>>>>>05/23/2005 10:46 PM >>>>>> >>>>>> To: wpolk@nist.gov >>>>>> cc: housley@vigilsec.com, ietf-pkix@imc.org, >>>kent@bbn.com, >>> >>>>>>stefans@microsoft.com >>>>>> From: Tom Gindin/Watson/IBM@IBMUS >>>>>> Subject: Re: WG Last Call: AIA CRL extension >>>>>> >>>>>> Tim: >>>>>> >>>>>> I should probably have brought this up earlier, but are >>we >> >>>>>certain >>>>> >>>>>>that "same trust anchor" is a strong enough check that the CRL >>>>> >>>>>signer is >>>>> >>>>>>the one expected by the issuing CA? While I was not in San Diego >>>when >>> >>>>>>this wording was included in the 3280 series, I do not really >>think >> >>>>>that >>>>> >>>>>>that check is strong enough. I would suggest instead that the >>CRL >> >>>>>>signer's certificate needs to be directly issued by one of the >>CA's >> >>>>>in the >>>>> >>>>>>certification path back to the trust anchor used for the >>>certificate's >>> >>>>>>verification, or by that anchor itself, unless people have >>practical >> >>>>>>experience with CA structures which that rule would prohibit. >>>>> >>>>>Forcing the >>>>> >>>>>>CRL to be issued by the CA itself (as I understand Denis to have >>>>>>suggested) prohibits the reasonable case where the CRL is issued >>by a >> >>>>>>hierarchical superior, so it is IMHO too strict. >>>>>> I am personally not sure, FWIW, that a CRL should be >>>>> >>>>>permitted to >>>>> >>>>>>be signed by a second-cousin certificate of the issuer's >>>>> >>>>>certificate. By >>>>> >>>>>>analogy to the use of the terms in families, "sibling" >>certificates >> >>>>>would >>>>> >>>>>>have the same issuer, "first-cousin" certificates would be issued >>by >> >>>>>>siblings, and "second-cousin" certificates would be issued by >>first >> >>>>>>cousins - so they are both three levels down from the same trust >>>>> >>>>>anchor, >>>>> >>>>>>or from the last common CA in their paths. This issue is not >>newly >> >>>>>caused >>>>> >>>>>>by CRL AIA, since the same issue can arise with CRL's containing >>only >> >>>>>>AKID. AIA only allows RP's to build a path (whether right or >>wrong) >> >>>>>more >>>>> >>>>>>quickly. >>>>>> In any case, nothing more than a note in Security >>>>> >>>>>Considerations >>>>> >>>>>>is appropriate in any of our RFC's other than 3280 and its >>successor. >> >>>>>> Tom Gindin >>>>>>P.S. - The above views are mine, and not necessarily those of my >>>>> >>>>>employer >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>Tim Polk >>>>>>Sent by: owner-ietf-pkix@mail.imc.org >>>>>>05/10/2005 05:27 PM >>>>>> >>>>>> To: ietf-pkix@imc.org >>>>>> cc: kent@bbn.com, stefans@microsoft.com, >>>>> >>>>>housley@vigilsec.com >>>>> >>>>>> Subject: WG Last Call: AIA CRL extension >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>This message initiates working group Last Call for the >>specification >> >>>>>>"Internet X.509 Public Key Infrastructure: Authority Information >>>Access >>> >>>>>>CRL >>>>>>Extension". While some issues raised in the working group are >>>>> >>>>>unresolved, >>>>> >>>>>>the editors believe that rough consensus supports the current >>>>>>specification. >>>>>> >>>>>>The URL for this Internet-Draft is: >>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt >>>>>> >>>>>>Last Call will run for (at least) two weeks. That is, Last Call >>will >> >>>>>not >>>>> >>>>>>close before May 24. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Tim Polk >>>>>> >>>> > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VEUnEw087238; Tue, 31 May 2005 07:30:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VEUnq8087237; Tue, 31 May 2005 07:30:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.funk.com (mail2.funk.com [199.103.155.98] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VEUmLC087227 for ; Tue, 31 May 2005 07:30:48 -0700 (PDT) (envelope-from shanna@funk.com) Received: from [127.0.0.1] (hannaxp [192.168.21.6]) by mail2.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id KNB9WPQY; Tue, 31 May 2005 10:29:17 -0400 Message-ID: <429C750D.7000005@funk.com> Date: Tue, 31 May 2005 10:30:37 -0400 From: Steve Hanna User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "David A. Cooper" CC: Peter Gutmann , pkix Subject: Re: Absent keyUsage in certificates References: <429C6B1F.5070506@nist.gov> In-Reply-To: <429C6B1F.5070506@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a good example of Jon Postel's advice: Be liberal in what you accept, and conservative in what you send. CAs should set keyUsage but relying parties should not require it to be set (unless explicitly configured to do so). Of course, there must be limits to an RP's "liberalism". An RP should not accept a purported CA certificate that contains a keyUsage extension that doesn't have the keyCertSign bit set. Thanks, Steve David A. Cooper wrote: > > Peter, > > This seems to be an issue that has caused confusion for several people, > as Sam Roberts pointed out to me in another forum > (http://cio.nist.gov/esd/emaildir/lists/pkits/msg00108.html). > > When the keyUsage extension is absent, then the key can be used for any > purpose (except as restricted by the basicConstraints, extendedKeyUsage, > certificatePolicies, etc. extensions as Stefan mentioned). > > The text that you quoted was intentionally written as "Conforming CAs > MUST ..." because it is a requirement that ONLY applies to CAs. So, > section 4 and 6 are not contradictory. The text from section 4 that you > quoted imposes a requirement on CAs, but does not apply to relying > parties. The text that Sam quoted from section 6 is part of the path > validation algorithm, which is used by relying parties but not CAs. > > The basic idea is that while the PKIX Certificate and CRL profile (RFC > 3280, 3280bis) imposes stricter certificate and CRL generation > requirements than X.509 does, there is no requirement to reject a > certification path that is valid under X.509 simply because it was not > issued in conformance with the PKIX profile. While it would be nice if > every CA followed the PKIX profile of X.509, I don't think PKIX should > mandate that certificates be rejected simply because they were issued in > accordance with a profile of X.509 that does not conform to the PKIX > profile. This is the reason that the path validation algorithm in RFC > 3280 and 3280bis was designed to accept any certification path that is > valid under X.509 and it does not include checks to verify that > certificates were issued in conformance to the PKIX profile. So, even > if PKIX required all certificates to include a keyUsage extension, this > could only be a requirement for conforming CAs, not relying parties. > > Sam suggested that I add text to section 6 of 3280bis clearly stating > that the PKIX path validation algorithm is designed to accept any > certification path that is valid under X.509, not just those that were > issued in conformance with the PKIX profile. He made the suggestion a > few days after the -00 draft was originally submitted, but I intend to > include this text in the -01 draft. > > As to your question about whether section 4 takes precedence over > section 6 or vice versa, I don't think there is a real answer. In > general, section 6 provides the definitive explanation of how to perform > certification path validation. However, section 6 does not repeat all > of the details from section 4. For example, section 6.1.3 steps (b) and > (c) and section 6.1.4 step (g) discuss the processing of name > constraints, but one must read section 4.2.1.10 to understand the rules > for applying name constraints to each name form. On the other hand, > while section 4.2.1.11 provides a good textual description of the > policyConstraints extension, this section does not provide enough detail > to implement the path validation algorithm. So, if you want a general > understanding of the extension, read section 4. If you want to > implement the code to process the extension, read section 6. > > BTW, if there are places where section 6 contradicts section 4, please > point them out so that they can be fixed. But remember that the > algorithm in section 6 was not intended to verify that CAs issued > certificates and CRLs in conformance with section 4. So, if there is a > requirement in section 4 of the form "conforming CAs MUST ...", there > may not be a corresponding requirement imposed in relying parties. > > Dave > > Peter Gutmann wrote: > >> Sam Roberts writes: >> >>> agree that allow-all or deny-all is sensible, and special-casing two >>> of the >>> bits would be weird, but isn't allow-all what is specified now? >> >> >> Nope. See below. >> >>> This interpretation is based on the validation rules, section 6.1.4, >>> rule >>> (n): >>> >>> If a key usage extension is present, verify that the keyCertSign bit >>> is set. >> >> >> Oh, section 6 contradicts section 4 in a number of places, I take >> section 4 as >> definitive since it specifies the intent of the spec whereas section 6 >> only >> contains an attempt at implementing that intent. >> >> (Another proposed improvement for bride-of-3280, indicate which of >> section 4 >> or 6 is definitive in the case of conflict). >> >>> I can't see anything that says that absence of Key Usage should >>> trigger chain >>> validation failure. >> >> >> The exact text I quoted earlier, i.e: >> >> Conforming CAs MUST include this extension in certificates that contain >> public keys that are used to validate digital signatures on other >> public key >> certificates or CRLs. >> >>> Its a long RFC, an you point to the text you are "squinting sideways" >>> at? >> >> >> The keyUsage text, which covers the use of keyUsage in a very obtuse way. >> What the above is trying to say in a very roundabout way is: >> >> CA certificates must include a keyUsage extension with keyCertSign or >> crlSign bits set as appropriate. >> >>> Why MUST an end-entity cert include a Key Usage, not including it is >>> a good >>> way of specifying allow-all. You want to forbid allow-all? >> >> >> No, I want to make it explicit. As your message shows, at least one PKIX >> member (not to mention an unknown but significant number of non-PKIX >> people) >> find the current text/usage quite confusing :-). Since virtually all CAs >> already include keyUsage, explicitly requiring it would fix the >> problem at >> virtually zero cost to implementors. >> >> Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDmUIr083945; Tue, 31 May 2005 06:48:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VDmUtZ083944; Tue, 31 May 2005 06:48:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDmTRp083937 for ; Tue, 31 May 2005 06:48:29 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4VDm7fC012295; Tue, 31 May 2005 09:48:21 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4VDlg6u021880; Tue, 31 May 2005 09:47:42 -0400 (EDT) Message-ID: <429C6B1F.5070506@nist.gov> Date: Tue, 31 May 2005 09:48:15 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: pkix Subject: Re: Absent keyUsage in certificates References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, This seems to be an issue that has caused confusion for several people, as Sam Roberts pointed out to me in another forum (http://cio.nist.gov/esd/emaildir/lists/pkits/msg00108.html). When the keyUsage extension is absent, then the key can be used for any purpose (except as restricted by the basicConstraints, extendedKeyUsage, certificatePolicies, etc. extensions as Stefan mentioned). The text that you quoted was intentionally written as "Conforming CAs MUST ..." because it is a requirement that ONLY applies to CAs. So, section 4 and 6 are not contradictory. The text from section 4 that you quoted imposes a requirement on CAs, but does not apply to relying parties. The text that Sam quoted from section 6 is part of the path validation algorithm, which is used by relying parties but not CAs. The basic idea is that while the PKIX Certificate and CRL profile (RFC 3280, 3280bis) imposes stricter certificate and CRL generation requirements than X.509 does, there is no requirement to reject a certification path that is valid under X.509 simply because it was not issued in conformance with the PKIX profile. While it would be nice if every CA followed the PKIX profile of X.509, I don't think PKIX should mandate that certificates be rejected simply because they were issued in accordance with a profile of X.509 that does not conform to the PKIX profile. This is the reason that the path validation algorithm in RFC 3280 and 3280bis was designed to accept any certification path that is valid under X.509 and it does not include checks to verify that certificates were issued in conformance to the PKIX profile. So, even if PKIX required all certificates to include a keyUsage extension, this could only be a requirement for conforming CAs, not relying parties. Sam suggested that I add text to section 6 of 3280bis clearly stating that the PKIX path validation algorithm is designed to accept any certification path that is valid under X.509, not just those that were issued in conformance with the PKIX profile. He made the suggestion a few days after the -00 draft was originally submitted, but I intend to include this text in the -01 draft. As to your question about whether section 4 takes precedence over section 6 or vice versa, I don't think there is a real answer. In general, section 6 provides the definitive explanation of how to perform certification path validation. However, section 6 does not repeat all of the details from section 4. For example, section 6.1.3 steps (b) and (c) and section 6.1.4 step (g) discuss the processing of name constraints, but one must read section 4.2.1.10 to understand the rules for applying name constraints to each name form. On the other hand, while section 4.2.1.11 provides a good textual description of the policyConstraints extension, this section does not provide enough detail to implement the path validation algorithm. So, if you want a general understanding of the extension, read section 4. If you want to implement the code to process the extension, read section 6. BTW, if there are places where section 6 contradicts section 4, please point them out so that they can be fixed. But remember that the algorithm in section 6 was not intended to verify that CAs issued certificates and CRLs in conformance with section 4. So, if there is a requirement in section 4 of the form "conforming CAs MUST ...", there may not be a corresponding requirement imposed in relying parties. Dave Peter Gutmann wrote: > Sam Roberts writes: > >> agree that allow-all or deny-all is sensible, and special-casing two >> of the >> bits would be weird, but isn't allow-all what is specified now? > > Nope. See below. > >> This interpretation is based on the validation rules, section 6.1.4, rule >> (n): >> >> If a key usage extension is present, verify that the keyCertSign bit >> is set. > > Oh, section 6 contradicts section 4 in a number of places, I take > section 4 as > definitive since it specifies the intent of the spec whereas section 6 > only > contains an attempt at implementing that intent. > > (Another proposed improvement for bride-of-3280, indicate which of > section 4 > or 6 is definitive in the case of conflict). > >> I can't see anything that says that absence of Key Usage should >> trigger chain >> validation failure. > > The exact text I quoted earlier, i.e: > > Conforming CAs MUST include this extension in certificates that contain > public keys that are used to validate digital signatures on other > public key > certificates or CRLs. > >> Its a long RFC, an you point to the text you are "squinting sideways" at? > > The keyUsage text, which covers the use of keyUsage in a very obtuse way. > What the above is trying to say in a very roundabout way is: > > CA certificates must include a keyUsage extension with keyCertSign or > crlSign bits set as appropriate. > >> Why MUST an end-entity cert include a Key Usage, not including it is >> a good >> way of specifying allow-all. You want to forbid allow-all? > > No, I want to make it explicit. As your message shows, at least one PKIX > member (not to mention an unknown but significant number of non-PKIX > people) > find the current text/usage quite confusing :-). Since virtually all CAs > already include keyUsage, explicitly requiring it would fix the problem at > virtually zero cost to implementors. > > Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDisnf083699; Tue, 31 May 2005 06:44:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VDisXS083698; Tue, 31 May 2005 06:44:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4VDir4X083689 for ; Tue, 31 May 2005 06:44:53 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id CCCC4100C5 for ; Tue, 31 May 2005 09:44:47 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12999-36 for ; Tue, 31 May 2005 09:44:34 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id F00F4100C1 for ; Tue, 31 May 2005 09:44:33 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005053109434147-63918 ; Tue, 31 May 2005 09:43:41 -0400 Date: Tue, 31 May 2005 09:44:33 -0400 From: Sam Roberts To: ietf-pkix@imc.org Subject: Re: Absent keyUsage in certificates Message-ID: <20050531134433.GA30174@certicom.com> Mail-Followup-To: ietf-pkix@imc.org References: <3C69AE30038D9A4590F5EC20DCD41F6806974716@RED-MSG-41.redmond.corp.microsoft.com> Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/31/2005 09:43:41 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/31/2005 09:43:41 AM, Serialize complete at 05/31/2005 09:43:41 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Peter Gutmann , on Tue, May 31, 2005 at 08:56:51PM +1200: > "David Cross" writes: > >In fact, many many companies and oragnizations have demanded the acceptance > >and usage by applications EE certs with this extension absent to indicate all > >purposes. > > All purposes except cert/CRL signing, you mean. Or do they really want to > use them for all purposes, including cert/CRL signing/verification? cert signing requires a BasicConstraints, so its disallowed for other reasons even if the KeyUsage is absent. I don't see the problem you would like to fix. Are you saying that its easier for a CA to mistakenly not include a KeyUsage than it is to mistakenly include a KeyUsage with all bits set? Since I regularly see certs that don't obey PKIX MUST encoding rules, and we have to be able to "work" with them anyhow, other than allowing us to gripe about certs we see that are wrong, I don't see how this change will help or hinder implementors. So, I'll bow out of the discussion. Cheers, Sam -- http://www.certicom.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDZa28083026; Tue, 31 May 2005 06:35:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VDZaLB083025; Tue, 31 May 2005 06:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mx.ditec.sk (mx.ditec.sk [62.65.178.4]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VDZVLI083000 for ; Tue, 31 May 2005 06:35:33 -0700 (PDT) (envelope-from vittek@ditec.sk) Received: from apps.intra.ditec.sk ([172.24.1.23] RDNS failed) by mx.ditec.sk with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 15:35:25 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: CRL sequence issues Date: Tue, 31 May 2005 15:35:24 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CRL sequence issues Thread-Index: AcVl5ZlgsStKfeuXRrmdg5PyOywmPA== From: "Vittek Robert" To: X-OriginalArrivalTime: 31 May 2005 13:35:25.0171 (UTC) FILETIME=[99C5A430:01C565E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4VDZaLI083018 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear gentlemen, I am involved in development of a system that is supposed to process electronically signed documents (possibly ten thousands per hour) while the response time (on the question if the signature is valid or not) should be "as low as possible". At the same time, it is crucial that the response is correct because a mistake can have serious legal consequences. I have questions concerning certificate status validation when CRLs are the revocation mechanism. All of the references are made to RFC 3280. CRL Validation algorithm described in 6.3 assumes usage of a local cache and somehow alibistically "assumes that all of the needed CRLs are available in a local cache". In 6.3.3, there are some rules to be followed on fetching all needed CRLs, one of them being very interesting. (2) If the current time is before the value of the next update field and use-deltas is set, then obtain the current delta CRL that can be used to update the locally cached complete CRL as specified in section 5.2.4. There is no rule specified if use-deltas is not set. At the same time description of Next Update field (5.1.2.5) says: This field indicates the date by which the next CRL will be issued. The next CRL could be issued before the indicated date, but it will not be issued any later than the indicated date. So, there is a possibility that a complete CRL has been issued invalidating the one in local cache for the time in question (e.g. from Time Stamp Token) and this CRL should be downloaded. I think that the above mentioned paragraph in 6.3.3 should be modified to obtain a complete CRL in any case or at least make a check. Anyway, it's been kind of a theoretical problem so far. In real world it is not feasible to make HTTP or FTP call to CA for every validated signature at the rate "ten thousands per hour". Even if it was, how can I be sure (using untrusted HTTP or FTP communication with most of CAs) that some traitor did not fetch my request and did not provided me with older CRL which still has next update field greater than time from TST. I can not. My uncertainty will disappear only after a CRL with ThisUpdate greater than TST is issued and I have downloaded all CRLs issued so far. Btw, CRL with ThisUpdate greater than TST is sometimes the first CRL that can invalidate a revoked certificate which makes the rules for fetching CRLs in algorithm for CRL Validation all erroneous. So, this leads me to a question what mechanism can be exploited to ensure that I have downloaded a complete set of CRLs issued so far. First, I thought that crlNumber is sufficient. But crlNumbers must convey only monotonically increasing sequence - NOT LINEAR sequence. That means, some of the numbers can be omitted and I have no means to determine it. Do you have any suggestions? Moreover, it may be critical to be sure to download the next CRL issued right after TST, because RFC 3280 states that: A complete CRL lists all unexpired certificates, within its scope, that have been revoked for one of the revocation reasons covered by the CRL scope. An entry is added to the CRL as part of the next update following notification of revocation. An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate's validity period. If TST < Cert.validTo < CRL(n).thisUpdate then CRL(n) is crucial for certificate status validation with respect to Time Stamp Token. Another reason to have a mechanism for a check if I am missing some CRL from sequence or not. Otherwise, there are cases when one is not able to say if a certificate was valid at TST time or not, hence if the signature is valid wrt. TST. Maybe, I am just missing something in RFC 3280 (or any other) that will suddenly make everything clear to me. In that case I apologize to the readers of this forum. Sincerely, Mgr. Robert Vittek DITEC, a.s. Bratislava Business Center V Plynárenská 7/C 821 09 Bratislava voice: +421 2 58 222 487 fax: +421 2 58 222 777 cell: +421 908 797 827 e-mail: vittek@ditec.sk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VD5DYL079804; Tue, 31 May 2005 06:05:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VD5Dcd079803; Tue, 31 May 2005 06:05:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VD5BZ6079756 for ; Tue, 31 May 2005 06:05:12 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 14:05:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Absent keyUsage in certificates Date: Tue, 31 May 2005 14:05:01 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Absent keyUsage in certificates Thread-Index: AcVlyi8zZEoN/dETS96aqt/ykZjh3wAFo0+w From: "Stefan Santesson" To: "Peter Gutmann" , "David Cross" , , X-OriginalArrivalTime: 31 May 2005 13:05:06.0060 (UTC) FILETIME=[5D7F54C0:01C565E1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4VD5CZ6079790 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, > >In fact, many many companies and oragnizations have demanded the > acceptance > >and usage by applications EE certs with this extension absent to indicate > all > >purposes. > > All purposes except cert/CRL signing, you mean. Or do they really want to > use them for all purposes, including cert/CRL signing/verification? All purposes that is consistent with the rest of the certificate. Since Basic Constraints MUST be present in CA certificates, this automatically excludes CRL/Cert signing for EE certs. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Peter Gutmann > Sent: den 31 maj 2005 10:57 > To: David Cross; ietf-pkix@imc.org; sroberts@certicom.com > Subject: RE: Absent keyUsage in certificates > > > "David Cross" writes: > > >I agree for CA certificates, the Key Usage extension MUST be asserted. > >However, in client (end entity) certificates, this is extremely > >disadvantageous as it makes deployments and future application > consumption > >difficult. > > In what way? Why can't you just set all the flags that make sense (e.g. > all > encryption and signing flags for an RSA key)? At the moment the few certs > I've seen with keyUsage absent seem to be more an indication of CA error > than > an intent to allow them to be used for any purpose (e.g. ones that have no > X.509 keyUsage but do have a Netscape keyUsage that doesn't match an all- > purpose usage, or ones where the CA, when questioned, admitted that that > wasn't at all what they'd intended). Making keyUsage mandatory everywhere > would make the CA's intent explicit. > > >In fact, many many companies and oragnizations have demanded the > acceptance > >and usage by applications EE certs with this extension absent to indicate > all > >purposes. > > All purposes except cert/CRL signing, you mean. Or do they really want to > use them for all purposes, including cert/CRL signing/verification? > > Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8wVXn092146; Tue, 31 May 2005 01:58:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4V8wVtE092145; Tue, 31 May 2005 01:58:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8wOfS092109 for ; Tue, 31 May 2005 01:58:25 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 May 2005 09:58:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Absent keyUsage in certificates Date: Tue, 31 May 2005 09:58:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Absent keyUsage in certificates Thread-Index: AcVlPLddOVfqhHUIQE2B/sqYjbi52gAgS1iA From: "Stefan Santesson" To: "Peter Gutmann" , , X-OriginalArrivalTime: 31 May 2005 08:58:16.0793 (UTC) FILETIME=[E27C8490:01C565BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4V8wPfS092128 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'm not sure I get the problem or what has to be fixed. This extension defines the use of the public key in the certificate. So obviously, in absence of this extension the usage is simply undefined in the context of this extension. The use of the public key may however still be constrained by other means, such as certificate policy, EKU, Basic Constraints etc. So it is not correct to define that absent key usage extension = all usages. The key usage extension is already required for CA certs. /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Peter Gutmann > Sent: den 30 maj 2005 18:31 > To: ietf-pkix@imc.org; sroberts@certicom.com > Subject: Re: Absent keyUsage in certificates > > > Sam Roberts writes: > > >I agree that allow-all or deny-all is sensible, and special-casing two of > the > >bits would be weird, but isn't allow-all what is specified now? > > Nope. See below. > > >This interpretation is based on the validation rules, section 6.1.4, rule > >(n): > > > > If a key usage extension is present, verify that the keyCertSign bit > > is set. > > Oh, section 6 contradicts section 4 in a number of places, I take section > 4 as > definitive since it specifies the intent of the spec whereas section 6 > only > contains an attempt at implementing that intent. > > (Another proposed improvement for bride-of-3280, indicate which of section > 4 > or 6 is definitive in the case of conflict). > > >I can't see anything that says that absence of Key Usage should trigger > chain > >validation failure. > > The exact text I quoted earlier, i.e: > > Conforming CAs MUST include this extension in certificates that contain > public keys that are used to validate digital signatures on other public > key > certificates or CRLs. > > >Its a long RFC, an you point to the text you are "squinting sideways" at? > > The keyUsage text, which covers the use of keyUsage in a very obtuse way. > What the above is trying to say in a very roundabout way is: > > CA certificates must include a keyUsage extension with keyCertSign or > crlSign bits set as appropriate. > > >Why MUST an end-entity cert include a Key Usage, not including it is a > good > >way of specifying allow-all. You want to forbid allow-all? > > No, I want to make it explicit. As your message shows, at least one PKIX > member (not to mention an unknown but significant number of non-PKIX > people) > find the current text/usage quite confusing :-). Since virtually all CAs > already include keyUsage, explicitly requiring it would fix the problem at > virtually zero cost to implementors. > > Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8ukp8091694; Tue, 31 May 2005 01:56:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4V8ukRi091693; Tue, 31 May 2005 01:56:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V8ujBe091677 for ; Tue, 31 May 2005 01:56:45 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id DEC493403C; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25382-02; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id C69983402A; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 917D237742; Tue, 31 May 2005 20:56:44 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Dd2YN-00016k-00; Tue, 31 May 2005 20:56:51 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dcross@microsoft.com, ietf-pkix@imc.org, sroberts@certicom.com Subject: RE: Absent keyUsage in certificates In-Reply-To: <3C69AE30038D9A4590F5EC20DCD41F6806974716@RED-MSG-41.redmond.corp.microsoft.com> Message-Id: Date: Tue, 31 May 2005 20:56:51 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David Cross" writes: >I agree for CA certificates, the Key Usage extension MUST be asserted. >However, in client (end entity) certificates, this is extremely >disadvantageous as it makes deployments and future application consumption >difficult. In what way? Why can't you just set all the flags that make sense (e.g. all encryption and signing flags for an RSA key)? At the moment the few certs I've seen with keyUsage absent seem to be more an indication of CA error than an intent to allow them to be used for any purpose (e.g. ones that have no X.509 keyUsage but do have a Netscape keyUsage that doesn't match an all- purpose usage, or ones where the CA, when questioned, admitted that that wasn't at all what they'd intended). Making keyUsage mandatory everywhere would make the CA's intent explicit. >In fact, many many companies and oragnizations have demanded the acceptance >and usage by applications EE certs with this extension absent to indicate all >purposes. All purposes except cert/CRL signing, you mean. Or do they really want to use them for all purposes, including cert/CRL signing/verification? Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V5x7pI025532; Mon, 30 May 2005 22:59:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4V5x7IQ025531; Mon, 30 May 2005 22:59:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V5x5As025487 for ; Mon, 30 May 2005 22:59:06 -0700 (PDT) (envelope-from dcross@microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 May 2005 22:58:01 -0700 Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 May 2005 22:58:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Absent keyUsage in certificates Date: Mon, 30 May 2005 22:57:58 -0700 Message-ID: <3C69AE30038D9A4590F5EC20DCD41F6806974716@RED-MSG-41.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Absent keyUsage in certificates Thread-Index: AcVlLyJra6ejgDTPQHOh1hfjFoWoAgAYetKA From: "David Cross" To: "Sam Roberts" , X-OriginalArrivalTime: 31 May 2005 05:58:05.0341 (UTC) FILETIME=[B65BDCD0:01C565A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4V5x6As025519 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree for CA certificates, the Key Usage extension MUST be asserted. However, in client (end entity) certificates, this is extremely disadvantageous as it makes deployments and future application consumption difficult. In fact, many many companies and oragnizations have demanded the acceptance and usage by applications EE certs with this extension absent to indicate all purposes. David B. Cross -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Sam Roberts Sent: Monday, May 30, 2005 7:25 AM To: ietf-pkix@imc.org Subject: Re: Absent keyUsage in certificates Wrote Peter Gutmann , on Mon, May 30, 2005 at 09:04:15PM +1200: > If anyone from Verisign-called-Thawte is reading this, could you > please fix your certs to include the keyUsage extension? They're > currently being issued without any keyUsage indication (or at least > some of them are), which is causing some debate about how to apply > them (the contact details I have for someone at Verisign seem to be out of date). > > Also, could the current wording around keyUsage in bride-of-3280 be > improved to indicate what the correct usage is if the extension is > absent? Squinting at the text sideways, it currently says that the > key can be used for anything > *except* cert and CRL verification, a rather strange > allow-some/deny-some interpretation when it's more normal to have a > default of either allow-all or deny-all (fail-open/fail-closed) in the > absence of any further instructions, I agree that allow-all or deny-all is sensible, and special-casing two of the bits would be weird, but isn't allow-all what is specified now? This interpretation is based on the validation rules, section 6.1.4, rule (n): If a key usage extension is present, verify that the keyCertSign bit is set. I can't see anything that says that absence of Key Usage should trigger chain validation failure. Its a long RFC, an you point to the text you are "squinting sideways" at? > but this is quite hard to see for anyone who doesn't already know in > advance how keyUsage works. The sentence "Conforming CAs MUST include > this extension in certificates that contain public keys that are used > to validate digital signatures on other public key certificates or CRLs" is particularly obtuse. > > I would suggest adding either: > > Conforming CAs MUST include this extension in all certificates. Why MUST an end-entity cert include a Key Usage, not including it is a good way of specifying allow-all. You want to forbid allow-all? Cheers, Sam -- http://www.certicom.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGUVtQ044565; Mon, 30 May 2005 09:30:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UGUVMF044564; Mon, 30 May 2005 09:30:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UGUUXB044556 for ; Mon, 30 May 2005 09:30:30 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 66104343A7; Tue, 31 May 2005 04:30:29 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17495-13; Tue, 31 May 2005 04:30:29 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 4B9FF34330; Tue, 31 May 2005 04:30:29 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0FA8337749; Tue, 31 May 2005 04:30:29 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Dcn9v-0002lU-00; Tue, 31 May 2005 04:30:35 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, sroberts@certicom.com Subject: Re: Absent keyUsage in certificates In-Reply-To: <20050530142442.GA2272@certicom.com> Message-Id: Date: Tue, 31 May 2005 04:30:35 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Roberts writes: >I agree that allow-all or deny-all is sensible, and special-casing two of the >bits would be weird, but isn't allow-all what is specified now? Nope. See below. >This interpretation is based on the validation rules, section 6.1.4, rule >(n): > > If a key usage extension is present, verify that the keyCertSign bit > is set. Oh, section 6 contradicts section 4 in a number of places, I take section 4 as definitive since it specifies the intent of the spec whereas section 6 only contains an attempt at implementing that intent. (Another proposed improvement for bride-of-3280, indicate which of section 4 or 6 is definitive in the case of conflict). >I can't see anything that says that absence of Key Usage should trigger chain >validation failure. The exact text I quoted earlier, i.e: Conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs. >Its a long RFC, an you point to the text you are "squinting sideways" at? The keyUsage text, which covers the use of keyUsage in a very obtuse way. What the above is trying to say in a very roundabout way is: CA certificates must include a keyUsage extension with keyCertSign or crlSign bits set as appropriate. >Why MUST an end-entity cert include a Key Usage, not including it is a good >way of specifying allow-all. You want to forbid allow-all? No, I want to make it explicit. As your message shows, at least one PKIX member (not to mention an unknown but significant number of non-PKIX people) find the current text/usage quite confusing :-). Since virtually all CAs already include keyUsage, explicitly requiring it would fix the problem at virtually zero cost to implementors. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UEP2iH036681; Mon, 30 May 2005 07:25:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4UEP2hI036680; Mon, 30 May 2005 07:25:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4UEOxfY036670 for ; Mon, 30 May 2005 07:25:01 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 53F5D100A8 for ; Mon, 30 May 2005 10:24:58 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08340-49 for ; Mon, 30 May 2005 10:24:44 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 5285110090 for ; Mon, 30 May 2005 10:24:44 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005053010235216-47701 ; Mon, 30 May 2005 10:23:52 -0400 Date: Mon, 30 May 2005 10:24:42 -0400 From: Sam Roberts To: ietf-pkix@imc.org Subject: Re: Absent keyUsage in certificates Message-ID: <20050530142442.GA2272@certicom.com> Mail-Followup-To: ietf-pkix@imc.org References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/30/2005 10:23:52 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/30/2005 10:23:53 AM, Serialize complete at 05/30/2005 10:23:53 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Peter Gutmann , on Mon, May 30, 2005 at 09:04:15PM +1200: > If anyone from Verisign-called-Thawte is reading this, could you please fix > your certs to include the keyUsage extension? They're currently being issued > without any keyUsage indication (or at least some of them are), which is > causing some debate about how to apply them (the contact details I have for > someone at Verisign seem to be out of date). > > Also, could the current wording around keyUsage in bride-of-3280 be improved > to indicate what the correct usage is if the extension is absent? Squinting > at the text sideways, it currently says that the key can be used for anything > *except* cert and CRL verification, a rather strange allow-some/deny-some > interpretation when it's more normal to have a default of either allow-all or > deny-all (fail-open/fail-closed) in the absence of any further instructions, I agree that allow-all or deny-all is sensible, and special-casing two of the bits would be weird, but isn't allow-all what is specified now? This interpretation is based on the validation rules, section 6.1.4, rule (n): If a key usage extension is present, verify that the keyCertSign bit is set. I can't see anything that says that absence of Key Usage should trigger chain validation failure. Its a long RFC, an you point to the text you are "squinting sideways" at? > but this is quite hard to see for anyone who doesn't already know in advance > how keyUsage works. The sentence "Conforming CAs MUST include this extension > in certificates that contain public keys that are used to validate digital > signatures on other public key certificates or CRLs" is particularly obtuse. > > I would suggest adding either: > > Conforming CAs MUST include this extension in all certificates. Why MUST an end-entity cert include a Key Usage, not including it is a good way of specifying allow-all. You want to forbid allow-all? Cheers, Sam -- http://www.certicom.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U9Jlf8018229; Mon, 30 May 2005 02:19:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4U9Jl46018228; Mon, 30 May 2005 02:19:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U9JkD2018217 for ; Mon, 30 May 2005 02:19:46 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 070CF34F63; Mon, 30 May 2005 21:19:46 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03711-21; Mon, 30 May 2005 21:19:45 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id D8850340D3; Mon, 30 May 2005 21:19:44 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CAA2637748; Mon, 30 May 2005 21:19:44 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DcgR2-0002RO-00; Mon, 30 May 2005 21:19:48 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: dpkemp@missi.ncsc.mil, ietf-pkix@imc.org Subject: Re: 3280bis: key usage (13) In-Reply-To: <200505271835.j4RIZ1xD022249@stingray.missi.ncsc.mil> Message-Id: Date: Mon, 30 May 2005 21:19:48 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "David P. Kemp" writes: >The suggestion at the time was to consider ephemeral signatures (entity >authentication w/ liveness) to be purpose A, and persistent signatures (data >origin authentication / integrity with no implication of presence/liveness) >to be purpose B. That view was roundly rejected by all present, who >subscribed to Stefan's theory of contagious fuzziness. Uhh, just for the record, I've always supported this interpretation, it's simple, straightforward, and easy to understand. From private discussions in the past that there are others here who support this as well, but they tend to fall into the class of PKI app developers/implementors, who have mostly abandoned this list or use it purely in read-only mode. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U94EZb012758; Mon, 30 May 2005 02:04:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4U94Eok012756; Mon, 30 May 2005 02:04:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4U94D4Z012735 for ; Mon, 30 May 2005 02:04:14 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 2E76B3544C for ; Mon, 30 May 2005 21:04:12 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27262-27 for ; Mon, 30 May 2005 21:04:12 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 15D5634F63 for ; Mon, 30 May 2005 21:04:11 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id B5E6A37748 for ; Mon, 30 May 2005 21:04:11 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DcgBz-0002Qr-00 for ; Mon, 30 May 2005 21:04:15 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org Subject: Absent keyUsage in certificates Message-Id: Date: Mon, 30 May 2005 21:04:15 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If anyone from Verisign-called-Thawte is reading this, could you please fix your certs to include the keyUsage extension? They're currently being issued without any keyUsage indication (or at least some of them are), which is causing some debate about how to apply them (the contact details I have for someone at Verisign seem to be out of date). Also, could the current wording around keyUsage in bride-of-3280 be improved to indicate what the correct usage is if the extension is absent? Squinting at the text sideways, it currently says that the key can be used for anything *except* cert and CRL verification, a rather strange allow-some/deny-some interpretation when it's more normal to have a default of either allow-all or deny-all (fail-open/fail-closed) in the absence of any further instructions, but this is quite hard to see for anyone who doesn't already know in advance how keyUsage works. The sentence "Conforming CAs MUST include this extension in certificates that contain public keys that are used to validate digital signatures on other public key certificates or CRLs" is particularly obtuse. I would suggest adding either: Conforming CAs MUST include this extension in all certificates. (by far the simplest solution, there's no reason not to include this in a cert, it's at the same level as basicConstraints, and virtually every CA in existence does it anyway), or at least: Where this extension is absent, the certificate may be used for all purposes that the public-key algorithm is capable of except certificate and CRL signing and validation. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4SKcGD2082132; Sat, 28 May 2005 13:38:16 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4SKcGPF082131; Sat, 28 May 2005 13:38:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (STRATTON-THREE-SIXTY-NINE.MIT.EDU [18.187.6.114]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4SKcFrV082123 for ; Sat, 28 May 2005 13:38:16 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 87EBDE0063; Sat, 28 May 2005 16:38:13 -0400 (EDT) To: Russ Housley Cc: timmoore@microsoft.com, ietf-pkix@imc.org Subject: Re: AD Review for draft-ietf-pkix-rfc3770bis References: <6.2.1.2.2.20050524104606.03fab960@mail.binhost.com> From: Sam Hartman Date: Sat, 28 May 2005 16:38:13 -0400 In-Reply-To: <6.2.1.2.2.20050524104606.03fab960@mail.binhost.com> (Russ Housley's message of "Tue, 24 May 2005 11:35:10 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, Russ. These changes look good to me and I agree they address my comments. There doesn't seem to be any disagreement from the WG, so let's send in a new draft unless we get an objection from the chairs. I believe I'm still waiting for a proto writeup from Tim. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RIb0ob003468; Fri, 27 May 2005 11:37:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RIb0so003467; Fri, 27 May 2005 11:37:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RIaxwl003459 for ; Fri, 27 May 2005 11:37:00 -0700 (PDT) (envelope-from DPKemp@missi.ncsc.mil) Message-ID: <200505271835.j4RIZ1xD022249@stingray.missi.ncsc.mil> Date: Fri, 27 May 2005 14:36:53 -0400 From: "David P. Kemp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: 3280bis: key usage (13) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2005 18:36:53.0530 (UTC) FILETIME=[0D9F2FA0:01C562EB] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David Chadwick and I argued within X.509 that if there are going to be two (or four) bits, then those bits should specify non-overlapping purposes (i.e. DS for purpose A, NR/CC/?? for purpose B, Cert-S for purpose C and CRL-S for purpose D, where A, B, C and D are mutually exclusive and collectively exhaustive). The suggestion at the time was to consider ephemeral signatures (entity authentication w/ liveness) to be purpose A, and persistent signatures (data origin authentication / integrity with no implication of presence/liveness) to be purpose B. That view was roundly rejected by all present, who subscribed to Stefan's theory of contagious fuzziness. So given that the decision has been made to create a fuzzy non-implementable definition for NR/CC, I believe PKIX should adopt Stephen's suggestion that CA's MUST set this bit to a random value. Dave Peter Gutmann wrote: >Stephen Farrell writes: > > > >>There's a bit (NR/CC) whose meaning has been the subject of loads and loads >>of rambling discussion for ages and ages, and you want to define DS= >>NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a >>bad idea. >> >> > >Oh was that what all that was about? I'd gone off to reorganise my sock >drawer and sort my packets of alphabet soup after the first 800 or so messages >went by, so I probably missed some bits. > >The motivation for the comment was that we've just gone through the >keyEncipherment vs. dataEncipherment debate where no-one's quite sure which >bits to set for what occasion, and now in an attempt to fix the equally- >problematic DS vs. NR we're creating a similar problem: what do you do in >situations where neither the DS nor CC/NR bits fit? I don't really care how >the bits are defined, as long as it doesn't end up creating un-uses that can't >be clearly signified with either DS or CC/NR. Without this, we'll get another >situation like the dataEncipherment one where something doesn't fall easily >into either choice, so users and CAs claim that their choice of DS or CC >applies, whatever happens to coincide with what their software does. > > > >> The digitalSignature bit is asserted when the subject public key >> is used for verifying digital signatures that are used >> with an entity authentication service, a data origin authentication >> service or/and an integrity service. Note that a certificate >> with only the digitalSignature bit set MUST NOT be used for >> verifying certificate or CRL signatures. >> >> > >Sounds good to me. > >Peter. > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RGqMXK092941; Fri, 27 May 2005 09:52:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RGqMoc092940; Fri, 27 May 2005 09:52:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RGqLHb092934 for ; Fri, 27 May 2005 09:52:21 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4RGqC9v019687; Fri, 27 May 2005 12:52:13 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4RGpV6u006218; Fri, 27 May 2005 12:51:31 -0400 (EDT) Message-ID: <4297502A.804@nist.gov> Date: Fri, 27 May 2005 12:51:54 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas CC: pkix Subject: Re: 3280bis: CRL validation References: <42958C32.8020706@bull.net> In-Reply-To: <42958C32.8020706@bull.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, You have been saying for some time that "CRL validation is NOT specified in RFC 3280". But, the more you post about CRL validation, the more clear it becomes that the problem is that you do not understand how CRL validation works in X.509. Further, it is not clear that the problem is with the text of X.509 or RFC 3280 or if it is just that X.509 does not work the way you believe (or want) it to work. X.509 was designed based on a model in which names are globally unique. In November on the X.500 mail list, you tried to argue otherwise, but it was demonstrated quite convincingly that this is what X.509 says: X.509, clause 8.3.2.1 (subject alternative name extension): The values in the alternatives of the GeneralName type are names of various forms as follows: – directoryName is a directory name defined in accordance with ITU-T Rec. X.501 | ISO/IEC 9594-2; (NOTE that directoryName is of type Name, which is the also the type used to define the issuer and subject fields) X.501, clause 9.1 (Definitions): 9.1.4 (directory) name: A construct that singles out a particular object from all other objects. A name shall be unambiguous (that is, denote just one object), however it need not be unique (that is, be the only name which unambiguously denotes the object). X.501, clause 9.2 (Names in General): A (directory) name is a construct that identifies a particular object from among the set of all objects. A name shall be unambiguous, that is, denotes just one object. However, a name need not be unique, that is, be the only name that unambiguously denotes the object. A (directory) name also identifies an entry. This entry is either an object entry that represents the object or an alias entry which contains information that helps the Directory to locate the entry that represents the object. An object can be assigned a distinguished name without being represented by an entry in the Directory, but this name is then the name its object entry would have had were it represented in the Directory. Syntactically, each name for an object or entry is an ordered sequence of relative distinguished names (see 9.3). Name ::= CHOICE { -- only one possibility for now -- rdnSequence RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName DistinguishedName ::= RDNSequence Note that I am not try to argue that it is impossible for two entities within a PKI to be assigned the same name, just that this would be inconsistent with the model upon which X.509 was developed. In a message to the PKIX list on April 11 about the CRL AIA draft, you wrote: > In order to build a path, a relying party needs to make sure of the > name of the CRL Issuer, which means not simply knowing the DN of the > CRL issuer but also all the other DNs from the upper CAs up to a root > key. As noted above, in X.509 an object is uniquely identified by its DN. There is no notion of forming that "name" of an object by creating a sequence of DNs. In the context of your comment above, you seem to be suggesting that the "name" of the CRL Issuer consists of the sequence of names from the certificates forming a certification path that starts at a "root" and ends with the CRL Issuer. But, this does not make sense for two reasons. First, in the X.500 series, naming is defined in X.501. That is, the concept of PKI is not used in defining naming. Second, a naming scheme like this could only work if PKIs were limited to being hierarchies, which they are not. In the same message on April 11, you wrote: > Let us consider two different scenarios where this new extension [AIA > extension in a CRL] would be considered. > > Scenario A: The relying party does not trust any CRL issuer in > particular and will simply use the CRL Issuer designated by the > Certificate Issuer by means of the CRL DP extension. > > Scenario B: The relying party trusts at least a specific CRL issuer > and will get the CRLs from that CRL Issuer and then will make sure > that the information contained in them matches with the designation of > the Certificate Issuer. X.509/RFC 3280 does not allow for scenario B. With OCSP a relying party may choose to accept status information from a locally trusted OCSP server. With CRLs, a CRL may only be used to verify the status of a certificate if the certificate explicitly indicates that CRLs from that issuer may be used. This can be done in two ways. Either (1) the certificate issuer and CRL issuer are the same entity (i.e., the issuer fields in the certificate and CRL contain the same name) or (2) the certificate includes a cRLDistributionPoints extension in which the cRLIssuer field is present and contains the name of the CRL issuer. This is covered in RFC 3280 in section 6.3.3, step (b)(1): 6.3.3 CRL Processing (b) Verify the issuer and scope of the complete CRL as follows: (1) If the DP includes cRLIssuer, then verify that the issuer field in the complete CRL matches cRLIssuer in the DP and that the complete CRL contains an issuing distribution point extension with the indrectCRL boolean asserted. Otherwise, verify that the CRL issuer matches the certificate issuer. As to your specific comments below: For issue 33, you are misinterpreting the certificateIssuer extension. The certificateIssuer extension is defined as GeneralNames so that one can include more than one name for the certificate issuer (e.g., the name from the issuer field of the certificate and one or more names from the issuerAltName extension of the certificate). That is it is a sequence (or logically a set) of names for a single entity. It is not intended to specify a certification path. As for issue 43, as I argued above, whether you like it or not, X.509 was designed based on the assumption that name collisions will not occur. (Of course a "rogue" CA could issue such certificates, but X.509 assumes that rogue CAs are untrusted (either they are never issued a certificate or certificates issued to them are revoked) so that any name collisions they create will not affect the security of the PKI). Again, you may believe that it was a bad idea to make such an assumption, but this doesn't change the fact that this assumption was used in the design of X.509. Recently, a number of people on the PKIX list, including you, have argued that it is unsafe to assume that no two authorities (e.g., CA and/or CRL issuer) will issue certificates and/or CRLs under the same name. In particular, they are concerned that at some point there will be two trusted authorities that belong to the same PKI that are issuing certificates and CRLs under the same name, that no one will detect this, and that this may result in a relying party using a CRL issued by one of the authorities to validate a certificate issued by the other authority. Since the CRL does not actually cover the certificate, it will not provide accurate information about the status of the certificate. At the IETF meeting in November, Santosh presented a proposal for a restricted version of the certification path validation algorithm that would prevent a relying party from using a CRL issued by the wrong authority to validate the status of a certificate, even if name collisions occurred, so long as no trusted CA issued two certificates to different entities with the same subject DN. At the meeting, the concern was expressed that incorporating this new algorithm into 3280bis would be too big of a change from RFC 3280 and so trying to incorporate it into 3280bis would unacceptably delay the completion of 3280bis. So, it was suggested that Santosh's proposal should be advanced in a separate document. At the same time, several people felt that if name collisions between authorities were ever going to be seen, it would be as a result of two authorities in two different PKIs using the same name, but with both authorities being trusted by a relying party as a result of the relying party using multiple trust anchors. Indicating that the certification path for a certificate and the corresponding CRL should start at the same trust anchor would prevent the use of the wrong CRL in this case. So, the initial agreement that came out of the November IETF meeting was to include a note in the security requirements section of 3280bis about the use of a common trust anchor in order to mitigate the risk that might result if a name collision ever did occur and to leave any further work on this issue to another document. Note that I am personally in favor of Santosh's proposal, mainly because I believe that imposing such restrictions on the certification path for the CRL will limit the search space for the certification path and will thus lead to more efficient implementations. While I am not particularly concerned about the name collision risk, I do not think that the restrictions that Santosh's algorithm imposes pose any problems either. However, PKIX standards, including 3280bis, are developed by consensus; I cannot simply write my own personal views into the standard. Dave Denis Pinkas wrote: > To the list, > > I changed the name of the thread which is now under 3280bis. > > As Tim mentioned: "it is clear that the current content of 3280bis > with respect to CRL validation does not enjoy consensus within the > working group". > > Issues 33 and 43 are directly related to this topic. They are both > copied below: > > 33) The certificateIssuer CRL entry extension contains a GeneralNames. > While RFC 3280 does not state this, there seems to be general > agreement that the certificateIssuer extension should only contain the > DN from the issuer field of the certificate being revoked. > > 3280bis states: "Conforming CRL issuers MUST include in [the > certificateIssuer] extension the distinguished name (DN) from the > issuer field of the certificate that corresponds to this CRL entry. > The encoding of the DN MUST be identical to the encoding used in the > certificate." > > > 43) It should be noted in 3280bis that there is a risk that two > different > CAs (or a CA and a CRL issuer) may issue certificates and CRLs under > the same name and that if this happens there is a risk that a > relying > party will validate a certificate issued by one of these entities > using a CRL issued by the other. > > The security considerations section of 3280bis states that CAs and CRL > issuers should be formed in a way that reduces the likelihood of name > collisions. It also states that implementations validating CRLs MUST > ensure that the certification path of the target certificate and the > CRL issuer certification path used to validate the target certificate > terminate at the same trust anchor. > > Both statements are incorrect. > > For issue 43: name collisions are possible and a design cannot be > based on the assumption that name collisions, whether accidental or > intentional, will never happen. This means that chosing names to > "reduce the likehood of name collisions" is not a way to solve the > issue. Termination at the same trust anchor without additional details > does not solve the issue either. > > For issue 33: the certificateIssuer extension is defined as : > > certificateIssuer ::= GeneralNames > > with > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > It is not defined as: > > certificateIssuer ::= GeneralName > > ... and this is NOT an error. > > To go directly to the point, certificateIssuer may contain in practice > either: > > - one name, or > - a sequence of names. > > If it contains one name, this means that this name MUST be certified > by the CA that has issued the certificate where the extension appears. > > If it contains a sequence of names, this means that the certification > path of the CRL issuer certificate formed using that sequence of names > MUST also terminate at the trust anchor of the target certificate. > > This is secure and avoids any name collision, either deliberate or > intentional. > > Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RGmbUl091491; Fri, 27 May 2005 09:48:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RGmbl3091490; Fri, 27 May 2005 09:48:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RGmacA091477 for ; Fri, 27 May 2005 09:48:36 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 17:48:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 17:48:28 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3280bis: key usage (13) Thread-Index: AcVi19RLqFejCjjSQrGHpadVO9E7XgAAhYoA From: "Stefan Santesson" To: "Stephen Farrell" , "Peter Gutmann" Cc: , X-OriginalArrivalTime: 27 May 2005 16:48:30.0818 (UTC) FILETIME=[E9B41420:01C562DB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4RGmbcA091484 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The problem is partly to understand what NR/CC is but the real issue why they can be mutually exclusive is that they define properties of different abstraction layers. Applications on the message layer only understand signing within the concept of data origin authentication and content integrity, they have no clue whether the signature they process is going to be used for CC/NR or not. Example: e-mail client with S/MIME signing will never know the purpose of signing. Application on the higher application layers may however know exactly why you are signing. E.g. web service enabling you to pay an invoice. This application will know whether the purpose is CC/NR and can pick the appropriate cert. So in summary, if you define DS = all signing except CC/NR, they you confuse all lower layer applications operating on the message layer who don't have a clue whether their signatures are being used for CC/NR in any higher layer context. To the text proposed by Stephen: It is not quite correct. That text forbids cert and CRL validation when only DS is set, which is close bon not exactly right. E.g. it does not prevent Cert and CRL validation when DS+NR/CC are set. I think you need to move closer to the original RFC 3280 def. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Stephen Farrell > Sent: den 27 maj 2005 17:26 > To: Peter Gutmann > Cc: Denis.Pinkas@bull.net; ietf-pkix@imc.org > Subject: Re: 3280bis: key usage (13) > > > > Peter, > > > The motivation for the comment was that we've just gone through the > > keyEncipherment vs. dataEncipherment debate where no-one's quite sure > which > > bits to set for what occasion, and now in an attempt to fix the equally- > > problematic DS vs. NR we're creating a similar problem: [...] > > Fair enough. Problem is we'll apparently never get agreement > on what NR/CC means:-( > > >> The digitalSignature bit is asserted when the subject public key > >> is used for verifying digital signatures that are used > >> with an entity authentication service, a data origin authentication > >> service or/and an integrity service. Note that a certificate > >> with only the digitalSignature bit set MUST NOT be used for > >> verifying certificate or CRL signatures. > > > > Sounds good to me. > > Cool. Let's see what happens when Denis get back so, > Stephen. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFLa69078973; Fri, 27 May 2005 08:21:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RFLZux078972; Fri, 27 May 2005 08:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFLYOR078962 for ; Fri, 27 May 2005 08:21:35 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 17BE414C029; Fri, 27 May 2005 16:21:29 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A0285F0B713; Fri, 27 May 2005 16:21:29 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id E935A14C029; Fri, 27 May 2005 16:21:28 +0100 (IST) Message-ID: <42973BF1.1080207@cs.tcd.ie> Date: Fri, 27 May 2005 16:25:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: 3280bis: key usage (13) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.734) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A1285F0B713 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, > The motivation for the comment was that we've just gone through the > keyEncipherment vs. dataEncipherment debate where no-one's quite sure which > bits to set for what occasion, and now in an attempt to fix the equally- > problematic DS vs. NR we're creating a similar problem: [...] Fair enough. Problem is we'll apparently never get agreement on what NR/CC means:-( >> The digitalSignature bit is asserted when the subject public key >> is used for verifying digital signatures that are used >> with an entity authentication service, a data origin authentication >> service or/and an integrity service. Note that a certificate >> with only the digitalSignature bit set MUST NOT be used for >> verifying certificate or CRL signatures. > > Sounds good to me. Cool. Let's see what happens when Denis get back so, Stephen. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFFvXS078622; Fri, 27 May 2005 08:15:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RFFv9j078621; Fri, 27 May 2005 08:15:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFFtdV078612 for ; Fri, 27 May 2005 08:15:55 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id DA4A334B2C; Sat, 28 May 2005 03:15:54 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06518-25; Sat, 28 May 2005 03:15:54 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 98EA4349B4; Sat, 28 May 2005 03:15:54 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 249A837756; Sat, 28 May 2005 03:15:54 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DbgZ9-0000B3-00; Sat, 28 May 2005 03:16:03 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, stephen.farrell@cs.tcd.ie Subject: Re: 3280bis: key usage (13) Cc: Denis.Pinkas@bull.net, ietf-pkix@imc.org In-Reply-To: <429735DB.9010905@cs.tcd.ie> Message-Id: Date: Sat, 28 May 2005 03:16:03 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephen Farrell writes: >There's a bit (NR/CC) whose meaning has been the subject of loads and loads >of rambling discussion for ages and ages, and you want to define DS= >NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a >bad idea. Oh was that what all that was about? I'd gone off to reorganise my sock drawer and sort my packets of alphabet soup after the first 800 or so messages went by, so I probably missed some bits. The motivation for the comment was that we've just gone through the keyEncipherment vs. dataEncipherment debate where no-one's quite sure which bits to set for what occasion, and now in an attempt to fix the equally- problematic DS vs. NR we're creating a similar problem: what do you do in situations where neither the DS nor CC/NR bits fit? I don't really care how the bits are defined, as long as it doesn't end up creating un-uses that can't be clearly signified with either DS or CC/NR. Without this, we'll get another situation like the dataEncipherment one where something doesn't fall easily into either choice, so users and CAs claim that their choice of DS or CC applies, whatever happens to coincide with what their software does. > The digitalSignature bit is asserted when the subject public key > is used for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service. Note that a certificate > with only the digitalSignature bit set MUST NOT be used for > verifying certificate or CRL signatures. Sounds good to me. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFDgbm078382; Fri, 27 May 2005 08:13:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RFDgis078381; Fri, 27 May 2005 08:13:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RFDfxK078355 for ; Fri, 27 May 2005 08:13:41 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 16:13:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 16:13:33 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3280bis: key usage (13) Thread-Index: AcViylkAK5peyTz2SUqD3Eki9N1xcAAA9amQ From: "Stefan Santesson" To: "David A. Cooper" , "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 27 May 2005 15:13:35.0616 (UTC) FILETIME=[A7193800:01C562CE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4RFDfxK078375 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Agree with David. We need to preserve the old logic in this regard. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of David A. Cooper > Sent: den 27 maj 2005 15:51 > To: Denis Pinkas > Cc: pkix > Subject: Re: 3280bis: key usage (13) > > > Denis, > > I do not agree with your proposal for the digitalSignature bit. Here is > the current text: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > This text merely states that setting the digitalSignature bit, by > itself, does not authorize relying parties to use the subject public key > to verify signatures on certificates or CRLs. It does not prevent a CA > from setting digitalSignature, keyCertSign, and cRLSign in the same > certificate. > > Imposing this restriction would, for example, prevent a CA from using > its certificate signing key to also sign OCSP responses. > > Denis Pinkas wrote: > > > Stephen, > > > > Just before leaving my office in a few minutes for a few days, > > here is a new text proposal for the DS bit: > > > > New proposal for 3280bis: > > > > The digitalSignature bit is asserted when the subject public key > > is used for verifying digital signatures that are used > > with an entity authentication service, a data origin authentication > > service or/and an integrity service. However, it SHALL not be set > > when certificate signing (bit 5) or CRL signing (bit 6) is set. > > > > Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REwfmB076175; Fri, 27 May 2005 07:58:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4REwftT076174; Fri, 27 May 2005 07:58:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REweja076150 for ; Fri, 27 May 2005 07:58:40 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4REwb8e004613 for ; Fri, 27 May 2005 10:58:39 -0400 From: "Santosh Chokhani" To: "'pkix'" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 10:58:32 -0400 Message-ID: <003d01c562cc$90550ab0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <429725BB.4000105@nist.gov> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I agree with David Cooper. In addition to David's argument, Dennis's proposal will also break many known PKI implementation for no security or interoperability reasons. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of David A. Cooper Sent: Friday, May 27, 2005 9:51 AM To: Denis Pinkas Cc: pkix Subject: Re: 3280bis: key usage (13) Denis, I do not agree with your proposal for the digitalSignature bit. Here is the current text: The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. This text merely states that setting the digitalSignature bit, by itself, does not authorize relying parties to use the subject public key to verify signatures on certificates or CRLs. It does not prevent a CA from setting digitalSignature, keyCertSign, and cRLSign in the same certificate. Imposing this restriction would, for example, prevent a CA from using its certificate signing key to also sign OCSP responses. Denis Pinkas wrote: > Stephen, > > Just before leaving my office in a few minutes for a few days, here is > a new text proposal for the DS bit: > > New proposal for 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service. However, it SHALL not be set > when certificate signing (bit 5) or CRL signing (bit 6) is set. > > Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REtfr9075214; Fri, 27 May 2005 07:55:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4REtfVk075213; Fri, 27 May 2005 07:55:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REtec3075180 for ; Fri, 27 May 2005 07:55:40 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id BBEA114C067; Fri, 27 May 2005 15:55:32 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A01EA0B5AB8; Fri, 27 May 2005 15:55:32 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id 8DC6B14C067; Fri, 27 May 2005 15:55:32 +0100 (IST) Message-ID: <429735DB.9010905@cs.tcd.ie> Date: Fri, 27 May 2005 15:59:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: Denis.Pinkas@bull.net, ietf-pkix@imc.org Subject: Re: 3280bis: key usage (13) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.733) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A11EA0B5AB8 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Peter Gutmann wrote: > Wouldn't it be better to say that it's used for purposes other than CC? By > saying that DS can only be used for purposes A, B, and C, and CC for purpose > D, what happens if someone wants to mark a key for purpose E? Since CC seems > to be the more restrictive, it would be better to say that DS is to be used > for everything else. If not, we'd need a third signature bit to cover the > 'other' category that's explicitly excluded from DS and CC. You're kidding, right? There's a bit (NR/CC) whose meaning has been the subject of loads and loads of rambling discussion for ages and ages, and you want to define DS=NOT(NR/CC)? Sounds like a great way to spread the NR fuzziness around, i.e. a bad idea. >>However, it SHALL not be set when certificate signing (bit 5) or CRL signing >>(bit 6) is set. > > Why not? The intent of the original text was to say that > digitalSignature doesn't mean you can use the cert for cert/CRL > signing, now it says something completely different, that a > cert-signing cert can never be used for any other purpose. This > wording change would make a number of CAs non-compliant, since > they do use their CA certs for other purposes (don't ask me why, > I just see the things turn up from time to time). The wording > should be something like "Setting this bit doesn't mean the > cert can be used for cert or CRL signing; for that, you need > to set the cert/CRL signing bits". You're right there (as is David C.) So we should replace Denis' last sentence with something like yours, giving maybe: The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures that are used with an entity authentication service, a data origin authentication service or/and an integrity service. Note that a certificate with only the digitalSignature bit set MUST NOT be used for verifying certificate or CRL signatures. And the certificate and CRL signing bits are described elsewhere. Stephen. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REhutQ074306; Fri, 27 May 2005 07:43:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4REhurc074305; Fri, 27 May 2005 07:43:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4REhtRc074298 for ; Fri, 27 May 2005 07:43:55 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4REhq8e021374 for ; Fri, 27 May 2005 10:43:53 -0400 From: "Santosh Chokhani" To: "'pkix'" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 10:43:47 -0400 Message-ID: <003001c562ca$803aa510$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C562A8.F9290510" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <5.1.0.14.0.20050527090001.00b128d0@172.16.146.192> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C562A8.F9290510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X.509 V1 or V2 did not have any extensions. Thus, neither key usage nor certificate policies were part of v1 or v2. These extensions came about = in v3. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On Behalf Of Kazin, Joel Sent: Friday, May 27, 2005 9:20 AM To: Stefan Santesson; Denis Pinkas; Stephen Farrell Cc: Hoyt L Kesterson II; pkix Subject: RE: 3280bis: key usage (13) The core problem is labeling the bit non-repudiation. It goes against = the legal idea that you can attempt to repudiate your alleged actions even = when your defense is weaker than "the cat ate my homework". To me, non-repudiation is more of a marketing description than a technical, contractual, or legal description of what the signer intended to do. =20 A secondary problem is that the non-repudiation bit doesn't tell a = relying party or third party enough. The logical place to look for such = information is in the id-ce-certificatePolicies extension. Was the id-ce-certificatePolicies extension part of the original x.509 v1 specification? If that is true, then perhaps the non-repudiation bit is just a holdover from the original x.509 v1 certificate definition? If = my arguments are true then we can: 1) keep calling it non-repudiation and strongly deprecate its use, 2) change the name and deprecate its use, 3) change the name and allow its use. I favor 1 over 2 over 3. =20 At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote: Speaking as implementer and not design team member, I can live with both = texts since they allow me to do the same thing.=20 It allows my low level application to add a digital signature supported=20 by the digital signature bit, where the intention of that application is = to add integrity and origin authentication, while the use of the=20 signature in practice (higher layers) ends up being used as evidence of=20 some kind of commitment.=20 Example. An e-mail application adds an arbitrary signature supported by=20 the DS bit, while the body of the text reads "Through the digital=20 signature on this e-mail I commit to....). This is now a perfectly valid = scenario according to both texts.=20 The real defect that was fixed was that the digital signature bit said=20 that it was for purposes "other" than NR. That is now gone in both=20 standards.=20 I agree to Stephen's rationale to keep the name nonRepudiation. It is=20 not worth the cost to change the name. Stephen's point here was missing=20 in the X.509 discussions of a name change.=20 Stefan Santesson=20 Program Manager, Standards Liaison=20 Windows Security=20 =20 > -----Original Message-----=20 > From: owner-ietf-pkix@mail.imc.org=20 [mailto:owner-ietf-pkix@mail.imc.org]=20 > On Behalf Of Denis Pinkas=20 > Sent: den 27 maj 2005 12:29=20 > To: Stephen Farrell=20 > Cc: Hoyt L Kesterson II; pkix=20 > Subject: Re: 3280bis: key usage (13)=20 >=20 >=20 > Stephen,=20 >=20 > I agree with everything Hoyt said on bit 1.=20 >=20 > However, there are two sides for this coin : bit 0 and bit 1.=20 >=20 > Both are again copied below:=20 >=20 > ISO Corrigendum:=20 >=20 > a) digitalSignature: for verifying digital signatures that are=20 used=20 > with an entity authentication service, a data origin=20 > authentication=20 > service or/and an integrity service;=20 >=20 > 3280bis:=20 >=20 > The digitalSignature bit is asserted when the subject public key=20 > is used with a digital signature mechanism to support security=20 > services other than certificate signing (bit 5), or CRL signing=20 > (bit 6). Digital signature mechanisms are often used for entity=20 > authentication and data origin authentication with integrity.=20 >=20 > The current text of 3280bis for bit 0 (ds) is incompatible with the=20 ISO=20 > Corrigendum.=20 >=20 > As Hoyt already said, any new text should align with the definition in = the=20 > approved technical corrigenda against the 4th edition and in the=20 upcoming=20 > 5th edition.=20 >=20 > Denis=20 >=20 > > Hi Hoyt,=20 > >=20 > > Hoyt L Kesterson II wrote:=20 > >=20 > >> Stephen=20 > >>=20 > >> I am somewhat dismayed at your reaction to the new text in X.509.=20 > >=20 > >=20 > > I'm sorry about that, but I guess I'm just fed up with the=20 > > NR bit, though I can understand how people who've worked=20 > > hard to try fix it might be dismayed.=20 > >=20 > > (BTW: I once suggested that CAs MUST set this bit randomly=20 > > since that was the only way I could see to kill it off=20 > > properly. If you can get that into X.509 then I'd be happy=20 > > for 3280bis to align:-)=20 > >=20 > > > I am not going to argue with you here (maybe in a bar the next=20 time=20 > > > we run into each other).=20 > >=20 > > Good idea!=20 > >=20 > >> However, I do want to mention several points.=20 > >>=20 > >> 1) I initiated the change in text because of the various=20 > interpretations=20 > >=20 > > > by implementors that were resulting in non-interoperable=20 > > > implementations. It was a conversation with a PKIXer at a RSA=20 > > > conference a few years ago that caused me to articulate a private = > > > concern.=20 > >=20 > > I agree that everything connected with this bit has been=20 > > confused and remains so.=20 > >=20 > >> 2) The legal community was very confused. There was even a=20 > >=20 > > > paper castigating the standard developers for mandating that=20 > > > one could not repudiate an action.=20 > >=20 > > Maybe the mistake was defining a bit that laywers care about?=20 > >=20 > >> 3) There were several meetings held where there was significant=20 > >=20 > > > participation by people in the IETF PKIX group (as well as=20 > > > lawyers). All agreed there was a problem with the published text. = > > > Denis and I argued long and hard over wording but we didn't=20 > > > disagree on the need for new text and its general intent.=20 > >=20 > > Fair enough.=20 > >=20 > >> 4) Russ was concerned that change would cause a problem=20 > >=20 > > > with existing IETF standards and was not too happy with a=20 > > > change to the name of the bit. That's why I put the line=20 > > > in that you referenced. However, that was to grandfather=20 > > > existing text, not to allow new text to continue using=20 > > > the old term and definitions.=20 > >=20 > > Ok. Here's the real reason not to change: Many people use=20 > > ASN.1 compilers which means that names from the ASN.1=20 > > module end up being directly used in higher layer code.=20 > > Changing the name causes that code not to compile. I'd=20 > > say that there's quite a lot of 3280 code in the world=20 > > at this stage. So, if the semantics isn't supposed to=20 > > have changed (and I assume that is meant to be the=20 > > case) then this cost just doesn't seem worthwhile.=20 > >=20 > >> 5) It is the definition that is important. I recommend=20 > >=20 > > > that any new text align with the definition in the approved=20 > > > technical corrigenda against the 4th edition and in=20 > > > the upcoming 5th edition.=20 > >=20 > > While I'd rather not see any more text added on this,=20 > > (there's been way too much already) I wouldn't have a big=20 > > issue with trying to help a reader make sense of the=20 > > fact that 3280bis and x.509 name this bit differently.=20 > >=20 > > However text like the sentence below is IMO almost=20 > > certain to cause even more confusion:=20 > >=20 > > The precise type of commitment of the signer e.g. "reviewed=20 > > and approved" or "with the intent to be bound", may be=20 > > signalled by the content being signed, e.g. the signed=20 > > document itself or some additional signed information.=20 > >=20 > > That sounds like the sole purpose of the CC-bit is as=20 > > a flag to indicate when some other bits somewhere else=20 > > tell you what the CC-bit means.=20 > >=20 > > So in the absence of some better text I think that 3280bis=20 > > is better off just saying "NR a.k.a. CC" as it currently=20 > > does.=20 > >=20 > > Regards,=20 > > Stephen.=20 > >=20 > >>=20 > >> At 14:49 +0100 5/26/05, Stephen Farrell wrote:=20 > >>=20 > >>> Denis,=20 > >>>=20 > >>>=20 > >>>> Please align with the the ISO-ITU text.=20 > >>>=20 > >>>=20 > >>> Do you mean we should rename the bits and include the=20 > >>> other new x.509 text? The design team were against=20 > >>> doing that.=20 > >>>=20 > >>> Is there any (good) reason other than alignment to=20 > >>> make such a change?=20 > >>>=20 > >>> Personally, I find the new x.509 text worse, although=20 > >>> it does say: "Note that it is not incorrect to refer to=20 > >>> this keyUsage bit using the identifier nonRepudiation."=20 > >>> So I can argue that we are aligned, just not identical.=20 > >>>=20 > >>> But of course, I'm from the non-repudiation is non-sense=20 > >>> camp so I may not be the best judge.=20 > >>>=20 > >>> Stephen.=20 > >>>=20 > >>> PS: A quibble:=20 > >>>=20 > >>>=20 > >>>> The new text in X.509 aligns with the text in RFC 3280. No=20 changes=20 > >>>> are required to 3280bis. A comment has been added to the ASN.1=20 for=20 > >>>> KeyUsage stating that "recent editions of X.509 have renamed=20 > >>>> [the nonRepudiation] bit to contentCommitment"=20 > >>>>=20 > >>>> This statement is untrue.=20 > >>>=20 > >>>=20 > >>> The paragraph to which I assume you refer contains 3=20 > >>> statements - it'd be easier to close these threads if=20 > >>> you were more precise. (I think I got what you want=20 > >>> by the end of the mail though...)=20 > >>>=20 > >>> PPS: "This statement is untrue."=20 > >>> Are you from Crete after all? :-)=20 > >>>=20 > >>>=20 > >>>=20 > >>>=20 > >>> Denis Pinkas wrote:=20 > >>>=20 > >>>=20 > >>>> To the list,=20 > >>>>=20 > >>>> The disposition of comments states:=20 > >>>>=20 > >>>> 13) The descriptions of the meanings of the digitalSignature and=20 > >>>> nonRepudiation bits of keyUsage may need to be adjusted based=20 > >>>> on the work in X.509=20 > >>>>=20 > >>>> The new text in X.509 aligns with the text in RFC 3280. No=20 changes=20 > >>>> are required to 3280bis. A comment has been added to the ASN.1=20 for=20 > >>>> KeyUsage stating that "recent editions of X.509 have renamed=20 > >>>> [the nonRepudiation] bit to contentCommitment"=20 > >>>>=20 > >>>> This statement is untrue.=20 > >>>>=20 > >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) = > >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called=20 > >>>>=20 > >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).=20 > >>>>=20 > >>>> An extract from this text is copied below:=20 > >>>>=20 > >>>> a) digitalSignature: for verifying digital signatures that are=20 used=20 > >>>> with an entity authentication service, a data origin=20 authentication=20 > >>>> service or/and an integrity service;=20 > >>>>=20 > >>>> b) contentCommitment: for verifying digital signatures which are=20 > >>>> intended=20 > >>>> to signal that the signer is committing to the content being=20 signed.=20 > >>>> The type of commitment the certificate can be used to support=20 may be=20 > >>>> further constrained by the CA, e.g. through a certificate=20 policy.=20 > >>>> The precise type of commitment of the signer e.g. "reviewed and=20 > >>>> approved" or "with the intent to be bound", may be signalled by=20 the=20 > >>>> content being signed, e.g. the signed document itself or some=20 > >>>> additional=20 > >>>> signed information.=20 > >>>>=20 > >>>> Since a content commitment signing is considered to be a=20 digitally=20 > >>>> signed=20 > >>>> transaction, the digitalSignature bit need not be set in the=20 > >>>> certificate.=20 > >>>> If it is set, it does not affect the level of commitment the=20 signer=20 > >>>> has=20 > >>>> endowed in the signed content.=20 > >>>>=20 > >>>> Note that it is not incorrect to refer to this keyUsage bit=20 using=20 > the=20 > >>>> identifier nonRepudiation. However, the use of this identifier=20 has=20 > >>>> been=20 > >>>> deprecated. Regardless of the identifier used, the semantics of=20 > >>>> this bit=20 > >>>> are as specified in this Directory Specification.=20 > >>>>=20 > >>>> The text from 3280 is copied below:=20 > >>>>=20 > >>>> The digitalSignature bit is asserted when the subject public=20 key=20 > >>>> is used with a digital signature mechanism to support=20 security=20 > >>>> services other than certificate signing (bit 5), or CRL=20 signing=20 > >>>> (bit 6). Digital signature mechanisms are often used for=20 entity=20 > >>>> authentication and data origin authentication with integrity. = > >>>>=20 > >>>> The nonRepudiation bit is asserted when the subject public=20 key is=20 > >>>> used to verify digital signatures used to provide a non-=20 > >>>> repudiation service which protects against the signing entity = > >>>> falsely denying some action, excluding certificate or CRL=20 > signing.=20 > >>>> In the case of later conflict, a reliable third party may=20 > >>>> determine the authenticity of the signed data.=20 > >>>>=20 > >>>> Further distinctions between the digitalSignature and=20 > >>>> nonRepudiation bits may be provided in specific certificate=20 > >>>> policies.=20 > >>>>=20 > >>>> The text from 3280bis does not align with the ISO-ITU text.=20 > >>>> Please align with the the ISO-ITU text.=20 > >>>>=20 > >>>> Denis=20 > >>>=20 > >>=20 > >>=20 > >>=20 > >=20 > >=20 >=20 Joel S. Kazin CPA, CISA, CISSP, CISM Senior Consultant Atos Origin 40 Old Sleepy Hollow Road Pleasantville, New York 10570-3802 USA Phone +1 914-769-8780 Mobile +1 914-564-1484 email joel.kazin@atosorigin.com www.atosorigin.com =20 ------=_NextPart_000_0031_01C562A8.F9290510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
X.509 V1 or V2 did not have any = extensions.  Thus,=20 neither key usage nor certificate policies were part of v1 or v2.  = These=20 extensions came about in v3.
-----Original Message-----
From:=20 owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] = On=20 Behalf Of Kazin, Joel
Sent: Friday, May 27, 2005 9:20=20 AM
To: Stefan Santesson; Denis Pinkas; Stephen = Farrell
Cc:=20 Hoyt L Kesterson II; pkix
Subject: RE: 3280bis: key usage=20 (13)

The core problem is labeling the bit=20 non-repudiation.  It goes against the legal idea that you can = attempt to=20 repudiate your alleged actions even when your defense is weaker than = "the cat=20 ate my homework".  To me, non-repudiation is more of a marketing=20 description than a technical, contractual, or legal description of = what the=20 signer intended to do. 

A secondary problem is that the=20 non-repudiation bit doesn't tell a relying party or third party = enough. =20 The logical place to look for such information is in the=20 id-ce-certificatePolicies extension.  Was the = id-ce-certificatePolicies=20 extension part of the original x.509 v1 specification?  If that = is true,=20 then perhaps the non-repudiation bit is just a holdover from the = original=20 x.509 v1 certificate definition?  If my arguments are true then = we can:=20 1) keep calling it non-repudiation and strongly deprecate its use, 2) = change=20 the name and deprecate its use, 3) change the name and allow its use. = I favor=20 1 over 2 over 3. 


At 07:06 AM 5/27/2005 -0500, Stefan = Santesson wrote:

Speaking as=20 implementer and not design team member, I can live with both=20
texts since they allow me to do the same = thing.=20

It allows my low level application to add a = digital=20 signature supported
by the digital = signature bit,=20 where the intention of that application is
to add=20 integrity and origin authentication, while the use of the =
signature in practice (higher layers) ends up being used as = evidence=20 of
some kind of commitment. =

Example. An e-mail application adds an arbitrary signature = supported=20 by
the DS bit, while the body of the text = reads=20 "Through the digital
signature on this = e-mail I=20 commit to....). This is now a perfectly valid
scenario according to both texts.

The=20 real defect that was fixed was that the digital signature bit = said=20
that it was for purposes "other" than NR. That is = now gone=20 in both
standards.

I=20 agree to Stephen's rationale to keep the name nonRepudiation. It = is=20
not worth the cost to change the name. Stephen's = point here=20 was missing
in the X.509 discussions of a = name=20 change.

Stefan Santesson =
Program Manager, Standards Liaison
Windows=20 Security
 

>=20 -----Original Message-----
> From:=20 owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.= imc.org]=20
> On Behalf Of Denis Pinkas
>=20 Sent: den 27 maj 2005 12:29
> To: = Stephen=20 Farrell
> Cc: Hoyt L Kesterson II; = pkix=20
> Subject: Re: 3280bis: key usage (13) =
>
>
>=20 Stephen,
>
> I agree=20 with everything Hoyt said on bit 1.
>=20
> However, there are two sides for this = coin :=20 bit 0 and bit 1.
>
>=20 Both are again copied below:
> =
> ISO Corrigendum:
> =
>      a) digitalSignature: for = verifying=20 digital signatures that are
used =
>         with = an entity=20 authentication service, a data origin
> = authentication
>         = service or/and=20 an integrity service;
> =
> 3280bis:
> =
>      The digitalSignature bit = is=20 asserted when the subject public key
>      is used with a digital = signature=20 mechanism to support security
>      services other than = certificate=20 signing (bit 5), or CRL signing
>      (bit 6).  Digital = signature=20 mechanisms are often used for entity
>      authentication and data = origin=20 authentication with integrity.
> =
> The current text of 3280bis for bit 0 (ds) is = incompatible with=20 the
ISO
>=20 Corrigendum.
>
> As=20 Hoyt already said, any new text should align with the definition = in=20
the
> approved = technical=20 corrigenda against the 4th edition and in the
upcoming
> 5th edition. =
>
> Denis
>=20
> > Hi Hoyt,
>=20 >
> > Hoyt L Kesterson II = wrote:=20
> >
> >> = Stephen
> >>
>=20 >> I am somewhat dismayed at your reaction to the new text in=20 X.509.
> >
>=20 >
> > I'm sorry about that, but I = guess I'm=20 just fed up with the
> > NR bit, = though I can=20 understand how people who've worked
> = > hard=20 to try fix it might be dismayed.
> = >=20
> > (BTW: I once suggested that CAs MUST = set this bit=20 randomly
> > since that was the only = way I=20 could see to kill it off
> > = properly. If you=20 can get that into X.509 then I'd be happy
> >=20 for 3280bis to align:-)
> > =
> >  > I am not going to argue with you here = (maybe in=20 a bar the next
time
>=20 >  > we run into each other).
>=20 >
> > Good idea!
> >
> >> However, = I do want to=20 mention several points.
> = >>=20
> >> 1) I initiated the change in text = because of=20 the various
> interpretations =
> >
> >  > by = implementors that were resulting in non-interoperable =
> >  > implementations. It was a conversation = with a=20 PKIXer at a RSA
> >  > = conference a=20 few years ago that caused me to articulate a private =
> >  > concern.
>=20 >
> > I agree that everything = connected=20 with this bit has been
> > confused = and=20 remains so.
> >
>=20 >> 2) The legal community was very confused. There was even = a=20
> >
> = >  >=20 paper castigating the standard developers for mandating that=20
> >  > one could not repudiate an=20 action.
> >
> >=20 Maybe the mistake was defining a bit that laywers care about? =
> >
> >> = 3) There=20 were several meetings held where there was significant =
> >
> >  > = participation=20 by people in the IETF PKIX group (as well as
>=20 >  > lawyers). All agreed there was a problem with the = published=20 text.
> >  > Denis and I = argued long=20 and hard over wording but we didn't
> = > =20 > disagree on the need for new text and its general = intent.=20
> >
> > = Fair=20 enough.
> >
>=20 >> 4) Russ was concerned that change would cause a = problem=20
> >
> = >  > with=20 existing IETF standards and was not too happy with a =
> >  > change to the name of the bit. That's = why I put=20 the line
> >  > in that you=20 referenced. However, that was to grandfather
>=20 >  > existing text, not to allow new text to continue=20 using
> >  > the old term = and=20 definitions.
> >
>=20 > Ok. Here's the real reason not to change: Many people = use=20
> > ASN.1 compilers which means that names = from the=20 ASN.1
> > module end up being = directly used in=20 higher layer code.
> > Changing the = name=20 causes that code not to compile. I'd
> = > say=20 that there's quite a lot of 3280 code in the world
> > at this stage. So, if the semantics isn't = supposed=20 to
> > have changed (and I assume = that is=20 meant to be the
> > case) then this = cost just=20 doesn't seem worthwhile.
> > =
> >> 5) It is the definition that is important. I=20 recommend
> >
>=20 >  > that any new text align with the definition in the=20 approved
> >  > technical = corrigenda=20 against the 4th edition and in
> = >  >=20 the upcoming 5th edition.
> > =
> > While I'd rather not see any more text added on=20 this,
> > (there's been way too much = already)=20 I wouldn't have a big
> > issue with = trying to=20 help a reader make sense of the
> > = fact that=20 3280bis and x.509 name this bit differently.
>=20 >
> > However text like the = sentence below=20 is IMO almost
> > certain to cause = even more=20 confusion:
> >
>=20 >   The precise type of commitment of the signer e.g.=20 "reviewed
> >   and = approved" or=20 "with the intent to be bound", may be
> = >   signalled by the content being signed, e.g. the=20 signed
> >   document = itself or some=20 additional signed information.
> = >=20
> > That sounds like the sole purpose of = the CC-bit=20 is as
> > a flag to indicate when = some other=20 bits somewhere else
> > tell you = what the=20 CC-bit means.
> >
>=20 > So in the absence of some better text I think that = 3280bis=20
> > is better off just saying "NR a.k.a. = CC" as it=20 currently
> > does.
> >
> > = Regards,
> > Stephen.
> = >
> >>
> >> At = 14:49 +0100=20 5/26/05, Stephen Farrell wrote:
> = >>=20
> >>> Denis,
>=20 >>>
> >>> =
> >>>> Please align with the the ISO-ITU = text.=20
> >>>
>=20 >>>
> >>> Do you mean = we should=20 rename the bits and include the
> = >>>=20 other new x.509 text? The design team were against
> >>> doing that.
>=20 >>>
> >>> Is there = any (good)=20 reason other than alignment to
> = >>>=20 make such a change?
> = >>>=20
> >>> Personally, I find the new = x.509 text=20 worse, although
> >>> it does = say: "Note=20 that it is not incorrect to refer to
>=20 >>> this keyUsage bit using the identifier = nonRepudiation."=20
> >>> So I can argue that we are = aligned, just=20 not identical.
> >>> =
> >>> But of course, I'm from the = non-repudiation is=20 non-sense
> >>> camp so I may = not be the=20 best judge.
> >>> =
> >>> Stephen.
>=20 >>>
> >>> PS: A = quibble:=20
> >>>
>=20 >>>
> >>>>  = The new=20 text in X.509 aligns with the text in RFC 3280.  No =
changes
> = >>>>  are=20 required to 3280bis.  A comment has been added to the = ASN.1=20
for
> = >>>> =20 KeyUsage stating that "recent editions of X.509 have renamed=20
> >>>>  [the nonRepudiation] = bit to=20 contentCommitment"
> = >>>>=20
> >>>> This statement is = untrue.=20
> >>>
>=20 >>>
> >>> The = paragraph to=20 which I assume you refer contains 3
>=20 >>> statements - it'd be easier to close these threads = if=20
> >>> you were more precise. (I think = I got=20 what you want
> >>> by the end = of the=20 mail though...)
> >>> =
> >>> PPS: "This statement is untrue." =
> >>>    Are you from Crete = after all?=20 :-)
> >>>
>=20 >>>
> >>> =
> >>>
> = >>> Denis=20 Pinkas wrote:
> >>> =
> >>>
> = >>>> To=20 the list,
> >>>> =
> >>>> The disposition of comments = states:=20
> >>>>
>=20 >>>> 13) The descriptions of the meanings of the=20 digitalSignature and
>=20 >>>>    nonRepudiation bits of keyUsage = may need=20 to be adjusted based
>=20 >>>>    on the work in X.509 =
> >>>>
> = >>>>=20 The new text in X.509 aligns with the text in RFC 3280.  = No=20
changes
> = >>>> are=20 required to 3280bis.  A comment has been added to the = ASN.1=20
for
> = >>>> KeyUsage=20 stating that "recent editions of X.509 have renamed
> >>>> [the nonRepudiation] bit to=20 contentCommitment"
> = >>>>=20
> >>>> This statement is = untrue.=20
> >>>>
>=20 >>>> The text from X.509 has been published in = Corrigendum 3=20 (04/2004)
> >>>> on pages 4 = and 5=20 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
>=20 >>>>
> >>>> = ITU-T Rec.=20 X.509 (2000)/Cor.3 (04/2004)).
>=20 >>>>
> >>>> An = extract=20 from this text is copied below:
>=20 >>>>
> >>>> a)=20 digitalSignature: for verifying digital signatures that are =
used
> >>>>  = with an=20 entity authentication service, a data origin
authentication
> = >>>> =20 service or/and an integrity service;
>=20 >>>>
> >>>> b)=20 contentCommitment: for verifying digital signatures which are =
> >>>> intended
>=20 >>>>  to signal that the signer is committing to = the=20 content being
signed.
>=20 >>>>  The type of commitment the certificate can be = used to=20 support
may be
>=20 >>>>  further constrained by the CA, e.g. through a = certificate
policy.
>=20 >>>>  The precise type of commitment of the signer = e.g.=20 "reviewed and
> >>>>  = approved"=20 or "with the intent to be bound", may be signalled by =
the
> >>>>  = content being=20 signed, e.g. the signed document itself or some
>=20 >>>> additional
>=20 >>>>  signed information.
>=20 >>>>
> = >>>>  Since a=20 content commitment signing is considered to be a
digitally
> >>>> = signed=20
> >>>>  transaction, the=20 digitalSignature bit need not be set in the
>=20 >>>> certificate.
>=20 >>>>  If it is set, it does not affect the level of = commitment the
signer
>=20 >>>> has
> = >>>> =20 endowed in the signed content.
>=20 >>>>
> = >>>>  Note=20 that it is not incorrect to refer to this keyUsage bit =
using
> the
>=20 >>>>  identifier nonRepudiation. However, the use = of this=20 identifier
has
>=20 >>>> been
> = >>>> =20 deprecated. Regardless of the identifier used, the semantics = of=20
> >>>> this bit
>=20 >>>>  are as specified in this Directory=20 Specification.
> = >>>>=20
> >>>> The text from 3280 is = copied=20 below:
> >>>> =
> >>>>     The = digitalSignature=20 bit is asserted when the subject public
key=20
> >>>>     is = used with=20 a digital signature mechanism to support
security
>=20 >>>>     services other than = certificate=20 signing (bit 5), or CRL
signing =
> >>>>     (bit = 6).  Digital=20 signature mechanisms are often used for
entity
>=20 >>>>     authentication and data = origin=20 authentication with integrity.
>=20 >>>>
>=20 >>>>     The nonRepudiation bit is = asserted=20 when the subject public
key is =
> >>>>     used to = verify digital=20 signatures used to provide a non-
>=20 >>>>     repudiation service which = protects=20 against the signing entity
>=20 >>>>     falsely denying some = action,=20 excluding certificate or CRL
> = signing.=20
> >>>>     In = the case=20 of later conflict, a reliable third party may
>=20 >>>>     determine the authenticity = of the=20 signed data.
> >>>> =
> >>>>     Further = distinctions=20 between the digitalSignature and
>=20 >>>>     nonRepudiation bits may be = provided=20 in specific certificate
>=20 >>>>     policies.
> >>>>
> = >>>>=20 The text from 3280bis does not align with the ISO-ITU text. =
> >>>> Please align with the the ISO-ITU = text.=20
> >>>>
>=20 >>>> Denis
> = >>>=20
> >>
> = >>=20
> >>
> = >=20
> >
>=20


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior=20 Consultant
Atos Origin
40 Old Sleepy Hollow = Road
Pleasantville, New=20 York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  = +1=20 914-564-1484
email   =20 joel.kazin@atosorigin.com
www.atosorigin.com

------=_NextPart_000_0031_01C562A8.F9290510-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDpa9E068685; Fri, 27 May 2005 06:51:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RDpasL068684; Fri, 27 May 2005 06:51:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDpLI7068668 for ; Fri, 27 May 2005 06:51:35 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4RDpAra002230; Fri, 27 May 2005 09:51:11 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4RDoS6u021243; Fri, 27 May 2005 09:50:28 -0400 (EDT) Message-ID: <429725BB.4000105@nist.gov> Date: Fri, 27 May 2005 09:50:51 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas CC: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> <4296F66E.3020406@bull.net> <42971110.5040008@cs.tcd.ie> <429712E8.7050708@bull.net> In-Reply-To: <429712E8.7050708@bull.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, I do not agree with your proposal for the digitalSignature bit. Here is the current text: The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. This text merely states that setting the digitalSignature bit, by itself, does not authorize relying parties to use the subject public key to verify signatures on certificates or CRLs. It does not prevent a CA from setting digitalSignature, keyCertSign, and cRLSign in the same certificate. Imposing this restriction would, for example, prevent a CA from using its certificate signing key to also sign OCSP responses. Denis Pinkas wrote: > Stephen, > > Just before leaving my office in a few minutes for a few days, > here is a new text proposal for the DS bit: > > New proposal for 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service. However, it SHALL not be set > when certificate signing (bit 5) or CRL signing (bit 6) is set. > > Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDIx92066235; Fri, 27 May 2005 06:18:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RDIxJU066234; Fri, 27 May 2005 06:18:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDIweb066214 for ; Fri, 27 May 2005 06:18:58 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com) Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id C619E5FEE1; Fri, 27 May 2005 08:18:28 -0500 (CDT) Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id ; Fri, 27 May 2005 08:18:28 -0500 Message-ID: <5.1.0.14.0.20050527090001.00b128d0@172.16.146.192> From: "Kazin, Joel" To: Stefan Santesson , Denis Pinkas , Stephen Farrell Cc: Hoyt L Kesterson II , pkix Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 08:19:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C562BE.91D1CCE2" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C562BE.91D1CCE2 Content-Type: text/plain; charset="iso-8859-1" The core problem is labeling the bit non-repudiation. It goes against the legal idea that you can attempt to repudiate your alleged actions even when your defense is weaker than "the cat ate my homework". To me, non-repudiation is more of a marketing description than a technical, contractual, or legal description of what the signer intended to do. A secondary problem is that the non-repudiation bit doesn't tell a relying party or third party enough. The logical place to look for such information is in the id-ce-certificatePolicies extension. Was the id-ce-certificatePolicies extension part of the original x.509 v1 specification? If that is true, then perhaps the non-repudiation bit is just a holdover from the original x.509 v1 certificate definition? If my arguments are true then we can: 1) keep calling it non-repudiation and strongly deprecate its use, 2) change the name and deprecate its use, 3) change the name and allow its use. I favor 1 over 2 over 3. At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote: Speaking as implementer and not design team member, I can live with both texts since they allow me to do the same thing. It allows my low level application to add a digital signature supported by the digital signature bit, where the intention of that application is to add integrity and origin authentication, while the use of the signature in practice (higher layers) ends up being used as evidence of some kind of commitment. Example. An e-mail application adds an arbitrary signature supported by the DS bit, while the body of the text reads "Through the digital signature on this e-mail I commit to....). This is now a perfectly valid scenario according to both texts. The real defect that was fixed was that the digital signature bit said that it was for purposes "other" than NR. That is now gone in both standards. I agree to Stephen's rationale to keep the name nonRepudiation. It is not worth the cost to change the name. Stephen's point here was missing in the X.509 discussions of a name change. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org ] > On Behalf Of Denis Pinkas > Sent: den 27 maj 2005 12:29 > To: Stephen Farrell > Cc: Hoyt L Kesterson II; pkix > Subject: Re: 3280bis: key usage (13) > > > Stephen, > > I agree with everything Hoyt said on bit 1. > > However, there are two sides for this coin : bit 0 and bit 1. > > Both are again copied below: > > ISO Corrigendum: > > a) digitalSignature: for verifying digital signatures that are used > with an entity authentication service, a data origin > authentication > service or/and an integrity service; > > 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > The current text of 3280bis for bit 0 (ds) is incompatible with the ISO > Corrigendum. > > As Hoyt already said, any new text should align with the definition in the > approved technical corrigenda against the 4th edition and in the upcoming > 5th edition. > > Denis > > > Hi Hoyt, > > > > Hoyt L Kesterson II wrote: > > > >> Stephen > >> > >> I am somewhat dismayed at your reaction to the new text in X.509. > > > > > > I'm sorry about that, but I guess I'm just fed up with the > > NR bit, though I can understand how people who've worked > > hard to try fix it might be dismayed. > > > > (BTW: I once suggested that CAs MUST set this bit randomly > > since that was the only way I could see to kill it off > > properly. If you can get that into X.509 then I'd be happy > > for 3280bis to align:-) > > > > > I am not going to argue with you here (maybe in a bar the next time > > > we run into each other). > > > > Good idea! > > > >> However, I do want to mention several points. > >> > >> 1) I initiated the change in text because of the various > interpretations > > > > > by implementors that were resulting in non-interoperable > > > implementations. It was a conversation with a PKIXer at a RSA > > > conference a few years ago that caused me to articulate a private > > > concern. > > > > I agree that everything connected with this bit has been > > confused and remains so. > > > >> 2) The legal community was very confused. There was even a > > > > > paper castigating the standard developers for mandating that > > > one could not repudiate an action. > > > > Maybe the mistake was defining a bit that laywers care about? > > > >> 3) There were several meetings held where there was significant > > > > > participation by people in the IETF PKIX group (as well as > > > lawyers). All agreed there was a problem with the published text. > > > Denis and I argued long and hard over wording but we didn't > > > disagree on the need for new text and its general intent. > > > > Fair enough. > > > >> 4) Russ was concerned that change would cause a problem > > > > > with existing IETF standards and was not too happy with a > > > change to the name of the bit. That's why I put the line > > > in that you referenced. However, that was to grandfather > > > existing text, not to allow new text to continue using > > > the old term and definitions. > > > > Ok. Here's the real reason not to change: Many people use > > ASN.1 compilers which means that names from the ASN.1 > > module end up being directly used in higher layer code. > > Changing the name causes that code not to compile. I'd > > say that there's quite a lot of 3280 code in the world > > at this stage. So, if the semantics isn't supposed to > > have changed (and I assume that is meant to be the > > case) then this cost just doesn't seem worthwhile. > > > >> 5) It is the definition that is important. I recommend > > > > > that any new text align with the definition in the approved > > > technical corrigenda against the 4th edition and in > > > the upcoming 5th edition. > > > > While I'd rather not see any more text added on this, > > (there's been way too much already) I wouldn't have a big > > issue with trying to help a reader make sense of the > > fact that 3280bis and x.509 name this bit differently. > > > > However text like the sentence below is IMO almost > > certain to cause even more confusion: > > > > The precise type of commitment of the signer e.g. "reviewed > > and approved" or "with the intent to be bound", may be > > signalled by the content being signed, e.g. the signed > > document itself or some additional signed information. > > > > That sounds like the sole purpose of the CC-bit is as > > a flag to indicate when some other bits somewhere else > > tell you what the CC-bit means. > > > > So in the absence of some better text I think that 3280bis > > is better off just saying "NR a.k.a. CC" as it currently > > does. > > > > Regards, > > Stephen. > > > >> > >> At 14:49 +0100 5/26/05, Stephen Farrell wrote: > >> > >>> Denis, > >>> > >>> > >>>> Please align with the the ISO-ITU text. > >>> > >>> > >>> Do you mean we should rename the bits and include the > >>> other new x.509 text? The design team were against > >>> doing that. > >>> > >>> Is there any (good) reason other than alignment to > >>> make such a change? > >>> > >>> Personally, I find the new x.509 text worse, although > >>> it does say: "Note that it is not incorrect to refer to > >>> this keyUsage bit using the identifier nonRepudiation." > >>> So I can argue that we are aligned, just not identical. > >>> > >>> But of course, I'm from the non-repudiation is non-sense > >>> camp so I may not be the best judge. > >>> > >>> Stephen. > >>> > >>> PS: A quibble: > >>> > >>> > >>>> The new text in X.509 aligns with the text in RFC 3280. No changes > >>>> are required to 3280bis. A comment has been added to the ASN.1 for > >>>> KeyUsage stating that "recent editions of X.509 have renamed > >>>> [the nonRepudiation] bit to contentCommitment" > >>>> > >>>> This statement is untrue. > >>> > >>> > >>> The paragraph to which I assume you refer contains 3 > >>> statements - it'd be easier to close these threads if > >>> you were more precise. (I think I got what you want > >>> by the end of the mail though...) > >>> > >>> PPS: "This statement is untrue." > >>> Are you from Crete after all? :-) > >>> > >>> > >>> > >>> > >>> Denis Pinkas wrote: > >>> > >>> > >>>> To the list, > >>>> > >>>> The disposition of comments states: > >>>> > >>>> 13) The descriptions of the meanings of the digitalSignature and > >>>> nonRepudiation bits of keyUsage may need to be adjusted based > >>>> on the work in X.509 > >>>> > >>>> The new text in X.509 aligns with the text in RFC 3280. No changes > >>>> are required to 3280bis. A comment has been added to the ASN.1 for > >>>> KeyUsage stating that "recent editions of X.509 have renamed > >>>> [the nonRepudiation] bit to contentCommitment" > >>>> > >>>> This statement is untrue. > >>>> > >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) > >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called > >>>> > >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). > >>>> > >>>> An extract from this text is copied below: > >>>> > >>>> a) digitalSignature: for verifying digital signatures that are used > >>>> with an entity authentication service, a data origin authentication > >>>> service or/and an integrity service; > >>>> > >>>> b) contentCommitment: for verifying digital signatures which are > >>>> intended > >>>> to signal that the signer is committing to the content being signed. > >>>> The type of commitment the certificate can be used to support may be > >>>> further constrained by the CA, e.g. through a certificate policy. > >>>> The precise type of commitment of the signer e.g. "reviewed and > >>>> approved" or "with the intent to be bound", may be signalled by the > >>>> content being signed, e.g. the signed document itself or some > >>>> additional > >>>> signed information. > >>>> > >>>> Since a content commitment signing is considered to be a digitally > >>>> signed > >>>> transaction, the digitalSignature bit need not be set in the > >>>> certificate. > >>>> If it is set, it does not affect the level of commitment the signer > >>>> has > >>>> endowed in the signed content. > >>>> > >>>> Note that it is not incorrect to refer to this keyUsage bit using > the > >>>> identifier nonRepudiation. However, the use of this identifier has > >>>> been > >>>> deprecated. Regardless of the identifier used, the semantics of > >>>> this bit > >>>> are as specified in this Directory Specification. > >>>> > >>>> The text from 3280 is copied below: > >>>> > >>>> The digitalSignature bit is asserted when the subject public key > >>>> is used with a digital signature mechanism to support security > >>>> services other than certificate signing (bit 5), or CRL signing > >>>> (bit 6). Digital signature mechanisms are often used for entity > >>>> authentication and data origin authentication with integrity. > >>>> > >>>> The nonRepudiation bit is asserted when the subject public key is > >>>> used to verify digital signatures used to provide a non- > >>>> repudiation service which protects against the signing entity > >>>> falsely denying some action, excluding certificate or CRL > signing. > >>>> In the case of later conflict, a reliable third party may > >>>> determine the authenticity of the signed data. > >>>> > >>>> Further distinctions between the digitalSignature and > >>>> nonRepudiation bits may be provided in specific certificate > >>>> policies. > >>>> > >>>> The text from 3280bis does not align with the ISO-ITU text. > >>>> Please align with the the ISO-ITU text. > >>>> > >>>> Denis > >>> > >> > >> > >> > > > > > Joel S. Kazin CPA, CISA, CISSP, CISM Senior Consultant Atos Origin 40 Old Sleepy Hollow Road Pleasantville, New York 10570-3802 USA Phone +1 914-769-8780 Mobile +1 914-564-1484 email joel.kazin@atosorigin.com www.atosorigin.com ------_=_NextPart_001_01C562BE.91D1CCE2 Content-Type: text/html; charset="iso-8859-1" The core problem is labeling the bit non-repudiation.  It goes against the legal idea that you can attempt to repudiate your alleged actions even when your defense is weaker than "the cat ate my homework".  To me, non-repudiation is more of a marketing description than a technical, contractual, or legal description of what the signer intended to do. 

A secondary problem is that the non-repudiation bit doesn't tell a relying party or third party enough.  The logical place to look for such information is in the id-ce-certificatePolicies extension.  Was the id-ce-certificatePolicies extension part of the original x.509 v1 specification?  If that is true, then perhaps the non-repudiation bit is just a holdover from the original x.509 v1 certificate definition?  If my arguments are true then we can: 1) keep calling it non-repudiation and strongly deprecate its use, 2) change the name and deprecate its use, 3) change the name and allow its use. I favor 1 over 2 over 3. 


At 07:06 AM 5/27/2005 -0500, Stefan Santesson wrote:

Speaking as implementer and not design team member, I can live with both
texts since they allow me to do the same thing.

It allows my low level application to add a digital signature supported
by the digital signature bit, where the intention of that application is
to add integrity and origin authentication, while the use of the
signature in practice (higher layers) ends up being used as evidence of
some kind of commitment.

Example. An e-mail application adds an arbitrary signature supported by
the DS bit, while the body of the text reads "Through the digital
signature on this e-mail I commit to....). This is now a perfectly valid
scenario according to both texts.

The real defect that was fixed was that the digital signature bit said
that it was for purposes "other" than NR. That is now gone in both
standards.

I agree to Stephen's rationale to keep the name nonRepudiation. It is
not worth the cost to change the name. Stephen's point here was missing
in the X.509 discussions of a name change.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: owner-ietf-pkix@mail.imc.org
[mailto:owner-ietf-pkix@mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: den 27 maj 2005 12:29
> To: Stephen Farrell
> Cc: Hoyt L Kesterson II; pkix
> Subject: Re: 3280bis: key usage (13)
>
>
> Stephen,
>
> I agree with everything Hoyt said on bit 1.
>
> However, there are two sides for this coin : bit 0 and bit 1.
>
> Both are again copied below:
>
> ISO Corrigendum:
>
>      a) digitalSignature: for verifying digital signatures that are
used
>         with an entity authentication service, a data origin
> authentication
>         service or/and an integrity service;
>
> 3280bis:
>
>      The digitalSignature bit is asserted when the subject public key
>      is used with a digital signature mechanism to support security
>      services other than certificate signing (bit 5), or CRL signing
>      (bit 6).  Digital signature mechanisms are often used for entity
>      authentication and data origin authentication with integrity.
>
> The current text of 3280bis for bit 0 (ds) is incompatible with the
ISO
> Corrigendum.
>
> As Hoyt already said, any new text should align with the definition in
the
> approved technical corrigenda against the 4th edition and in the
upcoming
> 5th edition.
>
> Denis
>
> > Hi Hoyt,
> >
> > Hoyt L Kesterson II wrote:
> >
> >> Stephen
> >>
> >> I am somewhat dismayed at your reaction to the new text in X.509.
> >
> >
> > I'm sorry about that, but I guess I'm just fed up with the
> > NR bit, though I can understand how people who've worked
> > hard to try fix it might be dismayed.
> >
> > (BTW: I once suggested that CAs MUST set this bit randomly
> > since that was the only way I could see to kill it off
> > properly. If you can get that into X.509 then I'd be happy
> > for 3280bis to align:-)
> >
> >  > I am not going to argue with you here (maybe in a bar the next
time
> >  > we run into each other).
> >
> > Good idea!
> >
> >> However, I do want to mention several points.
> >>
> >> 1) I initiated the change in text because of the various
> interpretations
> >
> >  > by implementors that were resulting in non-interoperable
> >  > implementations. It was a conversation with a PKIXer at a RSA
> >  > conference a few years ago that caused me to articulate a private
> >  > concern.
> >
> > I agree that everything connected with this bit has been
> > confused and remains so.
> >
> >> 2) The legal community was very confused. There was even a
> >
> >  > paper castigating the standard developers for mandating that
> >  > one could not repudiate an action.
> >
> > Maybe the mistake was defining a bit that laywers care about?
> >
> >> 3) There were several meetings held where there was significant
> >
> >  > participation by people in the IETF PKIX group (as well as
> >  > lawyers). All agreed there was a problem with the published text.
> >  > Denis and I argued long and hard over wording but we didn't
> >  > disagree on the need for new text and its general intent.
> >
> > Fair enough.
> >
> >> 4) Russ was concerned that change would cause a problem
> >
> >  > with existing IETF standards and was not too happy with a
> >  > change to the name of the bit. That's why I put the line
> >  > in that you referenced. However, that was to grandfather
> >  > existing text, not to allow new text to continue using
> >  > the old term and definitions.
> >
> > Ok. Here's the real reason not to change: Many people use
> > ASN.1 compilers which means that names from the ASN.1
> > module end up being directly used in higher layer code.
> > Changing the name causes that code not to compile. I'd
> > say that there's quite a lot of 3280 code in the world
> > at this stage. So, if the semantics isn't supposed to
> > have changed (and I assume that is meant to be the
> > case) then this cost just doesn't seem worthwhile.
> >
> >> 5) It is the definition that is important. I recommend
> >
> >  > that any new text align with the definition in the approved
> >  > technical corrigenda against the 4th edition and in
> >  > the upcoming 5th edition.
> >
> > While I'd rather not see any more text added on this,
> > (there's been way too much already) I wouldn't have a big
> > issue with trying to help a reader make sense of the
> > fact that 3280bis and x.509 name this bit differently.
> >
> > However text like the sentence below is IMO almost
> > certain to cause even more confusion:
> >
> >   The precise type of commitment of the signer e.g. "reviewed
> >   and approved" or "with the intent to be bound", may be
> >   signalled by the content being signed, e.g. the signed
> >   document itself or some additional signed information.
> >
> > That sounds like the sole purpose of the CC-bit is as
> > a flag to indicate when some other bits somewhere else
> > tell you what the CC-bit means.
> >
> > So in the absence of some better text I think that 3280bis
> > is better off just saying "NR a.k.a. CC" as it currently
> > does.
> >
> > Regards,
> > Stephen.
> >
> >>
> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote:
> >>
> >>> Denis,
> >>>
> >>>
> >>>> Please align with the the ISO-ITU text.
> >>>
> >>>
> >>> Do you mean we should rename the bits and include the
> >>> other new x.509 text? The design team were against
> >>> doing that.
> >>>
> >>> Is there any (good) reason other than alignment to
> >>> make such a change?
> >>>
> >>> Personally, I find the new x.509 text worse, although
> >>> it does say: "Note that it is not incorrect to refer to
> >>> this keyUsage bit using the identifier nonRepudiation."
> >>> So I can argue that we are aligned, just not identical.
> >>>
> >>> But of course, I'm from the non-repudiation is non-sense
> >>> camp so I may not be the best judge.
> >>>
> >>> Stephen.
> >>>
> >>> PS: A quibble:
> >>>
> >>>
> >>>>  The new text in X.509 aligns with the text in RFC 3280.  No
changes
> >>>>  are required to 3280bis.  A comment has been added to the ASN.1
for
> >>>>  KeyUsage stating that "recent editions of X.509 have renamed
> >>>>  [the nonRepudiation] bit to contentCommitment"
> >>>>
> >>>> This statement is untrue.
> >>>
> >>>
> >>> The paragraph to which I assume you refer contains 3
> >>> statements - it'd be easier to close these threads if
> >>> you were more precise. (I think I got what you want
> >>> by the end of the mail though...)
> >>>
> >>> PPS: "This statement is untrue."
> >>>    Are you from Crete after all? :-)
> >>>
> >>>
> >>>
> >>>
> >>> Denis Pinkas wrote:
> >>>
> >>>
> >>>> To the list,
> >>>>
> >>>> The disposition of comments states:
> >>>>
> >>>> 13) The descriptions of the meanings of the digitalSignature and
> >>>>    nonRepudiation bits of keyUsage may need to be adjusted based
> >>>>    on the work in X.509
> >>>>
> >>>> The new text in X.509 aligns with the text in RFC 3280.  No
changes
> >>>> are required to 3280bis.  A comment has been added to the ASN.1
for
> >>>> KeyUsage stating that "recent editions of X.509 have renamed
> >>>> [the nonRepudiation] bit to contentCommitment"
> >>>>
> >>>> This statement is untrue.
> >>>>
> >>>> The text from X.509 has been published in Corrigendum 3 (04/2004)
> >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
> >>>>
> >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
> >>>>
> >>>> An extract from this text is copied below:
> >>>>
> >>>> a) digitalSignature: for verifying digital signatures that are
used
> >>>>  with an entity authentication service, a data origin
authentication
> >>>>  service or/and an integrity service;
> >>>>
> >>>> b) contentCommitment: for verifying digital signatures which are
> >>>> intended
> >>>>  to signal that the signer is committing to the content being
signed.
> >>>>  The type of commitment the certificate can be used to support
may be
> >>>>  further constrained by the CA, e.g. through a certificate
policy.
> >>>>  The precise type of commitment of the signer e.g. "reviewed and
> >>>>  approved" or "with the intent to be bound", may be signalled by
the
> >>>>  content being signed, e.g. the signed document itself or some
> >>>> additional
> >>>>  signed information.
> >>>>
> >>>>  Since a content commitment signing is considered to be a
digitally
> >>>> signed
> >>>>  transaction, the digitalSignature bit need not be set in the
> >>>> certificate.
> >>>>  If it is set, it does not affect the level of commitment the
signer
> >>>> has
> >>>>  endowed in the signed content.
> >>>>
> >>>>  Note that it is not incorrect to refer to this keyUsage bit
using
> the
> >>>>  identifier nonRepudiation. However, the use of this identifier
has
> >>>> been
> >>>>  deprecated. Regardless of the identifier used, the semantics of
> >>>> this bit
> >>>>  are as specified in this Directory Specification.
> >>>>
> >>>> The text from 3280 is copied below:
> >>>>
> >>>>     The digitalSignature bit is asserted when the subject public
key
> >>>>     is used with a digital signature mechanism to support
security
> >>>>     services other than certificate signing (bit 5), or CRL
signing
> >>>>     (bit 6).  Digital signature mechanisms are often used for
entity
> >>>>     authentication and data origin authentication with integrity.
> >>>>
> >>>>     The nonRepudiation bit is asserted when the subject public
key is
> >>>>     used to verify digital signatures used to provide a non-
> >>>>     repudiation service which protects against the signing entity
> >>>>     falsely denying some action, excluding certificate or CRL
> signing.
> >>>>     In the case of later conflict, a reliable third party may
> >>>>     determine the authenticity of the signed data.
> >>>>
> >>>>     Further distinctions between the digitalSignature and
> >>>>     nonRepudiation bits may be provided in specific certificate
> >>>>     policies.
> >>>>
> >>>> The text from 3280bis does not align with the ISO-ITU text.
> >>>> Please align with the the ISO-ITU text.
> >>>>
> >>>> Denis
> >>>
> >>
> >>
> >>
> >
> >
>


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    joel.kazin@atosorigin.com
www.atosorigin.com
 ------_=_NextPart_001_01C562BE.91D1CCE2-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDGhZY066075; Fri, 27 May 2005 06:16:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RDGhbH066074; Fri, 27 May 2005 06:16:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RDGgpa066068 for ; Fri, 27 May 2005 06:16:42 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 17FB734759; Sat, 28 May 2005 01:16:41 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14778-15; Sat, 28 May 2005 01:16:40 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id CA7743449E; Sat, 28 May 2005 01:16:34 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CD16737756; Sat, 28 May 2005 01:16:34 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Dbehf-00007Q-00; Sat, 28 May 2005 01:16:43 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, stephen.farrell@cs.tcd.ie Subject: Re: 3280bis: key usage (13) Cc: ietf-pkix@imc.org In-Reply-To: <429712E8.7050708@bull.net> Message-Id: Date: Sat, 28 May 2005 01:16:43 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas writes: >The digitalSignature bit is asserted when the subject public key is used for >verifying digital signatures that are used with an entity authentication >service, a data origin authentication service or/and an integrity service. Wouldn't it be better to say that it's used for purposes other than CC? By saying that DS can only be used for purposes A, B, and C, and CC for purpose D, what happens if someone wants to mark a key for purpose E? Since CC seems to be the more restrictive, it would be better to say that DS is to be used for everything else. If not, we'd need a third signature bit to cover the 'other' category that's explicitly excluded from DS and CC. >However, it SHALL not be set when certificate signing (bit 5) or CRL signing >(bit 6) is set. Why not? The intent of the original text was to say that digitalSignature doesn't mean you can use the cert for cert/CRL signing, now it says something completely different, that a cert-signing cert can never be used for any other purpose. This wording change would make a number of CAs non-compliant, since they do use their CA certs for other purposes (don't ask me why, I just see the things turn up from time to time). The wording should be something like "Setting this bit doesn't mean the cert can be used for cert or CRL signing; for that, you need to set the cert/CRL signing bits". (I realise this stuff should be obvious to anyone, but there are going to be CAs and vendors out there who defend their buggy software by interpreting the text as literally as possible, so it had better not contain any loopholes). Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCZodM052509; Fri, 27 May 2005 05:35:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RCZoEg052507; Fri, 27 May 2005 05:35:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCZmbd052465 for ; Fri, 27 May 2005 05:35:48 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 2E09E14C035; Fri, 27 May 2005 13:35:43 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A0688F16512; Fri, 27 May 2005 13:35:43 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id C3C3C14C035; Fri, 27 May 2005 13:35:42 +0100 (IST) Message-ID: <42971517.1010104@cs.tcd.ie> Date: Fri, 27 May 2005 13:39:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> <4296F66E.3020406@bull.net> <42971110.5040008@cs.tcd.ie> <429712E8.7050708@bull.net> In-Reply-To: <429712E8.7050708@bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.733) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A1688F16512 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, Fine by me. Have a nice trip, Stephen. Denis Pinkas wrote: > Stephen, > > Just before leaving my office in a few minutes for a few days, > here is a new text proposal for the DS bit: > > New proposal for 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service. However, it SHALL not be set > when certificate signing (bit 5) or CRL signing (bit 6) is set. > > Denis > >> Hi Denis, >> >> I've no problem with aligning the DS bit text although I >> wouldn't say that they're incompatible actually. I like >> the way 3280 says the DS isn't for certs or CRLs which >> ISO doesn't seem to include. Would you like to propose >> an aligned paragraph? >> >> I oppose inclusion of new NR/CC text and the name change. >> >> Stephen. >> >> Denis Pinkas wrote: >> >>> Stephen, >>> >>> I agree with everything Hoyt said on bit 1. >>> >>> However, there are two sides for this coin : bit 0 and bit 1. >>> >>> Both are again copied below: >>> >>> ISO Corrigendum: >>> >>> a) digitalSignature: for verifying digital signatures that are used >>> with an entity authentication service, a data origin >>> authentication >>> service or/and an integrity service; >>> >>> 3280bis: >>> >>> The digitalSignature bit is asserted when the subject public key >>> is used with a digital signature mechanism to support security >>> services other than certificate signing (bit 5), or CRL signing >>> (bit 6). Digital signature mechanisms are often used for entity >>> authentication and data origin authentication with integrity. >>> >>> The current text of 3280bis for bit 0 (ds) is incompatible with the ISO >>> Corrigendum. >>> >>> As Hoyt already said, any new text should align with the definition >>> in the approved technical corrigenda against the 4th edition and in >>> the upcoming 5th edition. >>> >>> Denis >>> >>>> Hi Hoyt, >>>> >>>> Hoyt L Kesterson II wrote: >>>> >>>>> Stephen >>>>> >>>>> I am somewhat dismayed at your reaction to the new text in X.509. >>>> >>>> >>>> >>>> >>>> >>>> I'm sorry about that, but I guess I'm just fed up with the >>>> NR bit, though I can understand how people who've worked >>>> hard to try fix it might be dismayed. >>>> >>>> (BTW: I once suggested that CAs MUST set this bit randomly >>>> since that was the only way I could see to kill it off >>>> properly. If you can get that into X.509 then I'd be happy >>>> for 3280bis to align:-) >>>> >>>> > I am not going to argue with you here (maybe in a bar the next time >>>> > we run into each other). >>>> >>>> Good idea! >>>> >>>>> However, I do want to mention several points. >>>>> >>>>> 1) I initiated the change in text because of the various >>>>> interpretations >>>> >>>> >>>> >>>> >>>> > by implementors that were resulting in non-interoperable >>>> > implementations. It was a conversation with a PKIXer at a RSA >>>> > conference a few years ago that caused me to articulate a private >>>> > concern. >>>> >>>> I agree that everything connected with this bit has been >>>> confused and remains so. >>>> >>>>> 2) The legal community was very confused. There was even a >>>> >>>> >>>> >>>> >>>> > paper castigating the standard developers for mandating that >>>> > one could not repudiate an action. >>>> >>>> Maybe the mistake was defining a bit that laywers care about? >>>> >>>>> 3) There were several meetings held where there was significant >>>> >>>> >>>> >>>> >>>> > participation by people in the IETF PKIX group (as well as >>>> > lawyers). All agreed there was a problem with the published text. >>>> > Denis and I argued long and hard over wording but we didn't >>>> > disagree on the need for new text and its general intent. >>>> >>>> Fair enough. >>>> >>>>> 4) Russ was concerned that change would cause a problem >>>> >>>> >>>> >>>> >>>> > with existing IETF standards and was not too happy with a >>>> > change to the name of the bit. That's why I put the line >>>> > in that you referenced. However, that was to grandfather >>>> > existing text, not to allow new text to continue using >>>> > the old term and definitions. >>>> >>>> Ok. Here's the real reason not to change: Many people use >>>> ASN.1 compilers which means that names from the ASN.1 >>>> module end up being directly used in higher layer code. >>>> Changing the name causes that code not to compile. I'd >>>> say that there's quite a lot of 3280 code in the world >>>> at this stage. So, if the semantics isn't supposed to >>>> have changed (and I assume that is meant to be the >>>> case) then this cost just doesn't seem worthwhile. >>>> >>>>> 5) It is the definition that is important. I recommend >>>> >>>> >>>> >>>> >>>> > that any new text align with the definition in the approved >>>> > technical corrigenda against the 4th edition and in >>>> > the upcoming 5th edition. >>>> >>>> While I'd rather not see any more text added on this, >>>> (there's been way too much already) I wouldn't have a big >>>> issue with trying to help a reader make sense of the >>>> fact that 3280bis and x.509 name this bit differently. >>>> >>>> However text like the sentence below is IMO almost >>>> certain to cause even more confusion: >>>> >>>> The precise type of commitment of the signer e.g. "reviewed >>>> and approved" or "with the intent to be bound", may be >>>> signalled by the content being signed, e.g. the signed >>>> document itself or some additional signed information. >>>> >>>> That sounds like the sole purpose of the CC-bit is as >>>> a flag to indicate when some other bits somewhere else >>>> tell you what the CC-bit means. >>>> >>>> So in the absence of some better text I think that 3280bis >>>> is better off just saying "NR a.k.a. CC" as it currently >>>> does. >>>> >>>> Regards, >>>> Stephen. >>>> >>>>> >>>>> At 14:49 +0100 5/26/05, Stephen Farrell wrote: >>>>> >>>>>> Denis, >>>>>> >>>>>> >>>>>>> Please align with the the ISO-ITU text. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Do you mean we should rename the bits and include the >>>>>> other new x.509 text? The design team were against >>>>>> doing that. >>>>>> >>>>>> Is there any (good) reason other than alignment to >>>>>> make such a change? >>>>>> >>>>>> Personally, I find the new x.509 text worse, although >>>>>> it does say: "Note that it is not incorrect to refer to >>>>>> this keyUsage bit using the identifier nonRepudiation." >>>>>> So I can argue that we are aligned, just not identical. >>>>>> >>>>>> But of course, I'm from the non-repudiation is non-sense >>>>>> camp so I may not be the best judge. >>>>>> >>>>>> Stephen. >>>>>> >>>>>> PS: A quibble: >>>>>> >>>>>> >>>>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>>>> [the nonRepudiation] bit to contentCommitment" >>>>>>> >>>>>>> This statement is untrue. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The paragraph to which I assume you refer contains 3 >>>>>> statements - it'd be easier to close these threads if >>>>>> you were more precise. (I think I got what you want >>>>>> by the end of the mail though...) >>>>>> >>>>>> PPS: "This statement is untrue." >>>>>> Are you from Crete after all? :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Denis Pinkas wrote: >>>>>> >>>>>> >>>>>>> To the list, >>>>>>> >>>>>>> The disposition of comments states: >>>>>>> >>>>>>> 13) The descriptions of the meanings of the digitalSignature and >>>>>>> nonRepudiation bits of keyUsage may need to be adjusted based >>>>>>> on the work in X.509 >>>>>>> >>>>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>>>> [the nonRepudiation] bit to contentCommitment" >>>>>>> >>>>>>> This statement is untrue. >>>>>>> >>>>>>> The text from X.509 has been published in Corrigendum 3 (04/2004) >>>>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>>>>>> >>>>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>>>>>> >>>>>>> An extract from this text is copied below: >>>>>>> >>>>>>> a) digitalSignature: for verifying digital signatures that are used >>>>>>> with an entity authentication service, a data origin authentication >>>>>>> service or/and an integrity service; >>>>>>> >>>>>>> b) contentCommitment: for verifying digital signatures which are >>>>>>> intended >>>>>>> to signal that the signer is committing to the content being >>>>>>> signed. >>>>>>> The type of commitment the certificate can be used to support >>>>>>> may be >>>>>>> further constrained by the CA, e.g. through a certificate policy. >>>>>>> The precise type of commitment of the signer e.g. "reviewed and >>>>>>> approved" or "with the intent to be bound", may be signalled by the >>>>>>> content being signed, e.g. the signed document itself or some >>>>>>> additional >>>>>>> signed information. >>>>>>> >>>>>>> Since a content commitment signing is considered to be a >>>>>>> digitally signed >>>>>>> transaction, the digitalSignature bit need not be set in the >>>>>>> certificate. >>>>>>> If it is set, it does not affect the level of commitment the >>>>>>> signer has >>>>>>> endowed in the signed content. >>>>>>> >>>>>>> Note that it is not incorrect to refer to this keyUsage bit >>>>>>> using the >>>>>>> identifier nonRepudiation. However, the use of this identifier >>>>>>> has been >>>>>>> deprecated. Regardless of the identifier used, the semantics of >>>>>>> this bit >>>>>>> are as specified in this Directory Specification. >>>>>>> >>>>>>> The text from 3280 is copied below: >>>>>>> >>>>>>> The digitalSignature bit is asserted when the subject public key >>>>>>> is used with a digital signature mechanism to support security >>>>>>> services other than certificate signing (bit 5), or CRL signing >>>>>>> (bit 6). Digital signature mechanisms are often used for entity >>>>>>> authentication and data origin authentication with integrity. >>>>>>> >>>>>>> The nonRepudiation bit is asserted when the subject public >>>>>>> key is >>>>>>> used to verify digital signatures used to provide a non- >>>>>>> repudiation service which protects against the signing entity >>>>>>> falsely denying some action, excluding certificate or CRL >>>>>>> signing. >>>>>>> In the case of later conflict, a reliable third party may >>>>>>> determine the authenticity of the signed data. >>>>>>> >>>>>>> Further distinctions between the digitalSignature and >>>>>>> nonRepudiation bits may be provided in specific certificate >>>>>>> policies. >>>>>>> >>>>>>> The text from 3280bis does not align with the ISO-ITU text. >>>>>>> Please align with the the ISO-ITU text. >>>>>>> >>>>>>> Denis >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCTdRF050275; Fri, 27 May 2005 05:29:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RCTdYt050274; Fri, 27 May 2005 05:29:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCTbr2050230 for ; Fri, 27 May 2005 05:29:38 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA30434; Fri, 27 May 2005 14:44:42 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052714293001:1975 ; Fri, 27 May 2005 14:29:30 +0200 Message-ID: <429712E8.7050708@bull.net> Date: Fri, 27 May 2005 14:30:32 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stephen Farrell CC: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> <4296F66E.3020406@bull.net> <42971110.5040008@cs.tcd.ie> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/05/2005 14:29:30, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/05/2005 14:29:31, Serialize complete at 27/05/2005 14:29:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephen, Just before leaving my office in a few minutes for a few days, here is a new text proposal for the DS bit: New proposal for 3280bis: The digitalSignature bit is asserted when the subject public key is used for verifying digital signatures that are used with an entity authentication service, a data origin authentication service or/and an integrity service. However, it SHALL not be set when certificate signing (bit 5) or CRL signing (bit 6) is set. Denis > Hi Denis, > > I've no problem with aligning the DS bit text although I > wouldn't say that they're incompatible actually. I like > the way 3280 says the DS isn't for certs or CRLs which > ISO doesn't seem to include. Would you like to propose > an aligned paragraph? > > I oppose inclusion of new NR/CC text and the name change. > > Stephen. > > Denis Pinkas wrote: > >> Stephen, >> >> I agree with everything Hoyt said on bit 1. >> >> However, there are two sides for this coin : bit 0 and bit 1. >> >> Both are again copied below: >> >> ISO Corrigendum: >> >> a) digitalSignature: for verifying digital signatures that are used >> with an entity authentication service, a data origin >> authentication >> service or/and an integrity service; >> >> 3280bis: >> >> The digitalSignature bit is asserted when the subject public key >> is used with a digital signature mechanism to support security >> services other than certificate signing (bit 5), or CRL signing >> (bit 6). Digital signature mechanisms are often used for entity >> authentication and data origin authentication with integrity. >> >> The current text of 3280bis for bit 0 (ds) is incompatible with the ISO >> Corrigendum. >> >> As Hoyt already said, any new text should align with the definition in >> the approved technical corrigenda against the 4th edition and in the >> upcoming 5th edition. >> >> Denis >> >>> Hi Hoyt, >>> >>> Hoyt L Kesterson II wrote: >>> >>>> Stephen >>>> >>>> I am somewhat dismayed at your reaction to the new text in X.509. >>> >>> >>> >>> >>> I'm sorry about that, but I guess I'm just fed up with the >>> NR bit, though I can understand how people who've worked >>> hard to try fix it might be dismayed. >>> >>> (BTW: I once suggested that CAs MUST set this bit randomly >>> since that was the only way I could see to kill it off >>> properly. If you can get that into X.509 then I'd be happy >>> for 3280bis to align:-) >>> >>> > I am not going to argue with you here (maybe in a bar the next time >>> > we run into each other). >>> >>> Good idea! >>> >>>> However, I do want to mention several points. >>>> >>>> 1) I initiated the change in text because of the various >>>> interpretations >>> >>> >>> >>> > by implementors that were resulting in non-interoperable >>> > implementations. It was a conversation with a PKIXer at a RSA >>> > conference a few years ago that caused me to articulate a private >>> > concern. >>> >>> I agree that everything connected with this bit has been >>> confused and remains so. >>> >>>> 2) The legal community was very confused. There was even a >>> >>> >>> >>> > paper castigating the standard developers for mandating that >>> > one could not repudiate an action. >>> >>> Maybe the mistake was defining a bit that laywers care about? >>> >>>> 3) There were several meetings held where there was significant >>> >>> >>> >>> > participation by people in the IETF PKIX group (as well as >>> > lawyers). All agreed there was a problem with the published text. >>> > Denis and I argued long and hard over wording but we didn't >>> > disagree on the need for new text and its general intent. >>> >>> Fair enough. >>> >>>> 4) Russ was concerned that change would cause a problem >>> >>> >>> >>> > with existing IETF standards and was not too happy with a >>> > change to the name of the bit. That's why I put the line >>> > in that you referenced. However, that was to grandfather >>> > existing text, not to allow new text to continue using >>> > the old term and definitions. >>> >>> Ok. Here's the real reason not to change: Many people use >>> ASN.1 compilers which means that names from the ASN.1 >>> module end up being directly used in higher layer code. >>> Changing the name causes that code not to compile. I'd >>> say that there's quite a lot of 3280 code in the world >>> at this stage. So, if the semantics isn't supposed to >>> have changed (and I assume that is meant to be the >>> case) then this cost just doesn't seem worthwhile. >>> >>>> 5) It is the definition that is important. I recommend >>> >>> >>> >>> > that any new text align with the definition in the approved >>> > technical corrigenda against the 4th edition and in >>> > the upcoming 5th edition. >>> >>> While I'd rather not see any more text added on this, >>> (there's been way too much already) I wouldn't have a big >>> issue with trying to help a reader make sense of the >>> fact that 3280bis and x.509 name this bit differently. >>> >>> However text like the sentence below is IMO almost >>> certain to cause even more confusion: >>> >>> The precise type of commitment of the signer e.g. "reviewed >>> and approved" or "with the intent to be bound", may be >>> signalled by the content being signed, e.g. the signed >>> document itself or some additional signed information. >>> >>> That sounds like the sole purpose of the CC-bit is as >>> a flag to indicate when some other bits somewhere else >>> tell you what the CC-bit means. >>> >>> So in the absence of some better text I think that 3280bis >>> is better off just saying "NR a.k.a. CC" as it currently >>> does. >>> >>> Regards, >>> Stephen. >>> >>>> >>>> At 14:49 +0100 5/26/05, Stephen Farrell wrote: >>>> >>>>> Denis, >>>>> >>>>> >>>>>> Please align with the the ISO-ITU text. >>>>> >>>>> >>>>> >>>>> >>>>> Do you mean we should rename the bits and include the >>>>> other new x.509 text? The design team were against >>>>> doing that. >>>>> >>>>> Is there any (good) reason other than alignment to >>>>> make such a change? >>>>> >>>>> Personally, I find the new x.509 text worse, although >>>>> it does say: "Note that it is not incorrect to refer to >>>>> this keyUsage bit using the identifier nonRepudiation." >>>>> So I can argue that we are aligned, just not identical. >>>>> >>>>> But of course, I'm from the non-repudiation is non-sense >>>>> camp so I may not be the best judge. >>>>> >>>>> Stephen. >>>>> >>>>> PS: A quibble: >>>>> >>>>> >>>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>>> [the nonRepudiation] bit to contentCommitment" >>>>>> >>>>>> This statement is untrue. >>>>> >>>>> >>>>> >>>>> >>>>> The paragraph to which I assume you refer contains 3 >>>>> statements - it'd be easier to close these threads if >>>>> you were more precise. (I think I got what you want >>>>> by the end of the mail though...) >>>>> >>>>> PPS: "This statement is untrue." >>>>> Are you from Crete after all? :-) >>>>> >>>>> >>>>> >>>>> >>>>> Denis Pinkas wrote: >>>>> >>>>> >>>>>> To the list, >>>>>> >>>>>> The disposition of comments states: >>>>>> >>>>>> 13) The descriptions of the meanings of the digitalSignature and >>>>>> nonRepudiation bits of keyUsage may need to be adjusted based >>>>>> on the work in X.509 >>>>>> >>>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>>> [the nonRepudiation] bit to contentCommitment" >>>>>> >>>>>> This statement is untrue. >>>>>> >>>>>> The text from X.509 has been published in Corrigendum 3 (04/2004) >>>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>>>>> >>>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>>>>> >>>>>> An extract from this text is copied below: >>>>>> >>>>>> a) digitalSignature: for verifying digital signatures that are used >>>>>> with an entity authentication service, a data origin authentication >>>>>> service or/and an integrity service; >>>>>> >>>>>> b) contentCommitment: for verifying digital signatures which are >>>>>> intended >>>>>> to signal that the signer is committing to the content being signed. >>>>>> The type of commitment the certificate can be used to support may be >>>>>> further constrained by the CA, e.g. through a certificate policy. >>>>>> The precise type of commitment of the signer e.g. "reviewed and >>>>>> approved" or "with the intent to be bound", may be signalled by the >>>>>> content being signed, e.g. the signed document itself or some >>>>>> additional >>>>>> signed information. >>>>>> >>>>>> Since a content commitment signing is considered to be a >>>>>> digitally signed >>>>>> transaction, the digitalSignature bit need not be set in the >>>>>> certificate. >>>>>> If it is set, it does not affect the level of commitment the >>>>>> signer has >>>>>> endowed in the signed content. >>>>>> >>>>>> Note that it is not incorrect to refer to this keyUsage bit using >>>>>> the >>>>>> identifier nonRepudiation. However, the use of this identifier >>>>>> has been >>>>>> deprecated. Regardless of the identifier used, the semantics of >>>>>> this bit >>>>>> are as specified in this Directory Specification. >>>>>> >>>>>> The text from 3280 is copied below: >>>>>> >>>>>> The digitalSignature bit is asserted when the subject public key >>>>>> is used with a digital signature mechanism to support security >>>>>> services other than certificate signing (bit 5), or CRL signing >>>>>> (bit 6). Digital signature mechanisms are often used for entity >>>>>> authentication and data origin authentication with integrity. >>>>>> >>>>>> The nonRepudiation bit is asserted when the subject public key is >>>>>> used to verify digital signatures used to provide a non- >>>>>> repudiation service which protects against the signing entity >>>>>> falsely denying some action, excluding certificate or CRL >>>>>> signing. >>>>>> In the case of later conflict, a reliable third party may >>>>>> determine the authenticity of the signed data. >>>>>> >>>>>> Further distinctions between the digitalSignature and >>>>>> nonRepudiation bits may be provided in specific certificate >>>>>> policies. >>>>>> >>>>>> The text from 3280bis does not align with the ISO-ITU text. >>>>>> Please align with the the ISO-ITU text. >>>>>> >>>>>> Denis >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCIj3r044234; Fri, 27 May 2005 05:18:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RCIjSa044233; Fri, 27 May 2005 05:18:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCIiGx044135 for ; Fri, 27 May 2005 05:18:44 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 5B31514C042; Fri, 27 May 2005 13:18:36 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A063603A50D; Fri, 27 May 2005 13:18:36 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 046EA14C042; Fri, 27 May 2005 13:18:35 +0100 (IST) Message-ID: <42971110.5040008@cs.tcd.ie> Date: Fri, 27 May 2005 13:22:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> <4296F66E.3020406@bull.net> In-Reply-To: <4296F66E.3020406@bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.733) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A163603A50D Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Denis, I've no problem with aligning the DS bit text although I wouldn't say that they're incompatible actually. I like the way 3280 says the DS isn't for certs or CRLs which ISO doesn't seem to include. Would you like to propose an aligned paragraph? I oppose inclusion of new NR/CC text and the name change. Stephen. Denis Pinkas wrote: > Stephen, > > I agree with everything Hoyt said on bit 1. > > However, there are two sides for this coin : bit 0 and bit 1. > > Both are again copied below: > > ISO Corrigendum: > > a) digitalSignature: for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service; > > 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > The current text of 3280bis for bit 0 (ds) is incompatible with the ISO > Corrigendum. > > As Hoyt already said, any new text should align with the definition in > the approved technical corrigenda against the 4th edition and in the > upcoming 5th edition. > > Denis > >> Hi Hoyt, >> >> Hoyt L Kesterson II wrote: >> >>> Stephen >>> >>> I am somewhat dismayed at your reaction to the new text in X.509. >> >> >> >> I'm sorry about that, but I guess I'm just fed up with the >> NR bit, though I can understand how people who've worked >> hard to try fix it might be dismayed. >> >> (BTW: I once suggested that CAs MUST set this bit randomly >> since that was the only way I could see to kill it off >> properly. If you can get that into X.509 then I'd be happy >> for 3280bis to align:-) >> >> > I am not going to argue with you here (maybe in a bar the next time >> > we run into each other). >> >> Good idea! >> >>> However, I do want to mention several points. >>> >>> 1) I initiated the change in text because of the various interpretations >> >> >> > by implementors that were resulting in non-interoperable >> > implementations. It was a conversation with a PKIXer at a RSA >> > conference a few years ago that caused me to articulate a private >> > concern. >> >> I agree that everything connected with this bit has been >> confused and remains so. >> >>> 2) The legal community was very confused. There was even a >> >> >> > paper castigating the standard developers for mandating that >> > one could not repudiate an action. >> >> Maybe the mistake was defining a bit that laywers care about? >> >>> 3) There were several meetings held where there was significant >> >> >> > participation by people in the IETF PKIX group (as well as >> > lawyers). All agreed there was a problem with the published text. >> > Denis and I argued long and hard over wording but we didn't >> > disagree on the need for new text and its general intent. >> >> Fair enough. >> >>> 4) Russ was concerned that change would cause a problem >> >> >> > with existing IETF standards and was not too happy with a >> > change to the name of the bit. That's why I put the line >> > in that you referenced. However, that was to grandfather >> > existing text, not to allow new text to continue using >> > the old term and definitions. >> >> Ok. Here's the real reason not to change: Many people use >> ASN.1 compilers which means that names from the ASN.1 >> module end up being directly used in higher layer code. >> Changing the name causes that code not to compile. I'd >> say that there's quite a lot of 3280 code in the world >> at this stage. So, if the semantics isn't supposed to >> have changed (and I assume that is meant to be the >> case) then this cost just doesn't seem worthwhile. >> >>> 5) It is the definition that is important. I recommend >> >> >> > that any new text align with the definition in the approved >> > technical corrigenda against the 4th edition and in >> > the upcoming 5th edition. >> >> While I'd rather not see any more text added on this, >> (there's been way too much already) I wouldn't have a big >> issue with trying to help a reader make sense of the >> fact that 3280bis and x.509 name this bit differently. >> >> However text like the sentence below is IMO almost >> certain to cause even more confusion: >> >> The precise type of commitment of the signer e.g. "reviewed >> and approved" or "with the intent to be bound", may be >> signalled by the content being signed, e.g. the signed >> document itself or some additional signed information. >> >> That sounds like the sole purpose of the CC-bit is as >> a flag to indicate when some other bits somewhere else >> tell you what the CC-bit means. >> >> So in the absence of some better text I think that 3280bis >> is better off just saying "NR a.k.a. CC" as it currently >> does. >> >> Regards, >> Stephen. >> >>> >>> At 14:49 +0100 5/26/05, Stephen Farrell wrote: >>> >>>> Denis, >>>> >>>> >>>>> Please align with the the ISO-ITU text. >>>> >>>> >>>> >>>> Do you mean we should rename the bits and include the >>>> other new x.509 text? The design team were against >>>> doing that. >>>> >>>> Is there any (good) reason other than alignment to >>>> make such a change? >>>> >>>> Personally, I find the new x.509 text worse, although >>>> it does say: "Note that it is not incorrect to refer to >>>> this keyUsage bit using the identifier nonRepudiation." >>>> So I can argue that we are aligned, just not identical. >>>> >>>> But of course, I'm from the non-repudiation is non-sense >>>> camp so I may not be the best judge. >>>> >>>> Stephen. >>>> >>>> PS: A quibble: >>>> >>>> >>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>> [the nonRepudiation] bit to contentCommitment" >>>>> >>>>> This statement is untrue. >>>> >>>> >>>> >>>> The paragraph to which I assume you refer contains 3 >>>> statements - it'd be easier to close these threads if >>>> you were more precise. (I think I got what you want >>>> by the end of the mail though...) >>>> >>>> PPS: "This statement is untrue." >>>> Are you from Crete after all? :-) >>>> >>>> >>>> >>>> >>>> Denis Pinkas wrote: >>>> >>>> >>>>> To the list, >>>>> >>>>> The disposition of comments states: >>>>> >>>>> 13) The descriptions of the meanings of the digitalSignature and >>>>> nonRepudiation bits of keyUsage may need to be adjusted based >>>>> on the work in X.509 >>>>> >>>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>>> KeyUsage stating that "recent editions of X.509 have renamed >>>>> [the nonRepudiation] bit to contentCommitment" >>>>> >>>>> This statement is untrue. >>>>> >>>>> The text from X.509 has been published in Corrigendum 3 (04/2004) >>>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>>>> >>>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>>>> >>>>> An extract from this text is copied below: >>>>> >>>>> a) digitalSignature: for verifying digital signatures that are used >>>>> with an entity authentication service, a data origin authentication >>>>> service or/and an integrity service; >>>>> >>>>> b) contentCommitment: for verifying digital signatures which are >>>>> intended >>>>> to signal that the signer is committing to the content being signed. >>>>> The type of commitment the certificate can be used to support may be >>>>> further constrained by the CA, e.g. through a certificate policy. >>>>> The precise type of commitment of the signer e.g. "reviewed and >>>>> approved" or "with the intent to be bound", may be signalled by the >>>>> content being signed, e.g. the signed document itself or some >>>>> additional >>>>> signed information. >>>>> >>>>> Since a content commitment signing is considered to be a digitally >>>>> signed >>>>> transaction, the digitalSignature bit need not be set in the >>>>> certificate. >>>>> If it is set, it does not affect the level of commitment the >>>>> signer has >>>>> endowed in the signed content. >>>>> >>>>> Note that it is not incorrect to refer to this keyUsage bit using the >>>>> identifier nonRepudiation. However, the use of this identifier has >>>>> been >>>>> deprecated. Regardless of the identifier used, the semantics of >>>>> this bit >>>>> are as specified in this Directory Specification. >>>>> >>>>> The text from 3280 is copied below: >>>>> >>>>> The digitalSignature bit is asserted when the subject public key >>>>> is used with a digital signature mechanism to support security >>>>> services other than certificate signing (bit 5), or CRL signing >>>>> (bit 6). Digital signature mechanisms are often used for entity >>>>> authentication and data origin authentication with integrity. >>>>> >>>>> The nonRepudiation bit is asserted when the subject public key is >>>>> used to verify digital signatures used to provide a non- >>>>> repudiation service which protects against the signing entity >>>>> falsely denying some action, excluding certificate or CRL signing. >>>>> In the case of later conflict, a reliable third party may >>>>> determine the authenticity of the signed data. >>>>> >>>>> Further distinctions between the digitalSignature and >>>>> nonRepudiation bits may be provided in specific certificate >>>>> policies. >>>>> >>>>> The text from 3280bis does not align with the ISO-ITU text. >>>>> Please align with the the ISO-ITU text. >>>>> >>>>> Denis >>>> >>>> >>> >>> >>> >> >> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RC6L8s038480; Fri, 27 May 2005 05:06:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RC6LYb038478; Fri, 27 May 2005 05:06:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RC6Gso038396 for ; Fri, 27 May 2005 05:06:17 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 13:06:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: 3280bis: key usage (13) Date: Fri, 27 May 2005 13:06:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3280bis: key usage (13) Thread-Index: AcVirx3GaexNZnC4Qoi6SQuzG1QlLQAA1h7A From: "Stefan Santesson" To: "Denis Pinkas" , "Stephen Farrell" Cc: "Hoyt L Kesterson II" , "pkix" X-OriginalArrivalTime: 27 May 2005 12:06:11.0318 (UTC) FILETIME=[78F98160:01C562B4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4RC6Hso038443 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Speaking as implementer and not design team member, I can live with both texts since they allow me to do the same thing. It allows my low level application to add a digital signature supported by the digital signature bit, where the intention of that application is to add integrity and origin authentication, while the use of the signature in practice (higher layers) ends up being used as evidence of some kind of commitment. Example. An e-mail application adds an arbitrary signature supported by the DS bit, while the body of the text reads "Through the digital signature on this e-mail I commit to....). This is now a perfectly valid scenario according to both texts. The real defect that was fixed was that the digital signature bit said that it was for purposes "other" than NR. That is now gone in both standards. I agree to Stephen's rationale to keep the name nonRepudiation. It is not worth the cost to change the name. Stephen's point here was missing in the X.509 discussions of a name change. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 27 maj 2005 12:29 > To: Stephen Farrell > Cc: Hoyt L Kesterson II; pkix > Subject: Re: 3280bis: key usage (13) > > > Stephen, > > I agree with everything Hoyt said on bit 1. > > However, there are two sides for this coin : bit 0 and bit 1. > > Both are again copied below: > > ISO Corrigendum: > > a) digitalSignature: for verifying digital signatures that are used > with an entity authentication service, a data origin > authentication > service or/and an integrity service; > > 3280bis: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > The current text of 3280bis for bit 0 (ds) is incompatible with the ISO > Corrigendum. > > As Hoyt already said, any new text should align with the definition in the > approved technical corrigenda against the 4th edition and in the upcoming > 5th edition. > > Denis > > > Hi Hoyt, > > > > Hoyt L Kesterson II wrote: > > > >> Stephen > >> > >> I am somewhat dismayed at your reaction to the new text in X.509. > > > > > > I'm sorry about that, but I guess I'm just fed up with the > > NR bit, though I can understand how people who've worked > > hard to try fix it might be dismayed. > > > > (BTW: I once suggested that CAs MUST set this bit randomly > > since that was the only way I could see to kill it off > > properly. If you can get that into X.509 then I'd be happy > > for 3280bis to align:-) > > > > > I am not going to argue with you here (maybe in a bar the next time > > > we run into each other). > > > > Good idea! > > > >> However, I do want to mention several points. > >> > >> 1) I initiated the change in text because of the various > interpretations > > > > > by implementors that were resulting in non-interoperable > > > implementations. It was a conversation with a PKIXer at a RSA > > > conference a few years ago that caused me to articulate a private > > > concern. > > > > I agree that everything connected with this bit has been > > confused and remains so. > > > >> 2) The legal community was very confused. There was even a > > > > > paper castigating the standard developers for mandating that > > > one could not repudiate an action. > > > > Maybe the mistake was defining a bit that laywers care about? > > > >> 3) There were several meetings held where there was significant > > > > > participation by people in the IETF PKIX group (as well as > > > lawyers). All agreed there was a problem with the published text. > > > Denis and I argued long and hard over wording but we didn't > > > disagree on the need for new text and its general intent. > > > > Fair enough. > > > >> 4) Russ was concerned that change would cause a problem > > > > > with existing IETF standards and was not too happy with a > > > change to the name of the bit. That's why I put the line > > > in that you referenced. However, that was to grandfather > > > existing text, not to allow new text to continue using > > > the old term and definitions. > > > > Ok. Here's the real reason not to change: Many people use > > ASN.1 compilers which means that names from the ASN.1 > > module end up being directly used in higher layer code. > > Changing the name causes that code not to compile. I'd > > say that there's quite a lot of 3280 code in the world > > at this stage. So, if the semantics isn't supposed to > > have changed (and I assume that is meant to be the > > case) then this cost just doesn't seem worthwhile. > > > >> 5) It is the definition that is important. I recommend > > > > > that any new text align with the definition in the approved > > > technical corrigenda against the 4th edition and in > > > the upcoming 5th edition. > > > > While I'd rather not see any more text added on this, > > (there's been way too much already) I wouldn't have a big > > issue with trying to help a reader make sense of the > > fact that 3280bis and x.509 name this bit differently. > > > > However text like the sentence below is IMO almost > > certain to cause even more confusion: > > > > The precise type of commitment of the signer e.g. "reviewed > > and approved" or "with the intent to be bound", may be > > signalled by the content being signed, e.g. the signed > > document itself or some additional signed information. > > > > That sounds like the sole purpose of the CC-bit is as > > a flag to indicate when some other bits somewhere else > > tell you what the CC-bit means. > > > > So in the absence of some better text I think that 3280bis > > is better off just saying "NR a.k.a. CC" as it currently > > does. > > > > Regards, > > Stephen. > > > >> > >> At 14:49 +0100 5/26/05, Stephen Farrell wrote: > >> > >>> Denis, > >>> > >>> > >>>> Please align with the the ISO-ITU text. > >>> > >>> > >>> Do you mean we should rename the bits and include the > >>> other new x.509 text? The design team were against > >>> doing that. > >>> > >>> Is there any (good) reason other than alignment to > >>> make such a change? > >>> > >>> Personally, I find the new x.509 text worse, although > >>> it does say: "Note that it is not incorrect to refer to > >>> this keyUsage bit using the identifier nonRepudiation." > >>> So I can argue that we are aligned, just not identical. > >>> > >>> But of course, I'm from the non-repudiation is non-sense > >>> camp so I may not be the best judge. > >>> > >>> Stephen. > >>> > >>> PS: A quibble: > >>> > >>> > >>>> The new text in X.509 aligns with the text in RFC 3280. No changes > >>>> are required to 3280bis. A comment has been added to the ASN.1 for > >>>> KeyUsage stating that "recent editions of X.509 have renamed > >>>> [the nonRepudiation] bit to contentCommitment" > >>>> > >>>> This statement is untrue. > >>> > >>> > >>> The paragraph to which I assume you refer contains 3 > >>> statements - it'd be easier to close these threads if > >>> you were more precise. (I think I got what you want > >>> by the end of the mail though...) > >>> > >>> PPS: "This statement is untrue." > >>> Are you from Crete after all? :-) > >>> > >>> > >>> > >>> > >>> Denis Pinkas wrote: > >>> > >>> > >>>> To the list, > >>>> > >>>> The disposition of comments states: > >>>> > >>>> 13) The descriptions of the meanings of the digitalSignature and > >>>> nonRepudiation bits of keyUsage may need to be adjusted based > >>>> on the work in X.509 > >>>> > >>>> The new text in X.509 aligns with the text in RFC 3280. No changes > >>>> are required to 3280bis. A comment has been added to the ASN.1 for > >>>> KeyUsage stating that "recent editions of X.509 have renamed > >>>> [the nonRepudiation] bit to contentCommitment" > >>>> > >>>> This statement is untrue. > >>>> > >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) > >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called > >>>> > >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). > >>>> > >>>> An extract from this text is copied below: > >>>> > >>>> a) digitalSignature: for verifying digital signatures that are used > >>>> with an entity authentication service, a data origin authentication > >>>> service or/and an integrity service; > >>>> > >>>> b) contentCommitment: for verifying digital signatures which are > >>>> intended > >>>> to signal that the signer is committing to the content being signed. > >>>> The type of commitment the certificate can be used to support may be > >>>> further constrained by the CA, e.g. through a certificate policy. > >>>> The precise type of commitment of the signer e.g. "reviewed and > >>>> approved" or "with the intent to be bound", may be signalled by the > >>>> content being signed, e.g. the signed document itself or some > >>>> additional > >>>> signed information. > >>>> > >>>> Since a content commitment signing is considered to be a digitally > >>>> signed > >>>> transaction, the digitalSignature bit need not be set in the > >>>> certificate. > >>>> If it is set, it does not affect the level of commitment the signer > >>>> has > >>>> endowed in the signed content. > >>>> > >>>> Note that it is not incorrect to refer to this keyUsage bit using > the > >>>> identifier nonRepudiation. However, the use of this identifier has > >>>> been > >>>> deprecated. Regardless of the identifier used, the semantics of > >>>> this bit > >>>> are as specified in this Directory Specification. > >>>> > >>>> The text from 3280 is copied below: > >>>> > >>>> The digitalSignature bit is asserted when the subject public key > >>>> is used with a digital signature mechanism to support security > >>>> services other than certificate signing (bit 5), or CRL signing > >>>> (bit 6). Digital signature mechanisms are often used for entity > >>>> authentication and data origin authentication with integrity. > >>>> > >>>> The nonRepudiation bit is asserted when the subject public key is > >>>> used to verify digital signatures used to provide a non- > >>>> repudiation service which protects against the signing entity > >>>> falsely denying some action, excluding certificate or CRL > signing. > >>>> In the case of later conflict, a reliable third party may > >>>> determine the authenticity of the signed data. > >>>> > >>>> Further distinctions between the digitalSignature and > >>>> nonRepudiation bits may be provided in specific certificate > >>>> policies. > >>>> > >>>> The text from 3280bis does not align with the ISO-ITU text. > >>>> Please align with the the ISO-ITU text. > >>>> > >>>> Denis > >>> > >> > >> > >> > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RASCgt086751; Fri, 27 May 2005 03:28:12 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RASCZW086750; Fri, 27 May 2005 03:28:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RASBD2086703 for ; Fri, 27 May 2005 03:28:11 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA70810; Fri, 27 May 2005 12:43:13 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052712280030:1918 ; Fri, 27 May 2005 12:28:00 +0200 Message-ID: <4296F66E.3020406@bull.net> Date: Fri, 27 May 2005 12:29:02 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stephen Farrell CC: Hoyt L Kesterson II , pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> <4296EF39.4050202@cs.tcd.ie> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/05/2005 12:28:00, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 27/05/2005 12:28:02, Serialize complete at 27/05/2005 12:28:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephen, I agree with everything Hoyt said on bit 1. However, there are two sides for this coin : bit 0 and bit 1. Both are again copied below: ISO Corrigendum: a) digitalSignature: for verifying digital signatures that are used with an entity authentication service, a data origin authentication service or/and an integrity service; 3280bis: The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. The current text of 3280bis for bit 0 (ds) is incompatible with the ISO Corrigendum. As Hoyt already said, any new text should align with the definition in the approved technical corrigenda against the 4th edition and in the upcoming 5th edition. Denis > Hi Hoyt, > > Hoyt L Kesterson II wrote: > >> Stephen >> >> I am somewhat dismayed at your reaction to the new text in X.509. > > > I'm sorry about that, but I guess I'm just fed up with the > NR bit, though I can understand how people who've worked > hard to try fix it might be dismayed. > > (BTW: I once suggested that CAs MUST set this bit randomly > since that was the only way I could see to kill it off > properly. If you can get that into X.509 then I'd be happy > for 3280bis to align:-) > > > I am not going to argue with you here (maybe in a bar the next time > > we run into each other). > > Good idea! > >> However, I do want to mention several points. >> >> 1) I initiated the change in text because of the various interpretations > > > by implementors that were resulting in non-interoperable > > implementations. It was a conversation with a PKIXer at a RSA > > conference a few years ago that caused me to articulate a private > > concern. > > I agree that everything connected with this bit has been > confused and remains so. > >> 2) The legal community was very confused. There was even a > > > paper castigating the standard developers for mandating that > > one could not repudiate an action. > > Maybe the mistake was defining a bit that laywers care about? > >> 3) There were several meetings held where there was significant > > > participation by people in the IETF PKIX group (as well as > > lawyers). All agreed there was a problem with the published text. > > Denis and I argued long and hard over wording but we didn't > > disagree on the need for new text and its general intent. > > Fair enough. > >> 4) Russ was concerned that change would cause a problem > > > with existing IETF standards and was not too happy with a > > change to the name of the bit. That's why I put the line > > in that you referenced. However, that was to grandfather > > existing text, not to allow new text to continue using > > the old term and definitions. > > Ok. Here's the real reason not to change: Many people use > ASN.1 compilers which means that names from the ASN.1 > module end up being directly used in higher layer code. > Changing the name causes that code not to compile. I'd > say that there's quite a lot of 3280 code in the world > at this stage. So, if the semantics isn't supposed to > have changed (and I assume that is meant to be the > case) then this cost just doesn't seem worthwhile. > >> 5) It is the definition that is important. I recommend > > > that any new text align with the definition in the approved > > technical corrigenda against the 4th edition and in > > the upcoming 5th edition. > > While I'd rather not see any more text added on this, > (there's been way too much already) I wouldn't have a big > issue with trying to help a reader make sense of the > fact that 3280bis and x.509 name this bit differently. > > However text like the sentence below is IMO almost > certain to cause even more confusion: > > The precise type of commitment of the signer e.g. "reviewed > and approved" or "with the intent to be bound", may be > signalled by the content being signed, e.g. the signed > document itself or some additional signed information. > > That sounds like the sole purpose of the CC-bit is as > a flag to indicate when some other bits somewhere else > tell you what the CC-bit means. > > So in the absence of some better text I think that 3280bis > is better off just saying "NR a.k.a. CC" as it currently > does. > > Regards, > Stephen. > >> >> At 14:49 +0100 5/26/05, Stephen Farrell wrote: >> >>> Denis, >>> >>> >>>> Please align with the the ISO-ITU text. >>> >>> >>> Do you mean we should rename the bits and include the >>> other new x.509 text? The design team were against >>> doing that. >>> >>> Is there any (good) reason other than alignment to >>> make such a change? >>> >>> Personally, I find the new x.509 text worse, although >>> it does say: "Note that it is not incorrect to refer to >>> this keyUsage bit using the identifier nonRepudiation." >>> So I can argue that we are aligned, just not identical. >>> >>> But of course, I'm from the non-repudiation is non-sense >>> camp so I may not be the best judge. >>> >>> Stephen. >>> >>> PS: A quibble: >>> >>> >>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>> KeyUsage stating that "recent editions of X.509 have renamed >>>> [the nonRepudiation] bit to contentCommitment" >>>> >>>> This statement is untrue. >>> >>> >>> The paragraph to which I assume you refer contains 3 >>> statements - it'd be easier to close these threads if >>> you were more precise. (I think I got what you want >>> by the end of the mail though...) >>> >>> PPS: "This statement is untrue." >>> Are you from Crete after all? :-) >>> >>> >>> >>> >>> Denis Pinkas wrote: >>> >>> >>>> To the list, >>>> >>>> The disposition of comments states: >>>> >>>> 13) The descriptions of the meanings of the digitalSignature and >>>> nonRepudiation bits of keyUsage may need to be adjusted based >>>> on the work in X.509 >>>> >>>> The new text in X.509 aligns with the text in RFC 3280. No changes >>>> are required to 3280bis. A comment has been added to the ASN.1 for >>>> KeyUsage stating that "recent editions of X.509 have renamed >>>> [the nonRepudiation] bit to contentCommitment" >>>> >>>> This statement is untrue. >>>> >>>> The text from X.509 has been published in Corrigendum 3 (04/2004) >>>> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>>> >>>> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>>> >>>> An extract from this text is copied below: >>>> >>>> a) digitalSignature: for verifying digital signatures that are used >>>> with an entity authentication service, a data origin authentication >>>> service or/and an integrity service; >>>> >>>> b) contentCommitment: for verifying digital signatures which are >>>> intended >>>> to signal that the signer is committing to the content being signed. >>>> The type of commitment the certificate can be used to support may be >>>> further constrained by the CA, e.g. through a certificate policy. >>>> The precise type of commitment of the signer e.g. "reviewed and >>>> approved" or "with the intent to be bound", may be signalled by the >>>> content being signed, e.g. the signed document itself or some >>>> additional >>>> signed information. >>>> >>>> Since a content commitment signing is considered to be a digitally >>>> signed >>>> transaction, the digitalSignature bit need not be set in the >>>> certificate. >>>> If it is set, it does not affect the level of commitment the signer >>>> has >>>> endowed in the signed content. >>>> >>>> Note that it is not incorrect to refer to this keyUsage bit using the >>>> identifier nonRepudiation. However, the use of this identifier has >>>> been >>>> deprecated. Regardless of the identifier used, the semantics of >>>> this bit >>>> are as specified in this Directory Specification. >>>> >>>> The text from 3280 is copied below: >>>> >>>> The digitalSignature bit is asserted when the subject public key >>>> is used with a digital signature mechanism to support security >>>> services other than certificate signing (bit 5), or CRL signing >>>> (bit 6). Digital signature mechanisms are often used for entity >>>> authentication and data origin authentication with integrity. >>>> >>>> The nonRepudiation bit is asserted when the subject public key is >>>> used to verify digital signatures used to provide a non- >>>> repudiation service which protects against the signing entity >>>> falsely denying some action, excluding certificate or CRL signing. >>>> In the case of later conflict, a reliable third party may >>>> determine the authenticity of the signed data. >>>> >>>> Further distinctions between the digitalSignature and >>>> nonRepudiation bits may be provided in specific certificate >>>> policies. >>>> >>>> The text from 3280bis does not align with the ISO-ITU text. >>>> Please align with the the ISO-ITU text. >>>> >>>> Denis >>> >> >> >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R9sM3M073979; Fri, 27 May 2005 02:54:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4R9sM9s073977; Fri, 27 May 2005 02:54:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R9sJLK073925 for ; Fri, 27 May 2005 02:54:20 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 075B214C063; Fri, 27 May 2005 10:54:09 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A02C23D287F; Fri, 27 May 2005 10:54:08 +0100 Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 7D23E14C047; Fri, 27 May 2005 10:54:08 +0100 (IST) Message-ID: <4296EF39.4050202@cs.tcd.ie> Date: Fri, 27 May 2005 10:58:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hoyt L Kesterson II Cc: Denis Pinkas , pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.733) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A12C23D287F Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Hoyt, Hoyt L Kesterson II wrote: > Stephen > > I am somewhat dismayed at your reaction to the new text in X.509. I'm sorry about that, but I guess I'm just fed up with the NR bit, though I can understand how people who've worked hard to try fix it might be dismayed. (BTW: I once suggested that CAs MUST set this bit randomly since that was the only way I could see to kill it off properly. If you can get that into X.509 then I'd be happy for 3280bis to align:-) > I am not going to argue with you here (maybe in a bar the next time > we run into each other). Good idea! > However, I do want to mention several points. > > 1) I initiated the change in text because of the various interpretations > by implementors that were resulting in non-interoperable > implementations. It was a conversation with a PKIXer at a RSA > conference a few years ago that caused me to articulate a private > concern. I agree that everything connected with this bit has been confused and remains so. > 2) The legal community was very confused. There was even a > paper castigating the standard developers for mandating that > one could not repudiate an action. Maybe the mistake was defining a bit that laywers care about? > 3) There were several meetings held where there was significant > participation by people in the IETF PKIX group (as well as > lawyers). All agreed there was a problem with the published text. > Denis and I argued long and hard over wording but we didn't > disagree on the need for new text and its general intent. Fair enough. > 4) Russ was concerned that change would cause a problem > with existing IETF standards and was not too happy with a > change to the name of the bit. That's why I put the line > in that you referenced. However, that was to grandfather > existing text, not to allow new text to continue using > the old term and definitions. Ok. Here's the real reason not to change: Many people use ASN.1 compilers which means that names from the ASN.1 module end up being directly used in higher layer code. Changing the name causes that code not to compile. I'd say that there's quite a lot of 3280 code in the world at this stage. So, if the semantics isn't supposed to have changed (and I assume that is meant to be the case) then this cost just doesn't seem worthwhile. > 5) It is the definition that is important. I recommend > that any new text align with the definition in the approved > technical corrigenda against the 4th edition and in > the upcoming 5th edition. While I'd rather not see any more text added on this, (there's been way too much already) I wouldn't have a big issue with trying to help a reader make sense of the fact that 3280bis and x.509 name this bit differently. However text like the sentence below is IMO almost certain to cause even more confusion: The precise type of commitment of the signer e.g. "reviewed and approved" or "with the intent to be bound", may be signalled by the content being signed, e.g. the signed document itself or some additional signed information. That sounds like the sole purpose of the CC-bit is as a flag to indicate when some other bits somewhere else tell you what the CC-bit means. So in the absence of some better text I think that 3280bis is better off just saying "NR a.k.a. CC" as it currently does. Regards, Stephen. > > At 14:49 +0100 5/26/05, Stephen Farrell wrote: > >>Denis, >> >> >>>Please align with the the ISO-ITU text. >> >>Do you mean we should rename the bits and include the >>other new x.509 text? The design team were against >>doing that. >> >>Is there any (good) reason other than alignment to >>make such a change? >> >>Personally, I find the new x.509 text worse, although >>it does say: "Note that it is not incorrect to refer to >>this keyUsage bit using the identifier nonRepudiation." >>So I can argue that we are aligned, just not identical. >> >>But of course, I'm from the non-repudiation is non-sense >>camp so I may not be the best judge. >> >>Stephen. >> >>PS: A quibble: >> >> >>> The new text in X.509 aligns with the text in RFC 3280. No changes >>> are required to 3280bis. A comment has been added to the ASN.1 for >>> KeyUsage stating that "recent editions of X.509 have renamed >>> [the nonRepudiation] bit to contentCommitment" >>> >>>This statement is untrue. >> >>The paragraph to which I assume you refer contains 3 >>statements - it'd be easier to close these threads if >>you were more precise. (I think I got what you want >>by the end of the mail though...) >> >>PPS: "This statement is untrue." >> Are you from Crete after all? :-) >> >> >> >> >>Denis Pinkas wrote: >> >> >>>To the list, >>> >>>The disposition of comments states: >>> >>>13) The descriptions of the meanings of the digitalSignature and >>> nonRepudiation bits of keyUsage may need to be adjusted based >>> on the work in X.509 >>> >>> The new text in X.509 aligns with the text in RFC 3280. No changes >>> are required to 3280bis. A comment has been added to the ASN.1 for >>> KeyUsage stating that "recent editions of X.509 have renamed >>> [the nonRepudiation] bit to contentCommitment" >>> >>>This statement is untrue. >>> >>>The text from X.509 has been published in Corrigendum 3 (04/2004) >>>on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >>> >>>ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >>> >>>An extract from this text is copied below: >>> >>>a) digitalSignature: for verifying digital signatures that are used >>> with an entity authentication service, a data origin authentication >>> service or/and an integrity service; >>> >>>b) contentCommitment: for verifying digital signatures which are intended >>> to signal that the signer is committing to the content being signed. >>> The type of commitment the certificate can be used to support may be >>> further constrained by the CA, e.g. through a certificate policy. >>> The precise type of commitment of the signer e.g. "reviewed and >>> approved" or "with the intent to be bound", may be signalled by the >>> content being signed, e.g. the signed document itself or some additional >>> signed information. >>> >>> Since a content commitment signing is considered to be a digitally signed >>> transaction, the digitalSignature bit need not be set in the certificate. >>> If it is set, it does not affect the level of commitment the signer has >>> endowed in the signed content. >>> >>> Note that it is not incorrect to refer to this keyUsage bit using the >>> identifier nonRepudiation. However, the use of this identifier has been >>> deprecated. Regardless of the identifier used, the semantics of this bit >>> are as specified in this Directory Specification. >>> >>>The text from 3280 is copied below: >>> >>> The digitalSignature bit is asserted when the subject public key >>> is used with a digital signature mechanism to support security >>> services other than certificate signing (bit 5), or CRL signing >>> (bit 6). Digital signature mechanisms are often used for entity >>> authentication and data origin authentication with integrity. >>> >>> The nonRepudiation bit is asserted when the subject public key is >>> used to verify digital signatures used to provide a non- >>> repudiation service which protects against the signing entity >>> falsely denying some action, excluding certificate or CRL signing. >>> In the case of later conflict, a reliable third party may >>> determine the authenticity of the signed data. >>> >>> Further distinctions between the digitalSignature and >>> nonRepudiation bits may be provided in specific certificate >>> policies. >>> >>>The text from 3280bis does not align with the ISO-ITU text. >>>Please align with the the ISO-ITU text. >>> >>>Denis > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R2tB6X088348; Thu, 26 May 2005 19:55:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4R2tBYa088347; Thu, 26 May 2005 19:55:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R2t9Eb088340 for ; Thu, 26 May 2005 19:55:09 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4R2t1qY019770 for ; Thu, 26 May 2005 22:55:01 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4R2t1bY154244 for ; Thu, 26 May 2005 22:55:01 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4R2t1Hq015807 for ; Thu, 26 May 2005 22:55:01 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4R2t18X015801; Thu, 26 May 2005 22:55:01 -0400 In-Reply-To: <00a001c561ea$2c8b37d0$aa02a8c0@hq.orionsec.com> To: "Santosh Chokhani" Cc: ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Thu, 26 May 2005 22:54:56 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/26/2005 22:55:00, Serialize complete at 05/26/2005 22:55:01, Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/26/2005 22:55:01 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh: That is indeed the scenario. I'm glad to hear that both your library and Stefan's do reject paths like this. I didn't say that no one does or understands these things, just that I doubted that people who hadn't implemented a library did (you ran into an infinite loop in this case while testing, which suggests that it hadn't been fully understood before that). If any implementor interpreted 6.1.3-a-3's "not revoked and not on hold status" to not reject cases where his code could not determine the status, they could easily accept this path. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/26/2005 07:57 AM To: cc: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, BTW, we may be putting Peter Guttman and rest of the group to sleep again, which may not be all bad. You need to provide a clear streamlined scenario. From what I discern, you are saying the following. Root R --> C C --> C1 as CRL issuer & C --> S and C asserts in S C1. C1 issues CRL. S goes rouge. C instructs C1 to put S on CRLgood. S --> C1. Now, the new C1 can issue a CRLbad without S on it. In order to verify signature on CRLbad, you need the path R --> C --> S --> C1. But, note that in order to verify signature on C --> S either you will find the correct path and CRL (R --> C --> C1 and CRLgood) or you will have circularity since C-->S require C1 CRL. There is no sense in having this e-mail discussion unless you lay out the scenario precisely as above as to what the various certification paths are. So far, when I fill in the gaps, all I see is circularity issues or what Stefan calls infinite loops. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Wednesday, May 25, 2005 10:22 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: I thought that I had made that particular issue clear. The indirect CRL being retrieved governs C's certificates and its issuer name (call it C1) is supposed to belong to C. Indeed, C has issued a CRL signing certificate with subject name C1. However, S has created another CRL signing certificate with this same subject name and has created a CRL with that key pair. C did not create any circularity. The original certificate for C1 was issued by C and the corresponding private key belongs to an entity under C's control, while the new certificate for C1 was issued by S and the corresponding private key belongs to a malicious subsystem inside S. While certificates are issued to entities, relying parties know the name and the chain but not the entity. No relevant CRL is issued by S. I'm sure that your objection to ' looking at CRL issued by C' actually meant 'issued by S', because you normally verify certificates by looking at CRL's issued by the certificate issuer or its delegate. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/25/2005 08:58 AM To: cc: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, It is not clear from your example who the indirect CRL issuer is and what role the "indirect CRL" plays in the attack. If S is the indirect CRL issuer, C should be smart enough to not create circularity (a good toolkit will not verify path when C issues a certificate to S and points to S as the indirect CRL issuer since it causes circularity and chicken and egg problem). That scenario can be easily rectified within current standard by C not declaring S as the indirect CRL issuer for certificate issued to S. C can declare itself in the CDP or some other issuer. I suspect you do not mean this. Your example may be simpler. To me the attack is still not plausible. Your scenario is not detailed enough to illustrate an attack. It does not seem that there is a way to validate the certificate issued to C by S without looking at CRL issued by C, resulting in circularity, which relying party clients should not accept. (Note that my November presentation to IETF in DC covered the circularity issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to the CRL certification path) -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, May 25, 2005 7:50 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; 'Julien Stern' Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJGIYx070182; Thu, 26 May 2005 12:16:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJGI3K070181; Thu, 26 May 2005 12:16:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJGIQF070175 for ; Thu, 26 May 2005 12:16:18 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.3]) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DbNpv-00051y-6Q; Thu, 26 May 2005 15:16:07 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Subject:Cc:Content-Type; b=NikbAVUEYzDDoXbX40o4ddoDYMSPePGBd6Xnyrqh7S2qdVN357chAaWLno109VPA; Mime-Version: 1.0 Message-Id: In-Reply-To: <4295D3EB.5010800@cs.tcd.ie> References: <42959044.4070802@bull.net> <4295D3EB.5010800@cs.tcd.ie> Date: Thu, 26 May 2005 12:15:54 -0700 To: Stephen Farrell , Denis Pinkas From: Hoyt L Kesterson II Subject: Re: 3280bis: key usage (13) Cc: pkix Content-Type: text/plain; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d4781412bc4b56a17d4768d818cffbd49a3004b207c7cc29a54b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephen I am somewhat dismayed at your reaction to the new text in X.509. I am not going to argue with you here (maybe in a bar the next time we run into each other). However, I do want to mention several points. 1) I initiated the change in text because of the various interpretations by implementors that were resulting in non-interoperable implementations. It was a conversation with a PKIXer at a RSA conference a few years ago that caused me to articulate a private concern. 2) The legal community was very confused. There was even a paper castigating the standard developers for mandating that one could not repudiate an action. 3) There were several meetings held where there was significant participation by people in the IETF PKIX group (as well as lawyers). All agreed there was a problem with the published text. Denis and I argued long and hard over wording but we didn't disagree on the need for new text and its general intent. 4) Russ was concerned that change would cause a problem with existing IETF standards and was not too happy with a change to the name of the bit. That's why I put the line in that you referenced. However, that was to grandfather existing text, not to allow new text to continue using the old term and definitions. 5) It is the definition that is important. I recommend that any new text align with the definition in the approved technical corrigenda against the 4th edition and in the upcoming 5th edition. hoyt At 14:49 +0100 5/26/05, Stephen Farrell wrote: >Denis, > > > Please align with the the ISO-ITU text. > >Do you mean we should rename the bits and include the >other new x.509 text? The design team were against >doing that. > >Is there any (good) reason other than alignment to >make such a change? > >Personally, I find the new x.509 text worse, although >it does say: "Note that it is not incorrect to refer to >this keyUsage bit using the identifier nonRepudiation." >So I can argue that we are aligned, just not identical. > >But of course, I'm from the non-repudiation is non-sense >camp so I may not be the best judge. > >Stephen. > >PS: A quibble: > >> The new text in X.509 aligns with the text in RFC 3280. No changes >> are required to 3280bis. A comment has been added to the ASN.1 for >> KeyUsage stating that "recent editions of X.509 have renamed >> [the nonRepudiation] bit to contentCommitment" >> >> This statement is untrue. > >The paragraph to which I assume you refer contains 3 >statements - it'd be easier to close these threads if >you were more precise. (I think I got what you want >by the end of the mail though...) > >PPS: "This statement is untrue." > Are you from Crete after all? :-) > > > > >Denis Pinkas wrote: > >> >>To the list, >> >>The disposition of comments states: >> >> 13) The descriptions of the meanings of the digitalSignature and >> nonRepudiation bits of keyUsage may need to be adjusted based >> on the work in X.509 >> >> The new text in X.509 aligns with the text in RFC 3280. No changes >> are required to 3280bis. A comment has been added to the ASN.1 for >> KeyUsage stating that "recent editions of X.509 have renamed >> [the nonRepudiation] bit to contentCommitment" >> >>This statement is untrue. >> >>The text from X.509 has been published in Corrigendum 3 (04/2004) >>on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called >> >>ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). >> >>An extract from this text is copied below: >> >>a) digitalSignature: for verifying digital signatures that are used >> with an entity authentication service, a data origin authentication >> service or/and an integrity service; >> >>b) contentCommitment: for verifying digital signatures which are intended >> to signal that the signer is committing to the content being signed. >> The type of commitment the certificate can be used to support may be >> further constrained by the CA, e.g. through a certificate policy. >> The precise type of commitment of the signer e.g. "reviewed and >> approved" or "with the intent to be bound", may be signalled by the >> content being signed, e.g. the signed document itself or some additional >> signed information. >> >> Since a content commitment signing is considered to be a digitally signed >> transaction, the digitalSignature bit need not be set in the certificate. >> If it is set, it does not affect the level of commitment the signer has >> endowed in the signed content. >> >> Note that it is not incorrect to refer to this keyUsage bit using the >> identifier nonRepudiation. However, the use of this identifier has been >> deprecated. Regardless of the identifier used, the semantics of this bit >> are as specified in this Directory Specification. >> >>The text from 3280 is copied below: >> >> The digitalSignature bit is asserted when the subject public key >> is used with a digital signature mechanism to support security >> services other than certificate signing (bit 5), or CRL signing >> (bit 6). Digital signature mechanisms are often used for entity >> authentication and data origin authentication with integrity. >> >> The nonRepudiation bit is asserted when the subject public key is >> used to verify digital signatures used to provide a non- >> repudiation service which protects against the signing entity >> falsely denying some action, excluding certificate or CRL signing. >> In the case of later conflict, a reliable third party may >> determine the authenticity of the signed data. >> >> Further distinctions between the digitalSignature and >> nonRepudiation bits may be provided in specific certificate >> policies. >> >>The text from 3280bis does not align with the ISO-ITU text. >>Please align with the the ISO-ITU text. >> >>Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QItTtb067863; Thu, 26 May 2005 11:55:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QItTqw067861; Thu, 26 May 2005 11:55:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QItRfb067761 for ; Thu, 26 May 2005 11:55:28 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 May 2005 19:55:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Thu, 26 May 2005 19:55:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Thread-Index: AcVhmdJGXS/B7joaTFqHyqHHyaiPzQAic0dg From: "Stefan Santesson" To: "Tom Gindin" Cc: "Santosh Chokhani" , , "Julien Stern" X-OriginalArrivalTime: 26 May 2005 18:55:22.0014 (UTC) FILETIME=[77EAABE0:01C56224] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QItSfb067839 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, Just Speaking as implementer, MS CAPI will quit and fail the validation once it detects a loop like this one. This is also true for indirect loops such as if https access to the CRL requires the target cert to be established. Such CDP will also be regarded as invalid. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com] > Sent: den 25 maj 2005 19:22 > To: Stefan Santesson > Cc: Santosh Chokhani; ietf-pkix@imc.org; Julien Stern > Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > Stefan: > > I can't find any loop control text on this subject in 3280 or > 3280-bis. I don't know what a practical validation library would do with > a potential loop like this, and I doubt if anybody who hasn't written such > a library knows either. One of the things it might do is note that the > certificate is already being validated and assume that its validation > result is sufficient. That avoids the loop, at the cost of letting this > certificate through. Being sure that the library will encounter a loop > depends on the library's author interpreting "Obtain and validate the > certification path for the complete CRL issuer" to include calling a > revocation check on each element in the path and not assuming that a bad > certificate already being validated once will be caught elsewhere in the > algorithm. > On a related issue, the certpathbuild I-D may be just as involved > in our discussions as 3280-bis. Its security considerations section on > CRL signer paths is considerably more elaborate than 3280's discussion, > and does not consider that terminating at the same trust anchor is good > enough. > > Tom Gindin > > > > > > > "Stefan Santesson" > 05/25/2005 02:17 PM > > To: Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" > > cc: , "Julien Stern" > > Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > If the substitution would be successful the validation would go into an > infinite loop and fail. > Validation of S's fake CRL requires validation of C's cross certificate > to S which triggers another validation of S's fake CRL and so on. > > I think we added some text against infinite loops but I don't have it > fresh in my memory. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Tom Gindin > > Sent: den 25 maj 2005 04:50 > > To: Santosh Chokhani > > Cc: ietf-pkix@imc.org; 'Julien Stern' > > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > > > > Santosh: > > > > A relatively concrete example would be the following: > > Assume a trust anchor called A, and CA it has issued a cross > > certificate to called C. Further assume that C uses indirect CRL's, > and > > has issued a cross certificate without name constraints to another CA > > called S. Then assume that S goes rogue and creates a CRL signing > > certificate with the same name as C uses for its indirect CRL's (the > key > > pair in that certificate is hereinafter called the "rogue CRL > signer"). > > Further assume that C finds out about this and creates a CRL listing S > as > > revoked, but that S successfully replaces that CRL in the repository > by > > one signed by the rogue CRL signer. > > Does RFC 3280 path validation consider S invalid? If so, > which > > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what > else > > would be likely to cause S to be recognized as invalid? You could > > probably patch any difficulties by adding "if the certificate whose > > revocation is being checked appears in the path, reject it" to > 6.3.3-f. > > > > Tom Gindin > > > > > > > > > > > > > > "Santosh Chokhani" > > 05/24/2005 06:42 PM > > > > To: Tom Gindin/Watson/IBM@IBMUS, > > cc: "'Julien Stern'" > > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > > extension) > > > > > > Tom, > > > > > > I assume you are talking about CRL certification path solution I > proposed > > will not permit the scenario? I still do not see in your case, if the > > Subject CA (cross certified CA) is revoked, you will verify the path > to it > > in the first place. May be I am not understanding your scenario > properly. > > How does the revoked CA gets verified? > > > > > > Julien, > > > > We have defined and proven the solution for how to do this. The > scenario > > you proposed is not something X.509 worries about (A CA that is still > > valid, > > but has gone bad). > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On > > Behalf Of Julien Stern > > Sent: Tuesday, May 24, 2005 3:49 PM > > To: Stefan Santesson > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > > Tom and Julien, > > > > > > Since this is a repetition of the discussion we had before San Diego > > > and I don't want to repeat it here. I'm not saying that this > > > discussion is invalid; it is just directed towards the wrong draft. > > > > Stefan, > > > > I agree with you. Actually, I would tend to believe that a _real_ > > discussion > > would have to take place at some point regarding the overall security > > model > > of CRL validation, but I have absolutely no objection to the AIA, as > soon > > as > > it is made clear that it's only goal is to simplify path building > > implementations, and not to adress security issues. My very humble > take on > > the subject is that Denis and yourself have been arguing on the list > on > > absolutely valid but different matters. > > > > So, I chose not to comment expect for my last mail (and will not any > more) > > about AIA, but I still think that a discusssion regarding revocation > > validation should take place for RFC3280bis, eventually. > > > > Regards, > > > > -- > > Julien Stern > > > > > > > > As Tom pointed out: > > > > this fraudulently issued CRL will probably be validated whether it > > > > contains an AIA or not. > > > > > > This indicates once again that this is not an issue caused by the > use > > > of AIA in CRLs but a generic CRL validation issue that belongs with > > > RFC 3280bis and not with the CRL-AIA draft. > > > > > > Stefan Santesson > > > Program Manager, Standards Liaison > > > Windows Security > > > > > > > > > > -----Original Message----- > > > > From: owner-ietf-pkix@mail.imc.org > > > [mailto:owner-ietf-pkix@mail.imc.org] > > > > On Behalf Of Julien Stern > > > > Sent: den 24 maj 2005 09:39 > > > > To: Tom Gindin > > > > Cc: ietf-pkix@imc.org > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > > > There is one scenario permitted by the "same trust > anchor" > > > rule > > > > > for CRL signers which seems to me to be a serious security hole. > > > Let us > > > > > assume a valid CA which is a direct subordinate of one of the > RP's > > > trust > > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > > usual > > > way, > > > > > and issues cross certificates. After months or years of > > > > > operation, > > > it > > > > > revokes one of its cross certificates because the subject's > > > > > operator > > > has > > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > > Signing certificate with the DN that the superior certificate > has > > > > > been using > > > to > > > > > sign ARL's, a public key which it has newly generated, and > various > > > > > extensions including an SKID. It then issues an updated copy of > > > > > an > > > old > > > > > ARL under the fraudulent CRL signer's certificate and with an > AKID > > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > > into > > > the > > > > > repository where the CRL is expected, this fraudulently issued > CRL > > > will > > > > > probably be validated whether it contains an AIA or not. It > will > > > > > certainly pass the "same trust anchor" condition. > > > > > This scenario, in which a rogue CA issues an ARL > > > > > certifiying > > > > that > > > > > its primary certificate has not been revoked and gets the ARL > > > accepted, > > > > is > > > > > possible under "same trust anchor" but not under "signed by path > > > > member". > > > > > > > > I agree with the validity of this scenario. I believe this is very > > > > close to the issue I attempted to bring on the list a short time > > > > ago. Of course, it assumes the existence of a rogue CA at some > point > > > > in > > > time. > > > > > > > > Note that the CRL could be directly inserted into a "long term" > > > > signature (according to RFC3126 for example). This does not > require > > > > a repository break-in and makes the "attack" even more realistic. > > > > > > > > Regards. > > > > > > > > -- > > > > Julien Stern > > > > > > > > > > > > > > Tom Gindin > > > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > > ----- > > > > > > > > > > > > > > > Tom Gindin > > > > > 05/23/2005 10:46 PM > > > > > > > > > > To: wpolk@nist.gov > > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > > kent@bbn.com, > > > > > stefans@microsoft.com > > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > > Tim: > > > > > > > > > > I should probably have brought this up earlier, but are > we > > > > certain > > > > > that "same trust anchor" is a strong enough check that the CRL > > > signer is > > > > > the one expected by the issuing CA? While I was not in San > Diego > > > when > > > > > this wording was included in the 3280 series, I do not really > > > > > think > > > that > > > > > that check is strong enough. I would suggest instead that the > CRL > > > > > signer's certificate needs to be directly issued by one of the > > > > > CA's > > > in > > > > the > > > > > certification path back to the trust anchor used for the > > > certificate's > > > > > verification, or by that anchor itself, unless people have > > > > > practical experience with CA structures which that rule would > > > > > prohibit. > > > Forcing > > > > the > > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > > by > > > a > > > > > hierarchical superior, so it is IMHO too strict. > > > > > I am personally not sure, FWIW, that a CRL should be > > > permitted > > > > to > > > > > be signed by a second-cousin certificate of the issuer's > > > certificate. > > > > By > > > > > analogy to the use of the terms in families, "sibling" > > > > > certificates > > > > would > > > > > have the same issuer, "first-cousin" certificates would be > issued > > > > > by siblings, and "second-cousin" certificates would be issued by > > > > > first cousins - so they are both three levels down from the same > > > > > trust > > > anchor, > > > > > or from the last common CA in their paths. This issue is not > > > > > newly > > > > caused > > > > > by CRL AIA, since the same issue can arise with CRL's containing > > > only > > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > > wrong) > > > > more > > > > > quickly. > > > > > In any case, nothing more than a note in Security > > > Considerations > > > > > is appropriate in any of our RFC's other than 3280 and its > > > successor. > > > > > > > > > > Tom Gindin > > > > > P.S. - The above views are mine, and not necessarily those of > my > > > > employer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > > 05/10/2005 05:27 PM > > > > > > > > > > To: ietf-pkix@imc.org > > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > > housley@vigilsec.com > > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > > specification "Internet X.509 Public Key Infrastructure: > Authority > > > > > Information > > > Access > > > > > CRL > > > > > Extension". While some issues raised in the working group are > > > > unresolved, > > > > > > > > > > the editors believe that rough consensus supports the current > > > > > specification. > > > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > > will > > > not > > > > > close before May 24. > > > > > > > > > > Thanks, > > > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGenFY033610; Thu, 26 May 2005 09:40:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGenwE033609; Thu, 26 May 2005 09:40:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGemcM033602 for ; Thu, 26 May 2005 09:40:48 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4QGea8e030549; Thu, 26 May 2005 12:40:38 -0400 From: "Santosh Chokhani" To: "'pgut001'" , , , Cc: , , , , , Subject: RE: Comments on / suggested changes for RFC3280bis Date: Thu, 26 May 2005 12:40:31 -0400 Message-ID: <001201c56211$a4c531c0$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QGencM033603 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Guttman, The KIDs are there for us to have fun. No just kidding. They are there for performance enhancement during certification path development and should play no role in path validation. -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Thursday, May 26, 2005 12:27 PM To: david.cooper@nist.gov; ietf-pkix@imc.org; pmhesse@geminisecurity.com Cc: chokhani@orionsec.com; GSecrest@CORUS.JNJ.com; guy@strategicidentitygroup.com; mcooper@orionsec.com; MRamos8@CORUS.JNJ.com; RGuida@CORUS.JNJ.com; Terry.Zagar@ngc.com Subject: Re: Comments on / suggested changes for RFC3280bis "Peter Hesse" writes: >Location: 4.2.1.2, 2nd para, last sentence >Original Text: "Applications are not required to verify that key >identifiers match when performing certification path validation." >Recommendation: "Applications SHOULD NOT verify that key identifiers >match when performing certification path validation." >Reason: Key identifier matching is not part of determining whether or >not a certification path is valid. I hate to be the guy who always has to ask the blindingly obvious questions, but if they're not required and SHOULD NOT be used, why are they there in the first place? (I know the answer to this question, but I'm interested in seeing what responses are provided). Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGRIA6032645; Thu, 26 May 2005 09:27:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGRIoi032644; Thu, 26 May 2005 09:27:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGRHgA032638 for ; Thu, 26 May 2005 09:27:17 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id D7F9D340A7; Fri, 27 May 2005 04:27:16 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29539-25; Fri, 27 May 2005 04:27:16 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 1B95F3482D; Fri, 27 May 2005 04:27:13 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6BBB33774F; Fri, 27 May 2005 04:27:13 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DbLCd-0007nR-00; Fri, 27 May 2005 04:27:23 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: david.cooper@nist.gov, ietf-pkix@imc.org, pmhesse@geminisecurity.com Subject: Re: Comments on / suggested changes for RFC3280bis Cc: chokhani@orionsec.com, GSecrest@CORUS.JNJ.com, guy@strategicidentitygroup.com, mcooper@orionsec.com, MRamos8@CORUS.JNJ.com, RGuida@CORUS.JNJ.com, Terry.Zagar@ngc.com In-Reply-To: <20050526151420.13819114175@nelson.textdrive.com> Message-Id: Date: Fri, 27 May 2005 04:27:23 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Peter Hesse" writes: >Location: 4.2.1.2, 2nd para, last sentence >Original Text: "Applications are not required to verify that key identifiers >match when performing certification path validation." >Recommendation: "Applications SHOULD NOT verify that key identifiers match >when performing certification path validation." >Reason: Key identifier matching is not part of determining whether or not a >certification path is valid. I hate to be the guy who always has to ask the blindingly obvious questions, but if they're not required and SHOULD NOT be used, why are they there in the first place? (I know the answer to this question, but I'm interested in seeing what responses are provided). Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGMv3v030651; Thu, 26 May 2005 09:22:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGMv52030650; Thu, 26 May 2005 09:22:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QGMu9Y030632 for ; Thu, 26 May 2005 09:22:57 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 13943 invoked by uid 0); 26 May 2005 16:22:31 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.127.10) by woodstock.binhost.com with SMTP; 26 May 2005 16:22:31 -0000 Message-Id: <6.2.1.2.2.20050526122036.06aa4d50@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 26 May 2005 12:22:30 -0400 To: pgut001@cs.auckland.ac.nz From: Russ Housley Subject: Re: [draft-ietf-pkix-sim-04.txt] Cc: ietf-pkix@imc.org In-Reply-To: References: <6.2.1.2.2.20050526095809.05835eb0@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter: SFL uses enhanced SNACC, which is freeware and it only supports the 1988 syntax. I do not think it is laziness. However, I am not going to be dragged down that rat hole. Russ At 10:34 AM 5/26/2005, Peter Gutmann wrote: >Russ Housley writes: > > >It is not fair to abuse new authors for following long-standing PKIX and > >S/MIME WG convention. These WGs have chosen to use the 1988 ASN.1 syntax > >because there are free tools that support it. If you have information > about > >freeware tools that support the later syntax, please let us know. > >These WGs have chosen to use the obsolete 1988 ASN.1 syntax because they >couldn't be bothered learning anything newer. The (un)availability of >freeware tools is merely the most convenient red herring available to support >this position. I'n not aware of a single OSS/freeware project that is >hampered by the unavailability of freeware ASN.1 tools (the only project of >this kind that I know of that even uses one is SFL, and that doesn't seem to >have any problems). > >Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QFEN6x019844; Thu, 26 May 2005 08:14:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QFENbD019843; Thu, 26 May 2005 08:14:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nelson.textdrive.com (nelson.textdrive.com [70.85.91.228]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QFELVP019835 for ; Thu, 26 May 2005 08:14:21 -0700 (PDT) (envelope-from pmhesse@geminisecurity.com) Received: from geminiph (unknown [70.21.21.141]) by nelson.textdrive.com (Postfix) with ESMTP id 13819114175; Thu, 26 May 2005 15:14:20 +0000 (GMT) From: "Peter Hesse" To: , "'David A. Cooper'" Cc: , , , , "'Zagar, Terry (Mission Systems)'" , "'Guy Tallent [SIG] (E-mail)'" , "'Gary Secrest [JJCUS] (E-mail)'" Subject: Comments on / suggested changes for RFC3280bis Date: Thu, 26 May 2005 11:14:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcVX1K4llWiL9DePTeCFxe3k0UJfvQKIX8gwAADGGJAAAGWhkAACmAwg In-Reply-To: <232C3D7FF15B854084DB58733FFD624101FFF1A7@XCGV4806.northgrum.com> Message-Id: <20050526151420.13819114175@nelson.textdrive.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: PKIX list and RFC3280bis editors, I apologize in advance for the length of this message. Below are comments on the RFC3280bis draft developed on behalf of Gemini Security and the SAFE-Biopharma Association. The SAFE-Biopharma Association's mission is to deliver unique electronic identity credentials for strong authentication and for the application of digital signatures for use in electronic systems and transactions across the bio-pharmaceutical industry. The SAFE-Biopharma Association manages the SAFE digital signature standard and associated operating policies for its Members, which include the world's leading biopharmaceutical companies, their business partners, and regulatory agencies. This message contains specific comments on and suggested changes to the RFC3280bis draft. For the most part these changes are meant to clarify and normalize the language used to specify required behavior of certificate processing systems and CAs/CRL issuers. Some additional changes are requested and reasons for them are also given. A real-world example of the unclear language related to behavior causing a problem: RFC3280 specified that the inhibitAnyPolicy extension be marked critical. At least one version of the Sun Java CertPath implementation rejects any certification paths containing inhibitAnyPolicy extensions which are not marked critical. The wording in RFC3280 was not clear that this was a requirement for issuers and not for implementations. (This issue has been fixed the current RFC3280bis draft, but remains in other places for other extensions.) I will also be providing these changes in a Word document with tracked changes to David Cooper for his use in developing the next draft. See below for the actual comments. I appreciate your willingness to consider these changes for the next draft. Sincerely, Peter Hesse ------------------------------------------------ Location: 3.3, 4th para, 6th line Original Text: "all currently issued CRLs are updated" Recommendation: "all currently issued CRLs are scheduled to be updated". Reason: Whether or not the CRL is updated doesn't affect notification, it is whether a scheduled update (specified in nextUpdate) was due to occur. Location: 4.2, 2nd para, last sentence Original Text: "The text for each extension specifies the acceptable values for the critical field." Recommendation: "The text for each extension specifies the acceptable values for conforming CAs and CRL Issuers to place in the critical field. Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.1, 5th para Original Text: "This extension MUST NOT be marked critical." Recommendation: "Conforming CAs MUST mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.2, 2nd para, last sentence Original Text: "Applications are not required to verify that key identifiers match when performing certification path validation." Recommendation: "Applications SHOULD NOT verify that key identifiers match when performing certification path validation." Reason: Key identifier matching is not part of determining whether or not a certification path is valid. Location: 4.2.1.2, next-to-last para Original Text: "This extension MUST NOT be marked critical." Recommendation:" Conforming CAs MUST mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.3, 2nd para, last sentence Original Text: "When this extension appears, it SHOULD be marked critical." Recommendation: "When this extension appears, conforming CAs SHOULD mark it critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.4, 3rd para, last sentence Original Text: "If this extension is critical, the path validation software MUST be able to interpret this extension (including the optional qualifier), or MUST reject the certificate." Comment: This sentence seems like an unnecessary repetition of the behavior required on all extensions, specified in the first para of 4.2. I recommend this sentence be removed. Location: 4.2.1.5, 5th para Original Text: "This extension MAY be supported by CAs and/or applications, and it SHOULD be critical." Recommendation: "This extension MAY be supported by CAs and/or applications, and conforming CAs SHOULD mark this extension critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.6, 3rd para, last sentence Original Text: "If the subject field contains an empty sequence, the subjectAltName extension MUST be marked critical." Recommendation: Add the following sentence. "Otherwise, conforming CAs SHOULD mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.7, 2nd para Original Text: "Where present, this extension SHOULD NOT be marked critical." Recommendation: "Where present, conforming CAs SHOULD mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.9, 4th para, 1st sentence Original Text: "This extension MUST appear in all CA certificates that contain public keys used to validate digital signatures on certificates." Recommendation: "Conforming CAs must place this extension in all CA certificates that contain public keys used to validate digital signatures on certificates." Reason: This statement is in conflict with the statement "verify that certificate i is a CA certificate through out-of-band means" in section 6.1.4. Location: 4.2.1.9, 4th para, 3rd sentence Original Text: "This extension MAY appear as a critical or non-critical extension in CA certificates that contain public keys..." Recommendation: "Conforming CAs MAY mark this extension as critical or non-critical in CA certificates that contain public keys..." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.9, 4th para, last sentence Original Text: "This extension MAY appear as a critical or non-critical extension in end entity certificates." Recommendation: "Conforming CAs MAY mark this extension as critical or non-critical in end entity certificates." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.11, 4th para, last sentence Original Text: "If the policyConstraints extension is marked critical and the inhibitPolicyMapping field is present, applications that do not implement support for the inhibitPolicyMapping field MUST reject the certificate." Comment: This seems to be encouraging different behavior depending on the criticality of the field, which goes against the spirit of extension processing. Location: 4.2.1.12, 6th para Original Text: "This extension MAY, at the option of the certificate issuer, be either critical or non-critical." Recommendation: "Conforming CAs MAY mark this extension either critical or non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) & normalization of text Location: 4.2.1.12, 8th para Original Text: "If the anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT be critical." Recommendation: "If the anyExtendedKeyUsage keyPurposeID is present, conforming CAs SHOULD NOT mark this extension critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 1st para, 2nd sentence Original Text: "The extension SHOULD be non-critical," Recommendation: "Conforming CAs SHOULD mark this extension non-critical," Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 2nd para, 4th sentence Original Text: "...not the CRL issuer, then the cRLIssuer field MUST be present and contain the Name of the CRL issuer." Recommendation: "...not the CRL issuer, then conforming CAs MUST include the cRLIssuer field containing the Name of the CRL issuer." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 2nd para, 5th sentence Original Text: "...is also the CRL issuer, then the cRLIssuer field MUST be omitted and the distributionPoint field MUST be present." Recommendation: "...is also the CRL issuer, then conforming CAs MUST omit the cRLIssuer field and MUST include the distributionPoint field." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 2nd para, last sentence Original Text: "If the distributionPoint field is omitted, cRLIssuer MUST be present and include a Name..." Recommendation: "If the distributionPoint field is omitted, conforming CAs MUST include the cRLIssuer field and include a Name..." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 4.2.1.13, 5th para, last sentence Original Text: "DistributionPointName SHOULD include at least one LDAP or HTTP URI." Recommendation: Add the following sentence. "If both HTTP and LDAP DistributionPointName URI values are specified, the HTTP DistributionPointName SHOULD appear first." Reason: Firewalls are more likely to allow HTTP through, and HTTP typically results in faster access. Applications typically try distribution points in the order in which they appear. Location: 4.2.2.1, 13th para, 2nd sentence Original Text: "...and MAY specify a host name (e.g., ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina ry,crossCertificatePair;binary). Recommendation: remove ",crossCertificatePair;binary" from the example Reason: Attributes containing cross-certificate pairs should not be recommended. There is no way for the client to know whether or not they will be encountering cross-certificate pairs as opposed to certificates, without attempting to decode them and failing. Retrieving only cACertificate attribute should be sufficient if LDAPv3 schema is being followed. Location: 4.2.2.1, 13th para, last sentence Original Text: "The URI MUST list appropriate attribute descriptions for one or more attributes holding DER [X.690] encoded certificates or cross-certificate pairs." Recommendation: remove "or cross-certificate pairs" Reason: Same as above (4.2.2.1, 13th para, 2nd sentence). Location: 4.2.2.1, 16th para Original Text: " .p7c A DER encoded "certs-only" CMS message as specified in [RFC 2797]." Recommendation: " .p7c A DER encoded "certs-only" CMS message as specified in [RFC 2797] which MUST NOT contain self-signed certificates." Reason: Self-signed certificates retrieved externally should not be included because they cannot be trusted, Location: 4.2.2.1, 18th para Original Text: "The semantics of other id-ad-caIssuers accessLocation name forms are not defined." Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP accessLocations are specified, the HTTP accessLocation SHOULD appear first." Reason: Same as above (4.2.1.13, 5th para, last sentence). Location: 4.2.2.2, 9th para, 2nd sentence Original Text: "...and MAY specify a host name (e.g., ldap://ldap.example.com/cn=example%20CA,dc=example,dc=com?cACertificate;bina ry,crossCertificatePair;binary). Recommendation: remove ",crossCertificatePair;binary" from the example Reason: Same as above (4.2.2.1, 13th para, 2nd sentence). Location: 4.2.2.2, 9th para, last sentence Original Text: "The URI MUST list appropriate attribute descriptions for one or more attributes holding DER [X.690] encoded certificates or cross-certificate pairs." Recommendation: remove "or cross-certificate pairs" Reason: Same as above (4.2.2.1, 13th para, 2nd sentence). Location: 4.2.2.2, 12th para Original Text: " .p7c A DER encoded "certs-only" CMS message as specified in [RFC 2797]." Recommendation: " .p7c A DER encoded "certs-only" CMS message as specified in [RFC 2797] which MUST NOT contain self-signed certificates." Reason: Self-signed certificates retrieved externally should not be included because they cannot be trusted, Location: 4.2.2.2, 14th para Original Text: "The semantics of other id-ad-caRepository accessLocation name forms are not defined." Recommendation: Add a new paragraph before this one: "If both HTTP and LDAP accessLocations are specified, the HTTP accessLocation SHOULD appear first." Reason: Same as above (4.2.1.13, 5th para, last sentence). Location: 5.1.2.5, 2nd para, 1st sentence Original Text: "This profile requires inclusion of nextUpdate in all CRLs issued by conforming CRL issuers." Recommendation: "Conforming CRL issuers MUST include the nextUpdate field in all CRLs." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) & normalization of text Location: 5.2.2, 2nd para Original Text: "The issuerAltName extension SHOULD NOT be marked critical." Recommendation: "Conforming CRL issuers SHOULD NOT mark the issuerAltName extension critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.2.3, 1st para Original Text: "The CRL number is a non-critical CRL extension which...MUST include this extension in all CRLs." Recommendation: "The CRL number is a CRL extension which...MUST include this extension in all CRLs and MUST mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) & normalization of text Location: 5.2.4, 1st para Original Text: "The delta CRL indicator is a critical CRL extension that...the local database without reprocessing information." Recommendation: "The delta CRL indicator is a CRL extension that...the local database without reprocessing information. Conforming CRL issuers MUST mark the delta CRL indicator extension critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) & normalization of text Location: 5.2.5, 1st para, 2nd sentence Original Text: "Although the extension is critical, conforming implementations are not required to support this extension." Recommendation: "Conforming CRL Issuers MUST mark this extension critical, but conforming implementations are not required to support this extension." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.2.6, 1st para, 2nd sentence Original Text: "The extension MUST be non-critical." Recommendation: "Conforming CRL issuers must mark this extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.3.1, 1st para, 1st sentence Original Text: "The reasonCode is a non-critical CRL entry extension that identifies the reason for the certificate revocation." Recommendation: "The reasonCode is a CRL entry extension that identifies the reason for the certificate revocation. Conforming CRL issuers MUST mark this entry extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.3.2, 1st para Original Text: "The hold instruction code is a non-critical CRL entry extension that...placed on hold." Recommendation: "The hold instruction code is a CRL entry extension that...placed on hold. Conforming CRL issuers MUST mark this entry extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.3.3, 1st para Original Text: "The invalidity date is a non-critical CRL entry extension that...to share it with CRL users." Recommendation: "The invalidity date is a CRL entry extension that...to share it with CRL users. Conforming CRL issuers MUST mark this entry extension non-critical." Reason: Clarification of behavior (CA/CRL Issuer vs. processing system) Location: 5.3.4, 5th para, 1st sentence Original Text: "If used by conforming CRL issuers, this extension MUST always be critical." Recommendation: "If used by conforming CRL issuers, this extension MUST be marked critical." Reason: Normalization of text Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QEY8XL014022; Thu, 26 May 2005 07:34:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QEY81g014021; Thu, 26 May 2005 07:34:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QEY7GR014003 for ; Thu, 26 May 2005 07:34:07 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 565293464D; Fri, 27 May 2005 02:34:06 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08975-10; Fri, 27 May 2005 02:34:06 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 60AA934500; Fri, 27 May 2005 02:34:04 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 0EB9737750; Fri, 27 May 2005 02:34:04 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DbJR7-0007jz-00; Fri, 27 May 2005 02:34:13 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: andrewsciberras@gmail.com, housley@vigilsec.com, Olivier.Dubuisson@francetelecom.com Subject: Re: [draft-ietf-pkix-sim-04.txt] Cc: ietf-pkix@imc.org, jhyoon@kisa.or.kr In-Reply-To: <6.2.1.2.2.20050526095809.05835eb0@mail.binhost.com> Message-Id: Date: Fri, 27 May 2005 02:34:13 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >It is not fair to abuse new authors for following long-standing PKIX and >S/MIME WG convention. These WGs have chosen to use the 1988 ASN.1 syntax >because there are free tools that support it. If you have information about >freeware tools that support the later syntax, please let us know. These WGs have chosen to use the obsolete 1988 ASN.1 syntax because they couldn't be bothered learning anything newer. The (un)availability of freeware tools is merely the most convenient red herring available to support this position. I'n not aware of a single OSS/freeware project that is hampered by the unavailability of freeware ASN.1 tools (the only project of this kind that I know of that even uses one is SFL, and that doesn't seem to have any problems). Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QE1oVs004130; Thu, 26 May 2005 07:01:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QE1oUw004129; Thu, 26 May 2005 07:01:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QE1mW2004121 for ; Thu, 26 May 2005 07:01:48 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 3429 invoked by uid 0); 26 May 2005 14:01:14 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.12.30) by woodstock.binhost.com with SMTP; 26 May 2005 14:01:14 -0000 Message-Id: <6.2.1.2.2.20050526095809.05835eb0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 26 May 2005 10:01:14 -0400 To: Olivier Dubuisson , Andrew Sciberras From: Russ Housley Subject: Re: [draft-ietf-pkix-sim-04.txt] Cc: Jaeho Yoon , ietf-pkix@imc.org In-Reply-To: <4295727D.1020100@francetelecom.com> References: <001501c56188$964f40b0$720710ac@5434d1> <42952E61.4020601@gmail.com> <4295727D.1020100@francetelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is not fair to abuse new authors for following long-standing PKIX and S/MIME WG convention. These WGs have chosen to use the 1988 ASN.1 syntax because there are free tools that support it. If you have information about freeware tools that support the later syntax, please let us know. Russ At 02:53 AM 5/26/2005, Olivier Dubuisson wrote: >Why redefine the UTF8String instead of using the one standardized in the >ASN.1 standard? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QDjcKa002532; Thu, 26 May 2005 06:45:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QDjcCE002531; Thu, 26 May 2005 06:45:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QDjYQo002520 for ; Thu, 26 May 2005 06:45:35 -0700 (PDT) (envelope-from stephen.farrell@cs.tcd.ie) Received: from Vams.smtp3 (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with SMTP id 8A60014C062; Thu, 26 May 2005 14:45:24 +0100 (IST) Received: from smtp3.tcd.ie ([134.226.1.158]) by smtp3.tcd.ie ([134.226.1.158]) with SMTP (gateway) id A07CCE6FB01; Thu, 26 May 2005 14:45:24 +0100 Received: from [134.226.36.26] (sfarrel2.dsg.cs.tcd.ie [134.226.36.26]) by smtp3.tcd.ie (Postfix) with ESMTP id 57F5814C062; Thu, 26 May 2005 14:45:24 +0100 (IST) Message-ID: <4295D3EB.5010800@cs.tcd.ie> Date: Thu, 26 May 2005 14:49:31 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Denis Pinkas Cc: pkix Subject: Re: 3280bis: key usage (13) References: <42959044.4070802@bull.net> In-Reply-To: <42959044.4070802@bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: Checked by TCD Vexira. (version=1.55.010 VDF=8.731) X-AntiVirus-Status: NONE X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: Host: smtp3.tcd.ie X-AntiVirus-Status: MessageID = A17CCE6FB01 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, > Please align with the the ISO-ITU text. Do you mean we should rename the bits and include the other new x.509 text? The design team were against doing that. Is there any (good) reason other than alignment to make such a change? Personally, I find the new x.509 text worse, although it does say: "Note that it is not incorrect to refer to this keyUsage bit using the identifier nonRepudiation." So I can argue that we are aligned, just not identical. But of course, I'm from the non-repudiation is non-sense camp so I may not be the best judge. Stephen. PS: A quibble: > The new text in X.509 aligns with the text in RFC 3280. No changes > are required to 3280bis. A comment has been added to the ASN.1 for > KeyUsage stating that "recent editions of X.509 have renamed > [the nonRepudiation] bit to contentCommitment" > > This statement is untrue. The paragraph to which I assume you refer contains 3 statements - it'd be easier to close these threads if you were more precise. (I think I got what you want by the end of the mail though...) PPS: "This statement is untrue." Are you from Crete after all? :-) Denis Pinkas wrote: > > To the list, > > The disposition of comments states: > > 13) The descriptions of the meanings of the digitalSignature and > nonRepudiation bits of keyUsage may need to be adjusted based > on the work in X.509 > > The new text in X.509 aligns with the text in RFC 3280. No changes > are required to 3280bis. A comment has been added to the ASN.1 for > KeyUsage stating that "recent editions of X.509 have renamed > [the nonRepudiation] bit to contentCommitment" > > This statement is untrue. > > The text from X.509 has been published in Corrigendum 3 (04/2004) > on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called > > ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). > > An extract from this text is copied below: > > a) digitalSignature: for verifying digital signatures that are used > with an entity authentication service, a data origin authentication > service or/and an integrity service; > > b) contentCommitment: for verifying digital signatures which are intended > to signal that the signer is committing to the content being signed. > The type of commitment the certificate can be used to support may be > further constrained by the CA, e.g. through a certificate policy. > The precise type of commitment of the signer e.g. "reviewed and > approved" or "with the intent to be bound", may be signalled by the > content being signed, e.g. the signed document itself or some additional > signed information. > > Since a content commitment signing is considered to be a digitally > signed > transaction, the digitalSignature bit need not be set in the > certificate. > If it is set, it does not affect the level of commitment the signer has > endowed in the signed content. > > Note that it is not incorrect to refer to this keyUsage bit using the > identifier nonRepudiation. However, the use of this identifier has been > deprecated. Regardless of the identifier used, the semantics of this bit > are as specified in this Directory Specification. > > The text from 3280 is copied below: > > The digitalSignature bit is asserted when the subject public key > is used with a digital signature mechanism to support security > services other than certificate signing (bit 5), or CRL signing > (bit 6). Digital signature mechanisms are often used for entity > authentication and data origin authentication with integrity. > > The nonRepudiation bit is asserted when the subject public key is > used to verify digital signatures used to provide a non- > repudiation service which protects against the signing entity > falsely denying some action, excluding certificate or CRL signing. > In the case of later conflict, a reliable third party may > determine the authenticity of the signed data. > > Further distinctions between the digitalSignature and > nonRepudiation bits may be provided in specific certificate > policies. > > The text from 3280bis does not align with the ISO-ITU text. > Please align with the the ISO-ITU text. > > Denis > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QC3bce071632; Thu, 26 May 2005 05:03:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QC3bsi071631; Thu, 26 May 2005 05:03:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QC3bFa071621 for ; Thu, 26 May 2005 05:03:37 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4QC3a8e026461 for ; Thu, 26 May 2005 08:03:36 -0400 From: "Santosh Chokhani" To: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Thu, 26 May 2005 08:03:26 -0400 Message-ID: <00a601c561ea$f12a2600$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QC3bFa071626 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom and Stefan, See below in [Santosh:] -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Wednesday, May 25, 2005 10:22 PM To: Stefan Santesson Cc: Santosh Chokhani; ietf-pkix@imc.org; Julien Stern Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Stefan: I can't find any loop control text on this subject in 3280 or 3280-bis. I don't know what a practical validation library would do with a potential loop like this, and I doubt if anybody who hasn't written such a library knows either. [Santosh: We at Orion has developed a library called PKIF for USMC that exactly does this. We found this circularity problem and our library went into neverland with infinite loop and we added loop control logic. So, saying that no one does or understands these things is dangerous and wrong in this case.] One of the things it might do is note that the certificate is already being validated and assume that its validation result is sufficient. That avoids the loop, at the cost of letting this certificate through. Being sure that the library will encounter a loop depends on the library's author interpreting "Obtain and validate the certification path for the complete CRL issuer" to include calling a revocation check on each element in the path and not assuming that a bad certificate already being validated once will be caught elsewhere in the algorithm. [Santosh: If I understand the above, be assured that X.509 requires that a CRL signature be verified using a public key that is fully validated per the X.509 certification path validation requirement, including revocation status checking of all the certificates in the CRL certification path] On a related issue, the certpathbuild I-D may be just as involved in our discussions as 3280-bis. Its security considerations section on CRL signer paths is considerably more elaborate than 3280's discussion, and does not consider that terminating at the same trust anchor is good enough. Tom Gindin "Stefan Santesson" 05/25/2005 02:17 PM To: Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" cc: , "Julien Stern" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, > cc: "'Julien Stern'" > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion would have to take place at some point regarding the > overall security model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBw8VD071226; Thu, 26 May 2005 04:58:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QBw8L6071225; Thu, 26 May 2005 04:58:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBw7rb071215 for ; Thu, 26 May 2005 04:58:08 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4QBw68e006635 for ; Thu, 26 May 2005 07:58:06 -0400 From: "Santosh Chokhani" To: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Thu, 26 May 2005 07:57:59 -0400 Message-ID: <00a001c561ea$2c8b37d0$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, BTW, we may be putting Peter Guttman and rest of the group to sleep again, which may not be all bad. You need to provide a clear streamlined scenario. From what I discern, you are saying the following. Root R --> C C --> C1 as CRL issuer & C --> S and C asserts in S C1. C1 issues CRL. S goes rouge. C instructs C1 to put S on CRLgood. S --> C1. Now, the new C1 can issue a CRLbad without S on it. In order to verify signature on CRLbad, you need the path R --> C --> S --> C1. But, note that in order to verify signature on C --> S either you will find the correct path and CRL (R --> C --> C1 and CRLgood) or you will have circularity since C-->S require C1 CRL. There is no sense in having this e-mail discussion unless you lay out the scenario precisely as above as to what the various certification paths are. So far, when I fill in the gaps, all I see is circularity issues or what Stefan calls infinite loops. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Tom Gindin Sent: Wednesday, May 25, 2005 10:22 PM To: Santosh Chokhani Cc: ietf-pkix@imc.org Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: I thought that I had made that particular issue clear. The indirect CRL being retrieved governs C's certificates and its issuer name (call it C1) is supposed to belong to C. Indeed, C has issued a CRL signing certificate with subject name C1. However, S has created another CRL signing certificate with this same subject name and has created a CRL with that key pair. C did not create any circularity. The original certificate for C1 was issued by C and the corresponding private key belongs to an entity under C's control, while the new certificate for C1 was issued by S and the corresponding private key belongs to a malicious subsystem inside S. While certificates are issued to entities, relying parties know the name and the chain but not the entity. No relevant CRL is issued by S. I'm sure that your objection to ' looking at CRL issued by C' actually meant 'issued by S', because you normally verify certificates by looking at CRL's issued by the certificate issuer or its delegate. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/25/2005 08:58 AM To: cc: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, It is not clear from your example who the indirect CRL issuer is and what role the "indirect CRL" plays in the attack. If S is the indirect CRL issuer, C should be smart enough to not create circularity (a good toolkit will not verify path when C issues a certificate to S and points to S as the indirect CRL issuer since it causes circularity and chicken and egg problem). That scenario can be easily rectified within current standard by C not declaring S as the indirect CRL issuer for certificate issued to S. C can declare itself in the CDP or some other issuer. I suspect you do not mean this. Your example may be simpler. To me the attack is still not plausible. Your scenario is not detailed enough to illustrate an attack. It does not seem that there is a way to validate the certificate issued to C by S without looking at CRL issued by C, resulting in circularity, which relying party clients should not accept. (Note that my November presentation to IETF in DC covered the circularity issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to the CRL certification path) -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, May 25, 2005 7:50 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; 'Julien Stern' Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q96k07032616; Thu, 26 May 2005 02:06:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q96k6m032615; Thu, 26 May 2005 02:06:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from outbound1.sopragroup.com (outbound1.z-ptx-11.fr.sopragroup.com [81.80.239.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q96j5N032608 for ; Thu, 26 May 2005 02:06:45 -0700 (PDT) (envelope-from aalberti@axway.com) Received: by outbound1.sopragroup.com (8.12.10/8.12.10/outbound-A02) with ESMTP id j4Q95KNg031948; Thu, 26 May 2005 11:05:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: 3280bis: CRL validation Date: Thu, 26 May 2005 11:00:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3280bis: CRL validation Thread-Index: AcVh0Glcm/QNTzxlS8u5gg6UddMuUgAAKgbw From: "Alberti Antoine" To: "Denis Pinkas" , "pkix" X-OriginalArrivalTime: 26 May 2005 09:09:13.0437 (UTC) FILETIME=[95CFB0D0:01C561D2] X-Scanned-By: MIMEDefang 2.38 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j4Q96k5N032610 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The fact that a cert is a trust anchor becomes very personal when using a cross-certified model: two parties are not supposed to have the same ones, but can still communicate. > -----Message d'origine----- > De : owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org]De la part de Denis Pinkas > Envoyé : jeudi 26 mai 2005 10:44 > À : pkix > Objet : 3280bis: CRL validation > > > > To the list, > > I changed the name of the thread which is now under 3280bis. > > As Tim mentioned: "it is clear that the current content of > 3280bis with > respect to CRL validation does not enjoy consensus within the > working group". > > Issues 33 and 43 are directly related to this topic. They are > both copied > below: > > 33) The certificateIssuer CRL entry extension contains a > GeneralNames. > While RFC 3280 does not state this, there seems to be general > agreement that > the certificateIssuer extension should only contain the DN > from the issuer > field of the certificate being revoked. > > 3280bis states: "Conforming CRL issuers MUST include in [the > certificateIssuer] extension the distinguished name (DN) from the > issuer field of the certificate that corresponds to this CRL entry. > The encoding of the DN MUST be identical to the encoding > used in the > certificate." > > > 43) It should be noted in 3280bis that there is a risk that > two different > CAs (or a CA and a CRL issuer) may issue certificates > and CRLs under > the same name and that if this happens there is a risk > that a relying > party will validate a certificate issued by one of > these entities > using a CRL issued by the other. > > The security considerations section of 3280bis states that > CAs and CRL > issuers should be formed in a way that reduces the > likelihood of name > collisions. It also states that implementations > validating CRLs MUST > ensure that the certification path of the target > certificate and the > CRL issuer certification path used to validate the target > certificate > terminate at the same trust anchor. > > Both statements are incorrect. > > For issue 43: name collisions are possible and a design > cannot be based on > the assumption that name collisions, whether accidental or > intentional, will > never happen. This means that chosing names to "reduce the > likehood of name > collisions" is not a way to solve the issue. Termination at > the same trust > anchor without additional details does not solve the issue either. > > For issue 33: the certificateIssuer extension is defined as : > > certificateIssuer ::= GeneralNames > > with > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > It is not defined as: > > certificateIssuer ::= GeneralName > > ... and this is NOT an error. > > To go directly to the point, certificateIssuer may contain in > practice either: > > - one name, or > - a sequence of names. > > If it contains one name, this means that this name MUST be > certified by the > CA that has issued the certificate where the extension appears. > > If it contains a sequence of names, this means that the > certification path > of the CRL issuer certificate formed using that sequence of > names MUST also > terminate at the trust anchor of the target certificate. > > This is secure and avoids any name collision, either > deliberate or intentional. > > Denis > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q8xxMs032103; Thu, 26 May 2005 01:59:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q8xxgM032102; Thu, 26 May 2005 01:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q8xvYJ032093 for ; Thu, 26 May 2005 01:59:58 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA22652 for ; Thu, 26 May 2005 11:15:01 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052610595055:1323 ; Thu, 26 May 2005 10:59:50 +0200 Message-ID: <42959044.4070802@bull.net> Date: Thu, 26 May 2005 11:00:52 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: pkix Subject: 3280bis: key usage (13) X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/05/2005 10:59:50, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/05/2005 10:59:52, Serialize complete at 26/05/2005 10:59:52 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To the list, The disposition of comments states: 13) The descriptions of the meanings of the digitalSignature and nonRepudiation bits of keyUsage may need to be adjusted based on the work in X.509 The new text in X.509 aligns with the text in RFC 3280. No changes are required to 3280bis. A comment has been added to the ASN.1 for KeyUsage stating that "recent editions of X.509 have renamed [the nonRepudiation] bit to contentCommitment" This statement is untrue. The text from X.509 has been published in Corrigendum 3 (04/2004) on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)). An extract from this text is copied below: a) digitalSignature: for verifying digital signatures that are used with an entity authentication service, a data origin authentication service or/and an integrity service; b) contentCommitment: for verifying digital signatures which are intended to signal that the signer is committing to the content being signed. The type of commitment the certificate can be used to support may be further constrained by the CA, e.g. through a certificate policy. The precise type of commitment of the signer e.g. "reviewed and approved" or "with the intent to be bound", may be signalled by the content being signed, e.g. the signed document itself or some additional signed information. Since a content commitment signing is considered to be a digitally signed transaction, the digitalSignature bit need not be set in the certificate. If it is set, it does not affect the level of commitment the signer has endowed in the signed content. Note that it is not incorrect to refer to this keyUsage bit using the identifier nonRepudiation. However, the use of this identifier has been deprecated. Regardless of the identifier used, the semantics of this bit are as specified in this Directory Specification. The text from 3280 is copied below: The digitalSignature bit is asserted when the subject public key is used with a digital signature mechanism to support security services other than certificate signing (bit 5), or CRL signing (bit 6). Digital signature mechanisms are often used for entity authentication and data origin authentication with integrity. The nonRepudiation bit is asserted when the subject public key is used to verify digital signatures used to provide a non- repudiation service which protects against the signing entity falsely denying some action, excluding certificate or CRL signing. In the case of later conflict, a reliable third party may determine the authenticity of the signed data. Further distinctions between the digitalSignature and nonRepudiation bits may be provided in specific certificate policies. The text from 3280bis does not align with the ISO-ITU text. Please align with the the ISO-ITU text. Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q8gbge030944; Thu, 26 May 2005 01:42:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q8gba3030943; Thu, 26 May 2005 01:42:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q8gZ58030933 for ; Thu, 26 May 2005 01:42:36 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA14146 for ; Thu, 26 May 2005 10:57:39 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052610422807:1303 ; Thu, 26 May 2005 10:42:28 +0200 Message-ID: <42958C32.8020706@bull.net> Date: Thu, 26 May 2005 10:43:30 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: pkix Subject: 3280bis: CRL validation X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/05/2005 10:42:28, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 26/05/2005 10:42:30, Serialize complete at 26/05/2005 10:42:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To the list, I changed the name of the thread which is now under 3280bis. As Tim mentioned: "it is clear that the current content of 3280bis with respect to CRL validation does not enjoy consensus within the working group". Issues 33 and 43 are directly related to this topic. They are both copied below: 33) The certificateIssuer CRL entry extension contains a GeneralNames. While RFC 3280 does not state this, there seems to be general agreement that the certificateIssuer extension should only contain the DN from the issuer field of the certificate being revoked. 3280bis states: "Conforming CRL issuers MUST include in [the certificateIssuer] extension the distinguished name (DN) from the issuer field of the certificate that corresponds to this CRL entry. The encoding of the DN MUST be identical to the encoding used in the certificate." 43) It should be noted in 3280bis that there is a risk that two different CAs (or a CA and a CRL issuer) may issue certificates and CRLs under the same name and that if this happens there is a risk that a relying party will validate a certificate issued by one of these entities using a CRL issued by the other. The security considerations section of 3280bis states that CAs and CRL issuers should be formed in a way that reduces the likelihood of name collisions. It also states that implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate terminate at the same trust anchor. Both statements are incorrect. For issue 43: name collisions are possible and a design cannot be based on the assumption that name collisions, whether accidental or intentional, will never happen. This means that chosing names to "reduce the likehood of name collisions" is not a way to solve the issue. Termination at the same trust anchor without additional details does not solve the issue either. For issue 33: the certificateIssuer extension is defined as : certificateIssuer ::= GeneralNames with GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName It is not defined as: certificateIssuer ::= GeneralName ... and this is NOT an error. To go directly to the point, certificateIssuer may contain in practice either: - one name, or - a sequence of names. If it contains one name, this means that this name MUST be certified by the CA that has issued the certificate where the extension appears. If it contains a sequence of names, this means that the certification path of the CRL issuer certificate formed using that sequence of names MUST also terminate at the trust anchor of the target certificate. This is secure and avoids any name collision, either deliberate or intentional. Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q6rsw7015419; Wed, 25 May 2005 23:53:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q6rsn5015418; Wed, 25 May 2005 23:53:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q6rqj4015380 for ; Wed, 25 May 2005 23:53:53 -0700 (PDT) (envelope-from olivier.dubuisson@francetelecom.com) Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 08:53:49 +0200 Received: from [10.193.13.92] ([10.193.13.92]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Thu, 26 May 2005 08:53:49 +0200 Message-ID: <4295727D.1020100@francetelecom.com> Date: Thu, 26 May 2005 08:53:49 +0200 From: Olivier Dubuisson Organization: France Telecom - Research & Development User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Sciberras CC: Jaeho Yoon , ietf-pkix@imc.org Subject: Re: [draft-ietf-pkix-sim-04.txt] References: <001501c56188$964f40b0$720710ac@5434d1> <42952E61.4020601@gmail.com> In-Reply-To: <42952E61.4020601@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2005 06:53:49.0550 (UTC) FILETIME=[AB98E8E0:01C561BF] Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Andrew Sciberras wrote: > Jaeho Yoon wrote: > >> Please review and comment on the following draft : >> Internet X.509 Public Key Infrastructure Subject Identification Method >> (SIM) >> > > Hi, > > Just a couple of little things... > > Since your defining ASN.1 types, it would probably be a good idea to > reference an ASN.1 specification, including the year. The right references are there: http://asn1.elibel.tm.fr/en/standards/index.htm > The year is > important because newer versions of the specification wont accept (or > compile) your ASN.1 module do to the usage of the UTF8String reserved > keyword as a typereference. Why redefine the UTF8String instead of using the one standardized in the ASN.1 standard? -- Olivier DUBUISSON France Telecom Recherche & Developpement R&D/MAPS/AMS - 22307 Lannion Cedex - France t: +33 2 96 05 38 50 - f: +33 2 96 05 39 45 - http://asn1.elibel.tm.fr/ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2MAb6072099; Wed, 25 May 2005 19:22:10 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q2MArH072098; Wed, 25 May 2005 19:22:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2M95m072081 for ; Wed, 25 May 2005 19:22:09 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2M4hh019058 for ; Wed, 25 May 2005 22:22:04 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4Q2M4hk090058 for ; Wed, 25 May 2005 22:22:04 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4Q2M4Ec017753 for ; Wed, 25 May 2005 22:22:04 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2M3rk017750; Wed, 25 May 2005 22:22:03 -0400 In-Reply-To: To: "Stefan Santesson" Cc: "Santosh Chokhani" , ietf-pkix@imc.org, "Julien Stern" MIME-Version: 1.0 Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Wed, 25 May 2005 22:21:59 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/25/2005 22:22:03, Serialize complete at 05/25/2005 22:22:03 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: I can't find any loop control text on this subject in 3280 or 3280-bis. I don't know what a practical validation library would do with a potential loop like this, and I doubt if anybody who hasn't written such a library knows either. One of the things it might do is note that the certificate is already being validated and assume that its validation result is sufficient. That avoids the loop, at the cost of letting this certificate through. Being sure that the library will encounter a loop depends on the library's author interpreting "Obtain and validate the certification path for the complete CRL issuer" to include calling a revocation check on each element in the path and not assuming that a bad certificate already being validated once will be caught elsewhere in the algorithm. On a related issue, the certpathbuild I-D may be just as involved in our discussions as 3280-bis. Its security considerations section on CRL signer paths is considerably more elaborate than 3280's discussion, and does not consider that terminating at the same trust anchor is good enough. Tom Gindin "Stefan Santesson" 05/25/2005 02:17 PM To: Tom Gindin/Watson/IBM@IBMUS, "Santosh Chokhani" cc: , "Julien Stern" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, > cc: "'Julien Stern'" > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, > but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion > would have to take place at some point regarding the overall security > model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2M5WX072088; Wed, 25 May 2005 19:22:05 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q2M58k072087; Wed, 25 May 2005 19:22:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2M4eJ072071 for ; Wed, 25 May 2005 19:22:04 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2Lxig013375 for ; Wed, 25 May 2005 22:21:59 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4Q2Lxhk069204 for ; Wed, 25 May 2005 22:21:59 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4Q2LwXZ013584 for ; Wed, 25 May 2005 22:21:58 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4Q2Lwex013581; Wed, 25 May 2005 22:21:58 -0400 In-Reply-To: <000401c56129$83eb3370$9a00a8c0@hq.orionsec.com> To: "Santosh Chokhani" Cc: ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Wed, 25 May 2005 22:21:54 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/25/2005 22:21:57, Serialize complete at 05/25/2005 22:21:57 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh: I thought that I had made that particular issue clear. The indirect CRL being retrieved governs C's certificates and its issuer name (call it C1) is supposed to belong to C. Indeed, C has issued a CRL signing certificate with subject name C1. However, S has created another CRL signing certificate with this same subject name and has created a CRL with that key pair. C did not create any circularity. The original certificate for C1 was issued by C and the corresponding private key belongs to an entity under C's control, while the new certificate for C1 was issued by S and the corresponding private key belongs to a malicious subsystem inside S. While certificates are issued to entities, relying parties know the name and the chain but not the entity. No relevant CRL is issued by S. I'm sure that your objection to ' looking at CRL issued by C' actually meant 'issued by S', because you normally verify certificates by looking at CRL's issued by the certificate issuer or its delegate. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/25/2005 08:58 AM To: cc: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, It is not clear from your example who the indirect CRL issuer is and what role the "indirect CRL" plays in the attack. If S is the indirect CRL issuer, C should be smart enough to not create circularity (a good toolkit will not verify path when C issues a certificate to S and points to S as the indirect CRL issuer since it causes circularity and chicken and egg problem). That scenario can be easily rectified within current standard by C not declaring S as the indirect CRL issuer for certificate issued to S. C can declare itself in the CDP or some other issuer. I suspect you do not mean this. Your example may be simpler. To me the attack is still not plausible. Your scenario is not detailed enough to illustrate an attack. It does not seem that there is a way to validate the certificate issued to C by S without looking at CRL issued by C, resulting in circularity, which relying party clients should not accept. (Note that my November presentation to IETF in DC covered the circularity issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to the CRL certification path) -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, May 25, 2005 7:50 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; 'Julien Stern' Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q22FxL066512; Wed, 25 May 2005 19:02:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q22Fq6066510; Wed, 25 May 2005 19:02:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q22Dkv066489 for ; Wed, 25 May 2005 19:02:13 -0700 (PDT) (envelope-from andrewsciberras@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so365818rne for ; Wed, 25 May 2005 19:02:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=EkI6kQAWsU62nj1nOISgueP3iYp19aWQNVX2g98h3zfgTxPsP26nbAparay1imdairrtvwCkOz03pJxG9W/8pBYIb/GDvS9XcFA9IirC6hg82TfNZYLlNCIVacO0g/kpBVG4wGoKR9HqQELJmkq85bTHmd8HqkJxxHI7TzZMQpM= Received: by 10.38.153.45 with SMTP id a45mr1528028rne; Wed, 25 May 2005 19:02:12 -0700 (PDT) Received: from ?192.168.1.13? ([202.164.196.167]) by mx.gmail.com with ESMTP id k21sm457814rnb.2005.05.25.19.02.11; Wed, 25 May 2005 19:02:12 -0700 (PDT) Message-ID: <42952E61.4020601@gmail.com> Date: Thu, 26 May 2005 12:03:13 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jaeho Yoon CC: ietf-pkix@imc.org Subject: Re: [draft-ietf-pkix-sim-04.txt] References: <001501c56188$964f40b0$720710ac@5434d1> In-Reply-To: <001501c56188$964f40b0$720710ac@5434d1> Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jaeho Yoon wrote:

Please review and comment on the following draft :
Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)
<draft-ietf-pkix-sim-04.txt>
Hi,

Just a couple of little things...

Since your defining ASN.1 types, it would probably be a good idea to reference an ASN.1 specification, including the year. The year is important because newer versions of the specification wont accept (or compile) your ASN.1 module do to the usage of the UTF8String reserved keyword as a typereference.

The [PI] reference should probably refer to RFC4043

Cheers,
Andrew
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q0JcQs039206; Wed, 25 May 2005 17:19:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q0JcLM039205; Wed, 25 May 2005 17:19:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sniper.kisa.or.kr ([211.252.150.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4Q0JZYJ039189 for ; Wed, 25 May 2005 17:19:37 -0700 (PDT) (envelope-from jhyoon@kisa.or.kr) Received: (snipe 30238 invoked by alias); 26 May 2005 09:18:03 +0900 Received: from jhyoon@kisa.or.kr with Spamsniper 2.83.29 (Processed in 0.010963 secs); Received: from unknown (HELO 5434d1) (172.16.7.114) by unknown with SMTP; 26 May 2005 09:18:03 +0900 X-RCPTTO: ietf-pkix@imc.org Message-ID: <001501c56188$964f40b0$720710ac@5434d1> From: "Jaeho Yoon" To: Subject: [draft-ietf-pkix-sim-04.txt] Date: Thu, 26 May 2005 09:19:31 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C561D4.05FB6650" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C561D4.05FB6650 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBQS0lYIFdHIG1lbWJlcnMsDQoNClBsZWFzZSByZXZpZXcgYW5kIGNvbW1lbnQgb24gdGhl IGZvbGxvd2luZyBkcmFmdCA6IA0KSW50ZXJuZXQgWC41MDkgUHVibGljIEtleSBJbmZyYXN0cnVj dHVyZSBTdWJqZWN0IElkZW50aWZpY2F0aW9uIE1ldGhvZCAoU0lNKQ0KPGRyYWZ0LWlldGYtcGtp eC1zaW0tMDQudHh0PiANCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLXBraXgtc2ltLTA0LnR4 dA0KDQpUaGlzIGRvY3VtZW50IGRlZmluZXMgUHJpdmFjeS1FbmhhbmNlZCBQcm90ZWN0ZWQgU3Vi amVjdCBJZGVudGlmaWVyKFBFUFNJKSBmb3JtYXQgZm9yIGluY2x1ZGluZyBhIHByaXZhY3kgc2Vu c2l0aXZlIGlkZW50aWZpZXIgaW4gdGhlIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbiBvZiBhIGNl cnRpZmljYXRlLiBUaGUgUEVQU0kgaXMgYW4gb3B0aW9uYWwgZmVhdHVyZSB0aGF0IG1heSBiZSB1 c2VkIGJ5IGEgcmVseWluZyBwYXJ0aWVzIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZSBzdWJqZWN0 IG9mIGEgcGFydGljdWxhciBjZXJ0aWZpY2F0ZSBpcyBhbHNvIHRoZSBwZXJzb24gY29ycmVzcG9u ZGluZyB0byBhIHBhcnRpY3VsYXIgc2Vuc2l0aXZlIGlkZW50aWZpZXIuDQogICAgICAgIA0KUmVn YXJkcywgDQoNCkphZWhvIFlvb24NCg== ------=_NextPart_000_0012_01C561D4.05FB6650 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWtzX2NfNTYwMS0xOTg3Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI5MDAuMjYyNyIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwv SEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+RGVhciBQS0lYIFdHIG1lbWJlcnMs PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5QbGVhc2UgcmV2aWV3IGFuZCBjb21tZW50 IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgOiA8L0RJVj4NCjxESVY+SW50ZXJuZXQgWC41MDkgUHVi bGljIEtleSBJbmZyYXN0cnVjdHVyZSBTdWJqZWN0Jm5ic3A7SWRlbnRpZmljYXRpb24gTWV0aG9k IA0KKFNJTSk8QlI+Jmx0O2RyYWZ0LWlldGYtcGtpeC1zaW0tMDQudHh0Jmd0OyA8L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxC Uj48QSANCmhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtcGtpeC1zaW0tMDQudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLXBraXgtc2ltLTA0LnR4dDwvQT48QlI+PEJSPlRoaXMgDQpkb2N1bWVudCBkZWZp bmVzIFByaXZhY3ktRW5oYW5jZWQgUHJvdGVjdGVkIFN1YmplY3QgSWRlbnRpZmllcihQRVBTSSkg Zm9ybWF0IGZvciANCmluY2x1ZGluZyBhIHByaXZhY3kgc2Vuc2l0aXZlIGlkZW50aWZpZXIgaW4g dGhlIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbiBvZiBhIA0KY2VydGlmaWNhdGUuIFRoZSBQRVBT SSBpcyBhbiBvcHRpb25hbCBmZWF0dXJlIHRoYXQgbWF5IGJlIHVzZWQgYnkgYSByZWx5aW5nIA0K cGFydGllcyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgc3ViamVjdCBvZiBhIHBhcnRpY3VsYXIg Y2VydGlmaWNhdGUgaXMgYWxzbyB0aGUgDQpwZXJzb24gY29ycmVzcG9uZGluZyB0byBhIHBhcnRp Y3VsYXIgc2Vuc2l0aXZlIA0KaWRlbnRpZmllci48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxCUj5SZWdhcmRzLCA8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+SmFlaG8gWW9vbjxCUj48L0RJVj48L0JPRFk+PC9I VE1MPg0K ------=_NextPart_000_0012_01C561D4.05FB6650-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJeDBl089544; Wed, 25 May 2005 12:40:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PJeDUJ089543; Wed, 25 May 2005 12:40:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJeBRl089537 for ; Wed, 25 May 2005 12:40:12 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id j4PJdjjo027420; Wed, 25 May 2005 15:40:00 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4PJcZ6v008597; Wed, 25 May 2005 15:38:36 -0400 (EDT) Message-Id: <5.1.0.14.2.20050525152918.03815c60@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 25 May 2005 15:40:18 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: Re: WG Last Call: AIA CRL extension Cc: Denis Pinkas , Stefan Santesson , Russ Housley In-Reply-To: <42948D66.7090300@bull.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Folks, My reading of this thread says that rough consensus has been achieved on the AIA CRL extension ID, and that I can forward the document to the appropriate Area Director after deletion of these sentences. (If anyone disagrees, please say so on list ASAP!) As noted, this issue will have to be addressed in the context of 3280bis. It is clear that the current content of 3280bis with respect to CRL validation does not enjoy consensus within the working group. Thanks, Tim Polk At 04:36 PM 5/25/2005 +0200, Denis Pinkas wrote: >Stefan and Russ, > >>Denis, > >>I discussed this with Russ and our conclusion is that if this resolves >>your last call issues, then we can live with deleting these sentences. > >If so, my concern is solved. > >Thanks, > >Denis > >PS: Stefan, we do not need to meet anymore next week on this topic, > and we can spend more time to enjoy some good food on the > French Riviera. :-) > >>Stefan Santesson >>Program Manager, Standards Liaison >>Windows Security >> >> >>>-----Original Message----- >>>From: owner-ietf-pkix@mail.imc.org >>[mailto:owner-ietf-pkix@mail.imc.org] >> >>>On Behalf Of Denis Pinkas >>>Sent: den 25 maj 2005 00:47 >>>To: Russ Housley >>>Cc: ietf-pkix@imc.org >>>Subject: Re: WG Last Call: AIA CRL extension >>> >>> >>>Russ, >>> >>>Two points: >>> >>>1. The current text in the security considerations section contains >>> text which suggest a solution to the problem but which is not. >>> At least the two following sentences SHALL be deleted: >>> >>> " As means of reducing problems and security issues related to >>issuer >> >>> name collisions, CA names SHOULD be formed in a way that reduce >>the >> >>> likelihood of name collisions. Implementations validating CRLs >>> MUST ensure that the certification path of the target certificate >>> and the CRL issuer certification path used to validate the target >>> certificate, terminate at the same trust anchor". >>> >>>2. We strongly agree that 3280bis MUST address this issue and >>currently >> >>> it does not do it correctly (otherwise we would not have this >>> loooong discussion), ... that we can continue within the scope >>> of 3280bis. >>> >>>Denis >>> >>> >>>>Julien & Tom: >>>> >>>>Two points: >>>> >>>>1. I understand this scenario. The change that you advocate as a >>>>countermeasure will prevent Indirect CRLs from working in scenarios >>that >> >>>>are intended. >>>> >>>>2. This observation has noting to do with the CRL AIA extension. >>The >> >>>>attacker is inserting the bogus revocation information into the >>>>repository. Any relying party that uses that repository (when using >>the >> >>>>CRL AIA extension or any other configuration information to locate >>it) >> >>>>will get the bogus revocation information. >>>> >>>>If this is a concern, then it needs to be addressed in RFC3280bis, >>not >> >>>>here. >>>> >>>>Russ >>>> >>>>At 12:38 PM 5/24/2005, Julien Stern wrote: >>>> >>>> >>>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: >>>>> >>>>>> There is one scenario permitted by the "same trust >>anchor" >> >>>rule >>> >>>>>>for CRL signers which seems to me to be a serious security hole. >>>>> >>>>>Let us >>>>> >>>>>>assume a valid CA which is a direct subordinate of one of the >>RP's >> >>>>>trust >>>>> >>>>>>anchors. This CA issues separate CRL's and ARL's, in a quite >>usual >> >>>>>way, >>>>> >>>>>>and issues cross certificates. After months or years of >>operation, >> >>>it >>> >>>>>>revokes one of its cross certificates because the subject's >>operator >> >>>>>has >>>>> >>>>>>gone rogue. That rogue subject then issues a fraudulent CRL >>Signing >> >>>>>>certificate with the DN that the superior certificate has been >>using >> >>>to >>> >>>>>>sign ARL's, a public key which it has newly generated, and >>various >> >>>>>>extensions including an SKID. It then issues an updated copy of >>an >> >>>old >>> >>>>>>ARL under the fraudulent CRL signer's certificate and with an >>AKID >> >>>>>>matching the fraudulent signer's SKID. If the rogue can break >>into >> >>>the >>> >>>>>>repository where the CRL is expected, this fraudulently issued >>CRL >> >>>will >>> >>>>>>probably be validated whether it contains an AIA or not. It will >>>>>>certainly pass the "same trust anchor" condition. >>>>>> This scenario, in which a rogue CA issues an ARL >>certifiying >> >>>>>that >>>>> >>>>>>its primary certificate has not been revoked and gets the ARL >>>>> >>>>>accepted, is >>>>> >>>>>>possible under "same trust anchor" but not under "signed by path >>>>> >>>>>member". >>>>> >>>>>I agree with the validity of this scenario. I believe this is very >>>>>close to the issue I attempted to bring on the list a short time >>ago. >> >>>>>Of course, it assumes the existence of a rogue CA at some point in >>>time. >>> >>>>>Note that the CRL could be directly inserted into a "long term" >>>>>signature (according to RFC3126 for example). This does not require >>>>>a repository break-in and makes the "attack" even more realistic. >>>>> >>>>>Regards. >>>>> >>>>>-- >>>>>Julien Stern >>>>> >>>>> >>>>>> Tom Gindin >>>>>> >>>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM >>----- >> >>>>>> >>>>>>Tom Gindin >>>>>>05/23/2005 10:46 PM >>>>>> >>>>>> To: wpolk@nist.gov >>>>>> cc: housley@vigilsec.com, ietf-pkix@imc.org, >>>kent@bbn.com, >>> >>>>>>stefans@microsoft.com >>>>>> From: Tom Gindin/Watson/IBM@IBMUS >>>>>> Subject: Re: WG Last Call: AIA CRL extension >>>>>> >>>>>> Tim: >>>>>> >>>>>> I should probably have brought this up earlier, but are >>we >> >>>>>certain >>>>> >>>>>>that "same trust anchor" is a strong enough check that the CRL >>>>> >>>>>signer is >>>>> >>>>>>the one expected by the issuing CA? While I was not in San Diego >>>when >>> >>>>>>this wording was included in the 3280 series, I do not really >>think >> >>>>>that >>>>> >>>>>>that check is strong enough. I would suggest instead that the >>CRL >> >>>>>>signer's certificate needs to be directly issued by one of the >>CA's >> >>>>>in the >>>>> >>>>>>certification path back to the trust anchor used for the >>>certificate's >>> >>>>>>verification, or by that anchor itself, unless people have >>practical >> >>>>>>experience with CA structures which that rule would prohibit. >>>>> >>>>>Forcing the >>>>> >>>>>>CRL to be issued by the CA itself (as I understand Denis to have >>>>>>suggested) prohibits the reasonable case where the CRL is issued >>by a >> >>>>>>hierarchical superior, so it is IMHO too strict. >>>>>> I am personally not sure, FWIW, that a CRL should be >>>>> >>>>>permitted to >>>>> >>>>>>be signed by a second-cousin certificate of the issuer's >>>>> >>>>>certificate. By >>>>> >>>>>>analogy to the use of the terms in families, "sibling" >>certificates >> >>>>>would >>>>> >>>>>>have the same issuer, "first-cousin" certificates would be issued >>by >> >>>>>>siblings, and "second-cousin" certificates would be issued by >>first >> >>>>>>cousins - so they are both three levels down from the same trust >>>>> >>>>>anchor, >>>>> >>>>>>or from the last common CA in their paths. This issue is not >>newly >> >>>>>caused >>>>> >>>>>>by CRL AIA, since the same issue can arise with CRL's containing >>only >> >>>>>>AKID. AIA only allows RP's to build a path (whether right or >>wrong) >> >>>>>more >>>>> >>>>>>quickly. >>>>>> In any case, nothing more than a note in Security >>>>> >>>>>Considerations >>>>> >>>>>>is appropriate in any of our RFC's other than 3280 and its >>successor. >> >>>>>> Tom Gindin >>>>>>P.S. - The above views are mine, and not necessarily those of my >>>>> >>>>>employer >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>Tim Polk >>>>>>Sent by: owner-ietf-pkix@mail.imc.org >>>>>>05/10/2005 05:27 PM >>>>>> >>>>>> To: ietf-pkix@imc.org >>>>>> cc: kent@bbn.com, stefans@microsoft.com, >>>>> >>>>>housley@vigilsec.com >>>>> >>>>>> Subject: WG Last Call: AIA CRL extension >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>This message initiates working group Last Call for the >>specification >> >>>>>>"Internet X.509 Public Key Infrastructure: Authority Information >>>Access >>> >>>>>>CRL >>>>>>Extension". While some issues raised in the working group are >>>>> >>>>>unresolved, >>>>> >>>>>>the editors believe that rough consensus supports the current >>>>>>specification. >>>>>> >>>>>>The URL for this Internet-Draft is: >>>>>> >>>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt >>>>>> >>>>>>Last Call will run for (at least) two weeks. That is, Last Call >>will >> >>>>>not >>>>> >>>>>>close before May 24. >>>>>> >>>>>>Thanks, >>>>>> >>>>>>Tim Polk >>>>>> >>>>>> >>>> >>>> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJZ0pk089335; Wed, 25 May 2005 12:35:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PJZ0hg089334; Wed, 25 May 2005 12:35:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PJYwwc089303 for ; Wed, 25 May 2005 12:34:59 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 May 2005 20:34:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Wed, 25 May 2005 20:34:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Thread-Index: AcVhXm8ooUxoytr5QSaYmzrpXI8E5AAAkefw From: "Stefan Santesson" To: "Santosh Chokhani" , X-OriginalArrivalTime: 25 May 2005 19:34:53.0134 (UTC) FILETIME=[D2CD1EE0:01C56160] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PJYxwc089323 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh, Agree, I was talking about 3280bis. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Santosh Chokhani > Sent: den 25 maj 2005 11:23 > To: ietf-pkix@imc.org > Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Stephan, > > Validation related text (e.g., infinite loops) belongs more in 3280. > Having > it in the new I-D does not harm. But, validation should be addressed by > 3280 and not diced up in multiple RFC and then served. > > -----Original Message----- > From: Stefan Santesson [mailto:stefans@microsoft.com] > Sent: Wednesday, May 25, 2005 2:18 PM > To: Tom Gindin; Santosh Chokhani > Cc: ietf-pkix@imc.org; Julien Stern > Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Tom, > > If the substitution would be successful the validation would go into an > infinite loop and fail. Validation of S's fake CRL requires validation of > C's cross certificate to S which triggers another validation of S's fake > CRL > and so on. > > I think we added some text against infinite loops but I don't have it > fresh > in my memory. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Tom Gindin > > Sent: den 25 maj 2005 04:50 > > To: Santosh Chokhani > > Cc: ietf-pkix@imc.org; 'Julien Stern' > > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > > > > Santosh: > > > > A relatively concrete example would be the following: > > Assume a trust anchor called A, and CA it has issued a cross > > certificate to called C. Further assume that C uses indirect CRL's, > and > > has issued a cross certificate without name constraints to another CA > > called S. Then assume that S goes rogue and creates a CRL signing > > certificate with the same name as C uses for its indirect CRL's (the > key > > pair in that certificate is hereinafter called the "rogue CRL > signer"). > > Further assume that C finds out about this and creates a CRL listing S > as > > revoked, but that S successfully replaces that CRL in the repository > by > > one signed by the rogue CRL signer. > > Does RFC 3280 path validation consider S invalid? If so, > which > > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what > else > > would be likely to cause S to be recognized as invalid? You could > > probably patch any difficulties by adding "if the certificate whose > > revocation is being checked appears in the path, reject it" to > 6.3.3-f. > > > > Tom Gindin > > > > > > > > > > > > > > "Santosh Chokhani" > > 05/24/2005 06:42 PM > > > > To: Tom Gindin/Watson/IBM@IBMUS, > > cc: "'Julien Stern'" > > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > > extension) > > > > > > Tom, > > > > > > I assume you are talking about CRL certification path solution I > proposed > > will not permit the scenario? I still do not see in your case, if the > > Subject CA (cross certified CA) is revoked, you will verify the path > to it > > in the first place. May be I am not understanding your scenario > properly. > > How does the revoked CA gets verified? > > > > > > Julien, > > > > We have defined and proven the solution for how to do this. The > scenario > > you proposed is not something X.509 worries about (A CA that is still > > valid, but has gone bad). > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On > > Behalf Of Julien Stern > > Sent: Tuesday, May 24, 2005 3:49 PM > > To: Stefan Santesson > > Cc: Tom Gindin; ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > > Tom and Julien, > > > > > > Since this is a repetition of the discussion we had before San Diego > > > and I don't want to repeat it here. I'm not saying that this > > > discussion is invalid; it is just directed towards the wrong draft. > > > > Stefan, > > > > I agree with you. Actually, I would tend to believe that a _real_ > > discussion would have to take place at some point regarding the > > overall security model > > of CRL validation, but I have absolutely no objection to the AIA, as > soon > > as > > it is made clear that it's only goal is to simplify path building > > implementations, and not to adress security issues. My very humble > take on > > the subject is that Denis and yourself have been arguing on the list > on > > absolutely valid but different matters. > > > > So, I chose not to comment expect for my last mail (and will not any > more) > > about AIA, but I still think that a discusssion regarding revocation > > validation should take place for RFC3280bis, eventually. > > > > Regards, > > > > -- > > Julien Stern > > > > > > > > As Tom pointed out: > > > > this fraudulently issued CRL will probably be validated whether it > > > > contains an AIA or not. > > > > > > This indicates once again that this is not an issue caused by the > use > > > of AIA in CRLs but a generic CRL validation issue that belongs with > > > RFC 3280bis and not with the CRL-AIA draft. > > > > > > Stefan Santesson > > > Program Manager, Standards Liaison > > > Windows Security > > > > > > > > > > -----Original Message----- > > > > From: owner-ietf-pkix@mail.imc.org > > > [mailto:owner-ietf-pkix@mail.imc.org] > > > > On Behalf Of Julien Stern > > > > Sent: den 24 maj 2005 09:39 > > > > To: Tom Gindin > > > > Cc: ietf-pkix@imc.org > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > > > There is one scenario permitted by the "same trust > anchor" > > > rule > > > > > for CRL signers which seems to me to be a serious security hole. > > > Let us > > > > > assume a valid CA which is a direct subordinate of one of the > RP's > > > trust > > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > > usual > > > way, > > > > > and issues cross certificates. After months or years of > > > > > operation, > > > it > > > > > revokes one of its cross certificates because the subject's > > > > > operator > > > has > > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > > Signing certificate with the DN that the superior certificate > has > > > > > been using > > > to > > > > > sign ARL's, a public key which it has newly generated, and > various > > > > > extensions including an SKID. It then issues an updated copy of > > > > > an > > > old > > > > > ARL under the fraudulent CRL signer's certificate and with an > AKID > > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > > into > > > the > > > > > repository where the CRL is expected, this fraudulently issued > CRL > > > will > > > > > probably be validated whether it contains an AIA or not. It > will > > > > > certainly pass the "same trust anchor" condition. > > > > > This scenario, in which a rogue CA issues an ARL > > > > > certifiying > > > > that > > > > > its primary certificate has not been revoked and gets the ARL > > > accepted, > > > > is > > > > > possible under "same trust anchor" but not under "signed by path > > > > member". > > > > > > > > I agree with the validity of this scenario. I believe this is very > > > > close to the issue I attempted to bring on the list a short time > > > > ago. Of course, it assumes the existence of a rogue CA at some > point > > > > in > > > time. > > > > > > > > Note that the CRL could be directly inserted into a "long term" > > > > signature (according to RFC3126 for example). This does not > require > > > > a repository break-in and makes the "attack" even more realistic. > > > > > > > > Regards. > > > > > > > > -- > > > > Julien Stern > > > > > > > > > > > > > > Tom Gindin > > > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > > ----- > > > > > > > > > > > > > > > Tom Gindin > > > > > 05/23/2005 10:46 PM > > > > > > > > > > To: wpolk@nist.gov > > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > > kent@bbn.com, > > > > > stefans@microsoft.com > > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > > Tim: > > > > > > > > > > I should probably have brought this up earlier, but are > we > > > > certain > > > > > that "same trust anchor" is a strong enough check that the CRL > > > signer is > > > > > the one expected by the issuing CA? While I was not in San > Diego > > > when > > > > > this wording was included in the 3280 series, I do not really > > > > > think > > > that > > > > > that check is strong enough. I would suggest instead that the > CRL > > > > > signer's certificate needs to be directly issued by one of the > > > > > CA's > > > in > > > > the > > > > > certification path back to the trust anchor used for the > > > certificate's > > > > > verification, or by that anchor itself, unless people have > > > > > practical experience with CA structures which that rule would > > > > > prohibit. > > > Forcing > > > > the > > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > > by > > > a > > > > > hierarchical superior, so it is IMHO too strict. > > > > > I am personally not sure, FWIW, that a CRL should be > > > permitted > > > > to > > > > > be signed by a second-cousin certificate of the issuer's > > > certificate. > > > > By > > > > > analogy to the use of the terms in families, "sibling" > > > > > certificates > > > > would > > > > > have the same issuer, "first-cousin" certificates would be > issued > > > > > by siblings, and "second-cousin" certificates would be issued by > > > > > first cousins - so they are both three levels down from the same > > > > > trust > > > anchor, > > > > > or from the last common CA in their paths. This issue is not > > > > > newly > > > > caused > > > > > by CRL AIA, since the same issue can arise with CRL's containing > > > only > > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > > wrong) > > > > more > > > > > quickly. > > > > > In any case, nothing more than a note in Security > > > Considerations > > > > > is appropriate in any of our RFC's other than 3280 and its > > > successor. > > > > > > > > > > Tom Gindin > > > > > P.S. - The above views are mine, and not necessarily those of > my > > > > employer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > > 05/10/2005 05:27 PM > > > > > > > > > > To: ietf-pkix@imc.org > > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > > housley@vigilsec.com > > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > > specification "Internet X.509 Public Key Infrastructure: > Authority > > > > > Information > > > Access > > > > > CRL > > > > > Extension". While some issues raised in the working group are > > > > unresolved, > > > > > > > > > > the editors believe that rough consensus supports the current > > > > > specification. > > > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > > will > > > not > > > > > close before May 24. > > > > > > > > > > Thanks, > > > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PIMpMA077900; Wed, 25 May 2005 11:22:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PIMpcX077899; Wed, 25 May 2005 11:22:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PIMofZ077893 for ; Wed, 25 May 2005 11:22:50 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4PIMn8e027842 for ; Wed, 25 May 2005 14:22:49 -0400 From: "Santosh Chokhani" To: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Wed, 25 May 2005 14:22:44 -0400 Message-ID: <002f01c56156$c1f50830$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PIMpfZ077894 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephan, Validation related text (e.g., infinite loops) belongs more in 3280. Having it in the new I-D does not harm. But, validation should be addressed by 3280 and not diced up in multiple RFC and then served. -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Wednesday, May 25, 2005 2:18 PM To: Tom Gindin; Santosh Chokhani Cc: ietf-pkix@imc.org; Julien Stern Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, > cc: "'Julien Stern'" > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion would have to take place at some point regarding the > overall security model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PII1t3077633; Wed, 25 May 2005 11:18:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PII1s8077632; Wed, 25 May 2005 11:18:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PIHxDS077624 for ; Wed, 25 May 2005 11:18:00 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 May 2005 19:17:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Wed, 25 May 2005 19:17:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Thread-Index: AcVhJ7hMyO7FTj+VSwauDRaoZ34EWQALZJgQ From: "Stefan Santesson" To: "Tom Gindin" , "Santosh Chokhani" Cc: , "Julien Stern" X-OriginalArrivalTime: 25 May 2005 18:17:54.0270 (UTC) FILETIME=[11BE67E0:01C56156] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PII0DS077627 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, If the substitution would be successful the validation would go into an infinite loop and fail. Validation of S's fake CRL requires validation of C's cross certificate to S which triggers another validation of S's fake CRL and so on. I think we added some text against infinite loops but I don't have it fresh in my memory. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Tom Gindin > Sent: den 25 maj 2005 04:50 > To: Santosh Chokhani > Cc: ietf-pkix@imc.org; 'Julien Stern' > Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) > > > Santosh: > > A relatively concrete example would be the following: > Assume a trust anchor called A, and CA it has issued a cross > certificate to called C. Further assume that C uses indirect CRL's, and > has issued a cross certificate without name constraints to another CA > called S. Then assume that S goes rogue and creates a CRL signing > certificate with the same name as C uses for its indirect CRL's (the key > pair in that certificate is hereinafter called the "rogue CRL signer"). > Further assume that C finds out about this and creates a CRL listing S as > revoked, but that S successfully replaces that CRL in the repository by > one signed by the rogue CRL signer. > Does RFC 3280 path validation consider S invalid? If so, which > step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there > always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else > would be likely to cause S to be recognized as invalid? You could > probably patch any difficulties by adding "if the certificate whose > revocation is being checked appears in the path, reject it" to 6.3.3-f. > > Tom Gindin > > > > > > > "Santosh Chokhani" > 05/24/2005 06:42 PM > > To: Tom Gindin/Watson/IBM@IBMUS, > cc: "'Julien Stern'" > Subject: CRL Issue (Was RE: WG Last Call: AIA CRL > extension) > > > Tom, > > > I assume you are talking about CRL certification path solution I proposed > will not permit the scenario? I still do not see in your case, if the > Subject CA (cross certified CA) is revoked, you will verify the path to it > in the first place. May be I am not understanding your scenario properly. > How does the revoked CA gets verified? > > > Julien, > > We have defined and proven the solution for how to do this. The scenario > you proposed is not something X.509 worries about (A CA that is still > valid, > but has gone bad). > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Julien Stern > Sent: Tuesday, May 24, 2005 3:49 PM > To: Stefan Santesson > Cc: Tom Gindin; ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > > On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > > Tom and Julien, > > > > Since this is a repetition of the discussion we had before San Diego > > and I don't want to repeat it here. I'm not saying that this > > discussion is invalid; it is just directed towards the wrong draft. > > Stefan, > > I agree with you. Actually, I would tend to believe that a _real_ > discussion > would have to take place at some point regarding the overall security > model > of CRL validation, but I have absolutely no objection to the AIA, as soon > as > it is made clear that it's only goal is to simplify path building > implementations, and not to adress security issues. My very humble take on > the subject is that Denis and yourself have been arguing on the list on > absolutely valid but different matters. > > So, I chose not to comment expect for my last mail (and will not any more) > about AIA, but I still think that a discusssion regarding revocation > validation should take place for RFC3280bis, eventually. > > Regards, > > -- > Julien Stern > > > > > As Tom pointed out: > > > this fraudulently issued CRL will probably be validated whether it > > > contains an AIA or not. > > > > This indicates once again that this is not an issue caused by the use > > of AIA in CRLs but a generic CRL validation issue that belongs with > > RFC 3280bis and not with the CRL-AIA draft. > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > -----Original Message----- > > > From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > > > On Behalf Of Julien Stern > > > Sent: den 24 maj 2005 09:39 > > > To: Tom Gindin > > > Cc: ietf-pkix@imc.org > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > > > There is one scenario permitted by the "same trust anchor" > > rule > > > > for CRL signers which seems to me to be a serious security hole. > > Let us > > > > assume a valid CA which is a direct subordinate of one of the RP's > > trust > > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > > usual > > way, > > > > and issues cross certificates. After months or years of > > > > operation, > > it > > > > revokes one of its cross certificates because the subject's > > > > operator > > has > > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > > Signing certificate with the DN that the superior certificate has > > > > been using > > to > > > > sign ARL's, a public key which it has newly generated, and various > > > > extensions including an SKID. It then issues an updated copy of > > > > an > > old > > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > > matching the fraudulent signer's SKID. If the rogue can break > > > > into > > the > > > > repository where the CRL is expected, this fraudulently issued CRL > > will > > > > probably be validated whether it contains an AIA or not. It will > > > > certainly pass the "same trust anchor" condition. > > > > This scenario, in which a rogue CA issues an ARL > > > > certifiying > > > that > > > > its primary certificate has not been revoked and gets the ARL > > accepted, > > > is > > > > possible under "same trust anchor" but not under "signed by path > > > member". > > > > > > I agree with the validity of this scenario. I believe this is very > > > close to the issue I attempted to bring on the list a short time > > > ago. Of course, it assumes the existence of a rogue CA at some point > > > in > > time. > > > > > > Note that the CRL could be directly inserted into a "long term" > > > signature (according to RFC3126 for example). This does not require > > > a repository break-in and makes the "attack" even more realistic. > > > > > > Regards. > > > > > > -- > > > Julien Stern > > > > > > > > > > > Tom Gindin > > > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > > ----- > > > > > > > > > > > > Tom Gindin > > > > 05/23/2005 10:46 PM > > > > > > > > To: wpolk@nist.gov > > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > > kent@bbn.com, > > > > stefans@microsoft.com > > > > From: Tom Gindin/Watson/IBM@IBMUS > > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > > > Tim: > > > > > > > > I should probably have brought this up earlier, but are we > > > certain > > > > that "same trust anchor" is a strong enough check that the CRL > > signer is > > > > the one expected by the issuing CA? While I was not in San Diego > > when > > > > this wording was included in the 3280 series, I do not really > > > > think > > that > > > > that check is strong enough. I would suggest instead that the CRL > > > > signer's certificate needs to be directly issued by one of the > > > > CA's > > in > > > the > > > > certification path back to the trust anchor used for the > > certificate's > > > > verification, or by that anchor itself, unless people have > > > > practical experience with CA structures which that rule would > > > > prohibit. > > Forcing > > > the > > > > CRL to be issued by the CA itself (as I understand Denis to have > > > > suggested) prohibits the reasonable case where the CRL is issued > > > > by > > a > > > > hierarchical superior, so it is IMHO too strict. > > > > I am personally not sure, FWIW, that a CRL should be > > permitted > > > to > > > > be signed by a second-cousin certificate of the issuer's > > certificate. > > > By > > > > analogy to the use of the terms in families, "sibling" > > > > certificates > > > would > > > > have the same issuer, "first-cousin" certificates would be issued > > > > by siblings, and "second-cousin" certificates would be issued by > > > > first cousins - so they are both three levels down from the same > > > > trust > > anchor, > > > > or from the last common CA in their paths. This issue is not > > > > newly > > > caused > > > > by CRL AIA, since the same issue can arise with CRL's containing > > only > > > > AKID. AIA only allows RP's to build a path (whether right or > > > > wrong) > > > more > > > > quickly. > > > > In any case, nothing more than a note in Security > > Considerations > > > > is appropriate in any of our RFC's other than 3280 and its > > successor. > > > > > > > > Tom Gindin > > > > P.S. - The above views are mine, and not necessarily those of my > > > employer > > > > > > > > > > > > > > > > > > > > > > > > Tim Polk > > > > Sent by: owner-ietf-pkix@mail.imc.org > > > > 05/10/2005 05:27 PM > > > > > > > > To: ietf-pkix@imc.org > > > > cc: kent@bbn.com, stefans@microsoft.com, > > > housley@vigilsec.com > > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > > Information > > Access > > > > CRL > > > > Extension". While some issues raised in the working group are > > > unresolved, > > > > > > > > the editors believe that rough consensus supports the current > > > > specification. > > > > > > > > The URL for this Internet-Draft is: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > > will > > not > > > > close before May 24. > > > > > > > > Thanks, > > > > > > > > Tim Polk > > > > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PEZxSa022338; Wed, 25 May 2005 07:35:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PEZxwt022337; Wed, 25 May 2005 07:35:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PEZvuB022317 for ; Wed, 25 May 2005 07:35:58 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA56426; Wed, 25 May 2005 16:50:41 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052516352850:1008 ; Wed, 25 May 2005 16:35:28 +0200 Message-ID: <42948D66.7090300@bull.net> Date: Wed, 25 May 2005 16:36:22 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson , Russ Housley CC: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/05/2005 16:35:28, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/05/2005 16:35:33, Serialize complete at 25/05/2005 16:35:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan and Russ, > Denis, > I discussed this with Russ and our conclusion is that if this resolves > your last call issues, then we can live with deleting these sentences. If so, my concern is solved. Thanks, Denis PS: Stefan, we do not need to meet anymore next week on this topic, and we can spend more time to enjoy some good food on the French Riviera. :-) > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 25 maj 2005 00:47 >>To: Russ Housley >>Cc: ietf-pkix@imc.org >>Subject: Re: WG Last Call: AIA CRL extension >> >> >>Russ, >> >>Two points: >> >>1. The current text in the security considerations section contains >> text which suggest a solution to the problem but which is not. >> At least the two following sentences SHALL be deleted: >> >> " As means of reducing problems and security issues related to > > issuer > >> name collisions, CA names SHOULD be formed in a way that reduce > > the > >> likelihood of name collisions. Implementations validating CRLs >> MUST ensure that the certification path of the target certificate >> and the CRL issuer certification path used to validate the target >> certificate, terminate at the same trust anchor". >> >>2. We strongly agree that 3280bis MUST address this issue and > > currently > >> it does not do it correctly (otherwise we would not have this >> loooong discussion), ... that we can continue within the scope >> of 3280bis. >> >>Denis >> >> >>>Julien & Tom: >>> >>>Two points: >>> >>>1. I understand this scenario. The change that you advocate as a >>>countermeasure will prevent Indirect CRLs from working in scenarios >> > that > >>>are intended. >>> >>>2. This observation has noting to do with the CRL AIA extension. >> > The > >>>attacker is inserting the bogus revocation information into the >>>repository. Any relying party that uses that repository (when using >> > the > >>>CRL AIA extension or any other configuration information to locate >> > it) > >>>will get the bogus revocation information. >>> >>>If this is a concern, then it needs to be addressed in RFC3280bis, >> > not > >>>here. >>> >>>Russ >>> >>>At 12:38 PM 5/24/2005, Julien Stern wrote: >>> >>> >>>>On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: >>>> >>>>> There is one scenario permitted by the "same trust >>>> > anchor" > >>rule >> >>>>>for CRL signers which seems to me to be a serious security hole. >>>> >>>>Let us >>>> >>>>>assume a valid CA which is a direct subordinate of one of the >>>> > RP's > >>>>trust >>>> >>>>>anchors. This CA issues separate CRL's and ARL's, in a quite >>>> > usual > >>>>way, >>>> >>>>>and issues cross certificates. After months or years of >>>> > operation, > >>it >> >>>>>revokes one of its cross certificates because the subject's >>>> > operator > >>>>has >>>> >>>>>gone rogue. That rogue subject then issues a fraudulent CRL >>>> > Signing > >>>>>certificate with the DN that the superior certificate has been >>>> > using > >>to >> >>>>>sign ARL's, a public key which it has newly generated, and >>>> > various > >>>>>extensions including an SKID. It then issues an updated copy of >>>> > an > >>old >> >>>>>ARL under the fraudulent CRL signer's certificate and with an >>>> > AKID > >>>>>matching the fraudulent signer's SKID. If the rogue can break >>>> > into > >>the >> >>>>>repository where the CRL is expected, this fraudulently issued >>>> > CRL > >>will >> >>>>>probably be validated whether it contains an AIA or not. It will >>>>>certainly pass the "same trust anchor" condition. >>>>> This scenario, in which a rogue CA issues an ARL >>>> > certifiying > >>>>that >>>> >>>>>its primary certificate has not been revoked and gets the ARL >>>> >>>>accepted, is >>>> >>>>>possible under "same trust anchor" but not under "signed by path >>>> >>>>member". >>>> >>>>I agree with the validity of this scenario. I believe this is very >>>>close to the issue I attempted to bring on the list a short time >>> > ago. > >>>>Of course, it assumes the existence of a rogue CA at some point in >>> >>time. >> >>>>Note that the CRL could be directly inserted into a "long term" >>>>signature (according to RFC3126 for example). This does not require >>>>a repository break-in and makes the "attack" even more realistic. >>>> >>>>Regards. >>>> >>>>-- >>>>Julien Stern >>>> >>>> >>>>> Tom Gindin >>>>> >>>>>----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM >>>> > ----- > >>>>> >>>>>Tom Gindin >>>>>05/23/2005 10:46 PM >>>>> >>>>> To: wpolk@nist.gov >>>>> cc: housley@vigilsec.com, ietf-pkix@imc.org, >>>> >>kent@bbn.com, >> >>>>>stefans@microsoft.com >>>>> From: Tom Gindin/Watson/IBM@IBMUS >>>>> Subject: Re: WG Last Call: AIA CRL extension >>>>> >>>>> Tim: >>>>> >>>>> I should probably have brought this up earlier, but are >>>> > we > >>>>certain >>>> >>>>>that "same trust anchor" is a strong enough check that the CRL >>>> >>>>signer is >>>> >>>>>the one expected by the issuing CA? While I was not in San Diego >>>> >>when >> >>>>>this wording was included in the 3280 series, I do not really >>>> > think > >>>>that >>>> >>>>>that check is strong enough. I would suggest instead that the >>>> > CRL > >>>>>signer's certificate needs to be directly issued by one of the >>>> > CA's > >>>>in the >>>> >>>>>certification path back to the trust anchor used for the >>>> >>certificate's >> >>>>>verification, or by that anchor itself, unless people have >>>> > practical > >>>>>experience with CA structures which that rule would prohibit. >>>> >>>>Forcing the >>>> >>>>>CRL to be issued by the CA itself (as I understand Denis to have >>>>>suggested) prohibits the reasonable case where the CRL is issued >>>> > by a > >>>>>hierarchical superior, so it is IMHO too strict. >>>>> I am personally not sure, FWIW, that a CRL should be >>>> >>>>permitted to >>>> >>>>>be signed by a second-cousin certificate of the issuer's >>>> >>>>certificate. By >>>> >>>>>analogy to the use of the terms in families, "sibling" >>>> > certificates > >>>>would >>>> >>>>>have the same issuer, "first-cousin" certificates would be issued >>>> > by > >>>>>siblings, and "second-cousin" certificates would be issued by >>>> > first > >>>>>cousins - so they are both three levels down from the same trust >>>> >>>>anchor, >>>> >>>>>or from the last common CA in their paths. This issue is not >>>> > newly > >>>>caused >>>> >>>>>by CRL AIA, since the same issue can arise with CRL's containing >>>> > only > >>>>>AKID. AIA only allows RP's to build a path (whether right or >>>> > wrong) > >>>>more >>>> >>>>>quickly. >>>>> In any case, nothing more than a note in Security >>>> >>>>Considerations >>>> >>>>>is appropriate in any of our RFC's other than 3280 and its >>>> > successor. > >>>>> Tom Gindin >>>>>P.S. - The above views are mine, and not necessarily those of my >>>> >>>>employer >>>> >>>>> >>>>> >>>>> >>>>> >>>>>Tim Polk >>>>>Sent by: owner-ietf-pkix@mail.imc.org >>>>>05/10/2005 05:27 PM >>>>> >>>>> To: ietf-pkix@imc.org >>>>> cc: kent@bbn.com, stefans@microsoft.com, >>>> >>>>housley@vigilsec.com >>>> >>>>> Subject: WG Last Call: AIA CRL extension >>>>> >>>>> >>>>> >>>>> >>>>>This message initiates working group Last Call for the >>>> > specification > >>>>>"Internet X.509 Public Key Infrastructure: Authority Information >>>> >>Access >> >>>>>CRL >>>>>Extension". While some issues raised in the working group are >>>> >>>>unresolved, >>>> >>>>>the editors believe that rough consensus supports the current >>>>>specification. >>>>> >>>>>The URL for this Internet-Draft is: >>>>> >>>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt >>>>> >>>>>Last Call will run for (at least) two weeks. That is, Last Call >>>> > will > >>>>not >>>> >>>>>close before May 24. >>>>> >>>>>Thanks, >>>>> >>>>>Tim Polk >>>>> >>>>> >>>>> >>>> >>> >>> >>> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PDnWc6014890; Wed, 25 May 2005 06:49:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PDnWgR014889; Wed, 25 May 2005 06:49:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PDnUEw014875 for ; Wed, 25 May 2005 06:49:31 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 May 2005 14:49:25 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: AIA CRL extension Date: Wed, 25 May 2005 14:49:10 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: AIA CRL extension Thread-Index: AcVhBrzVcfnlDPymT/ae2CZ3lJTg4AAKSlig From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: X-OriginalArrivalTime: 25 May 2005 13:49:25.0237 (UTC) FILETIME=[90030A50:01C56130] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PDnVEw014883 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, I discussed this with Russ and our conclusion is that if this resolves your last call issues, then we can live with deleting these sentences. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 25 maj 2005 00:47 > To: Russ Housley > Cc: ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > Russ, > > Two points: > > 1. The current text in the security considerations section contains > text which suggest a solution to the problem but which is not. > At least the two following sentences SHALL be deleted: > > " As means of reducing problems and security issues related to issuer > name collisions, CA names SHOULD be formed in a way that reduce the > likelihood of name collisions. Implementations validating CRLs > MUST ensure that the certification path of the target certificate > and the CRL issuer certification path used to validate the target > certificate, terminate at the same trust anchor". > > 2. We strongly agree that 3280bis MUST address this issue and currently > it does not do it correctly (otherwise we would not have this > loooong discussion), ... that we can continue within the scope > of 3280bis. > > Denis > > > Julien & Tom: > > > > Two points: > > > > 1. I understand this scenario. The change that you advocate as a > > countermeasure will prevent Indirect CRLs from working in scenarios that > > are intended. > > > > 2. This observation has noting to do with the CRL AIA extension. The > > attacker is inserting the bogus revocation information into the > > repository. Any relying party that uses that repository (when using the > > CRL AIA extension or any other configuration information to locate it) > > will get the bogus revocation information. > > > > If this is a concern, then it needs to be addressed in RFC3280bis, not > > here. > > > > Russ > > > > At 12:38 PM 5/24/2005, Julien Stern wrote: > > > >> On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > >> > > >> > There is one scenario permitted by the "same trust anchor" > rule > >> > for CRL signers which seems to me to be a serious security hole. > >> Let us > >> > assume a valid CA which is a direct subordinate of one of the RP's > >> trust > >> > anchors. This CA issues separate CRL's and ARL's, in a quite usual > >> way, > >> > and issues cross certificates. After months or years of operation, > it > >> > revokes one of its cross certificates because the subject's operator > >> has > >> > gone rogue. That rogue subject then issues a fraudulent CRL Signing > >> > certificate with the DN that the superior certificate has been using > to > >> > sign ARL's, a public key which it has newly generated, and various > >> > extensions including an SKID. It then issues an updated copy of an > old > >> > ARL under the fraudulent CRL signer's certificate and with an AKID > >> > matching the fraudulent signer's SKID. If the rogue can break into > the > >> > repository where the CRL is expected, this fraudulently issued CRL > will > >> > probably be validated whether it contains an AIA or not. It will > >> > certainly pass the "same trust anchor" condition. > >> > This scenario, in which a rogue CA issues an ARL certifiying > >> that > >> > its primary certificate has not been revoked and gets the ARL > >> accepted, is > >> > possible under "same trust anchor" but not under "signed by path > >> member". > >> > >> I agree with the validity of this scenario. I believe this is very > >> close to the issue I attempted to bring on the list a short time ago. > >> Of course, it assumes the existence of a rogue CA at some point in > time. > >> > >> Note that the CRL could be directly inserted into a "long term" > >> signature (according to RFC3126 for example). This does not require > >> a repository break-in and makes the "attack" even more realistic. > >> > >> Regards. > >> > >> -- > >> Julien Stern > >> > >> > > >> > Tom Gindin > >> > > >> > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > >> > > >> > > >> > Tom Gindin > >> > 05/23/2005 10:46 PM > >> > > >> > To: wpolk@nist.gov > >> > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > >> > stefans@microsoft.com > >> > From: Tom Gindin/Watson/IBM@IBMUS > >> > Subject: Re: WG Last Call: AIA CRL extension > >> > > >> > Tim: > >> > > >> > I should probably have brought this up earlier, but are we > >> certain > >> > that "same trust anchor" is a strong enough check that the CRL > >> signer is > >> > the one expected by the issuing CA? While I was not in San Diego > when > >> > this wording was included in the 3280 series, I do not really think > >> that > >> > that check is strong enough. I would suggest instead that the CRL > >> > signer's certificate needs to be directly issued by one of the CA's > >> in the > >> > certification path back to the trust anchor used for the > certificate's > >> > verification, or by that anchor itself, unless people have practical > >> > experience with CA structures which that rule would prohibit. > >> Forcing the > >> > CRL to be issued by the CA itself (as I understand Denis to have > >> > suggested) prohibits the reasonable case where the CRL is issued by a > >> > hierarchical superior, so it is IMHO too strict. > >> > I am personally not sure, FWIW, that a CRL should be > >> permitted to > >> > be signed by a second-cousin certificate of the issuer's > >> certificate. By > >> > analogy to the use of the terms in families, "sibling" certificates > >> would > >> > have the same issuer, "first-cousin" certificates would be issued by > >> > siblings, and "second-cousin" certificates would be issued by first > >> > cousins - so they are both three levels down from the same trust > >> anchor, > >> > or from the last common CA in their paths. This issue is not newly > >> caused > >> > by CRL AIA, since the same issue can arise with CRL's containing only > >> > AKID. AIA only allows RP's to build a path (whether right or wrong) > >> more > >> > quickly. > >> > In any case, nothing more than a note in Security > >> Considerations > >> > is appropriate in any of our RFC's other than 3280 and its successor. > >> > > >> > Tom Gindin > >> > P.S. - The above views are mine, and not necessarily those of my > >> employer > >> > > >> > > >> > > >> > > >> > > >> > Tim Polk > >> > Sent by: owner-ietf-pkix@mail.imc.org > >> > 05/10/2005 05:27 PM > >> > > >> > To: ietf-pkix@imc.org > >> > cc: kent@bbn.com, stefans@microsoft.com, > >> housley@vigilsec.com > >> > Subject: WG Last Call: AIA CRL extension > >> > > >> > > >> > > >> > > >> > This message initiates working group Last Call for the specification > >> > "Internet X.509 Public Key Infrastructure: Authority Information > Access > >> > CRL > >> > Extension". While some issues raised in the working group are > >> unresolved, > >> > > >> > the editors believe that rough consensus supports the current > >> > specification. > >> > > >> > The URL for this Internet-Draft is: > >> > > >> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > >> > > >> > Last Call will run for (at least) two weeks. That is, Last Call will > >> not > >> > close before May 24. > >> > > >> > Thanks, > >> > > >> > Tim Polk > >> > > >> > > >> > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PCx0tM000309; Wed, 25 May 2005 05:59:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PCx04v000307; Wed, 25 May 2005 05:59:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PCwxdX000294 for ; Wed, 25 May 2005 05:58:59 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-114-242.res.east.verizon.net [70.21.114.242]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4PCww8e005156 for ; Wed, 25 May 2005 08:58:59 -0400 From: "Santosh Chokhani" To: Subject: RE: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Wed, 25 May 2005 08:58:52 -0400 Message-ID: <000401c56129$83eb3370$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4PCx0dX000301 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, It is not clear from your example who the indirect CRL issuer is and what role the "indirect CRL" plays in the attack. If S is the indirect CRL issuer, C should be smart enough to not create circularity (a good toolkit will not verify path when C issues a certificate to S and points to S as the indirect CRL issuer since it causes circularity and chicken and egg problem). That scenario can be easily rectified within current standard by C not declaring S as the indirect CRL issuer for certificate issued to S. C can declare itself in the CDP or some other issuer. I suspect you do not mean this. Your example may be simpler. To me the attack is still not plausible. Your scenario is not detailed enough to illustrate an attack. It does not seem that there is a way to validate the certificate issued to C by S without looking at CRL issued by C, resulting in circularity, which relying party clients should not accept. (Note that my November presentation to IETF in DC covered the circularity issues in CRL and OCSP and recommendations for 3280 and 2560 in addition to the CRL certification path) -----Original Message----- From: Tom Gindin [mailto:tgindin@us.ibm.com] Sent: Wednesday, May 25, 2005 7:50 AM To: Santosh Chokhani Cc: ietf-pkix@imc.org; 'Julien Stern' Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PBo2vI060031; Wed, 25 May 2005 04:50:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PBo2nI060030; Wed, 25 May 2005 04:50:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PBo0Oq059983 for ; Wed, 25 May 2005 04:50:00 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4PBnsT5023927 for ; Wed, 25 May 2005 07:49:54 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4PBns5Z157526 for ; Wed, 25 May 2005 07:49:54 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4PBnsPS002935 for ; Wed, 25 May 2005 07:49:54 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4PBnsxc002932; Wed, 25 May 2005 07:49:54 -0400 In-Reply-To: <005601c560b1$e2034470$aa02a8c0@hq.orionsec.com> To: "Santosh Chokhani" Cc: ietf-pkix@imc.org, "'Julien Stern'" MIME-Version: 1.0 Subject: Re: CRL Issue (Was RE: WG Last Call: AIA CRL extension) X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Wed, 25 May 2005 07:49:50 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/25/2005 07:49:53, Serialize complete at 05/25/2005 07:49:53 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Santosh: A relatively concrete example would be the following: Assume a trust anchor called A, and CA it has issued a cross certificate to called C. Further assume that C uses indirect CRL's, and has issued a cross certificate without name constraints to another CA called S. Then assume that S goes rogue and creates a CRL signing certificate with the same name as C uses for its indirect CRL's (the key pair in that certificate is hereinafter called the "rogue CRL signer"). Further assume that C finds out about this and creates a CRL listing S as revoked, but that S successfully replaces that CRL in the repository by one signed by the rogue CRL signer. Does RFC 3280 path validation consider S invalid? If so, which step loops or fails? It looks to me like 6.3.3-b-1 passes. Is there always a bi-modal loop between 6.3.3-f and 6.1.3-a-3? If not, what else would be likely to cause S to be recognized as invalid? You could probably patch any difficulties by adding "if the certificate whose revocation is being checked appears in the path, reject it" to 6.3.3-f. Tom Gindin "Santosh Chokhani" 05/24/2005 06:42 PM To: Tom Gindin/Watson/IBM@IBMUS, cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4P7jq9t061700; Wed, 25 May 2005 00:45:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4P7jqTk061699; Wed, 25 May 2005 00:45:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4P7jnO1061655 for ; Wed, 25 May 2005 00:45:50 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA38762; Wed, 25 May 2005 10:00:38 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052509452887:606 ; Wed, 25 May 2005 09:45:28 +0200 Message-ID: <42942D57.5010103@bull.net> Date: Wed, 25 May 2005 09:46:31 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension References: <20050524163852.GA13889@cryptolog.com> <6.2.1.2.2.20050524142144.068279f0@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/05/2005 09:45:28, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 25/05/2005 09:45:30, Serialize complete at 25/05/2005 09:45:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Two points: 1. The current text in the security considerations section contains text which suggest a solution to the problem but which is not. At least the two following sentences SHALL be deleted: " As means of reducing problems and security issues related to issuer name collisions, CA names SHOULD be formed in a way that reduce the likelihood of name collisions. Implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at the same trust anchor". 2. We strongly agree that 3280bis MUST address this issue and currently it does not do it correctly (otherwise we would not have this loooong discussion), ... that we can continue within the scope of 3280bis. Denis > Julien & Tom: > > Two points: > > 1. I understand this scenario. The change that you advocate as a > countermeasure will prevent Indirect CRLs from working in scenarios that > are intended. > > 2. This observation has noting to do with the CRL AIA extension. The > attacker is inserting the bogus revocation information into the > repository. Any relying party that uses that repository (when using the > CRL AIA extension or any other configuration information to locate it) > will get the bogus revocation information. > > If this is a concern, then it needs to be addressed in RFC3280bis, not > here. > > Russ > > At 12:38 PM 5/24/2005, Julien Stern wrote: > >> On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: >> > >> > There is one scenario permitted by the "same trust anchor" rule >> > for CRL signers which seems to me to be a serious security hole. >> Let us >> > assume a valid CA which is a direct subordinate of one of the RP's >> trust >> > anchors. This CA issues separate CRL's and ARL's, in a quite usual >> way, >> > and issues cross certificates. After months or years of operation, it >> > revokes one of its cross certificates because the subject's operator >> has >> > gone rogue. That rogue subject then issues a fraudulent CRL Signing >> > certificate with the DN that the superior certificate has been using to >> > sign ARL's, a public key which it has newly generated, and various >> > extensions including an SKID. It then issues an updated copy of an old >> > ARL under the fraudulent CRL signer's certificate and with an AKID >> > matching the fraudulent signer's SKID. If the rogue can break into the >> > repository where the CRL is expected, this fraudulently issued CRL will >> > probably be validated whether it contains an AIA or not. It will >> > certainly pass the "same trust anchor" condition. >> > This scenario, in which a rogue CA issues an ARL certifiying >> that >> > its primary certificate has not been revoked and gets the ARL >> accepted, is >> > possible under "same trust anchor" but not under "signed by path >> member". >> >> I agree with the validity of this scenario. I believe this is very >> close to the issue I attempted to bring on the list a short time ago. >> Of course, it assumes the existence of a rogue CA at some point in time. >> >> Note that the CRL could be directly inserted into a "long term" >> signature (according to RFC3126 for example). This does not require >> a repository break-in and makes the "attack" even more realistic. >> >> Regards. >> >> -- >> Julien Stern >> >> > >> > Tom Gindin >> > >> > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- >> > >> > >> > Tom Gindin >> > 05/23/2005 10:46 PM >> > >> > To: wpolk@nist.gov >> > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, >> > stefans@microsoft.com >> > From: Tom Gindin/Watson/IBM@IBMUS >> > Subject: Re: WG Last Call: AIA CRL extension >> > >> > Tim: >> > >> > I should probably have brought this up earlier, but are we >> certain >> > that "same trust anchor" is a strong enough check that the CRL >> signer is >> > the one expected by the issuing CA? While I was not in San Diego when >> > this wording was included in the 3280 series, I do not really think >> that >> > that check is strong enough. I would suggest instead that the CRL >> > signer's certificate needs to be directly issued by one of the CA's >> in the >> > certification path back to the trust anchor used for the certificate's >> > verification, or by that anchor itself, unless people have practical >> > experience with CA structures which that rule would prohibit. >> Forcing the >> > CRL to be issued by the CA itself (as I understand Denis to have >> > suggested) prohibits the reasonable case where the CRL is issued by a >> > hierarchical superior, so it is IMHO too strict. >> > I am personally not sure, FWIW, that a CRL should be >> permitted to >> > be signed by a second-cousin certificate of the issuer's >> certificate. By >> > analogy to the use of the terms in families, "sibling" certificates >> would >> > have the same issuer, "first-cousin" certificates would be issued by >> > siblings, and "second-cousin" certificates would be issued by first >> > cousins - so they are both three levels down from the same trust >> anchor, >> > or from the last common CA in their paths. This issue is not newly >> caused >> > by CRL AIA, since the same issue can arise with CRL's containing only >> > AKID. AIA only allows RP's to build a path (whether right or wrong) >> more >> > quickly. >> > In any case, nothing more than a note in Security >> Considerations >> > is appropriate in any of our RFC's other than 3280 and its successor. >> > >> > Tom Gindin >> > P.S. - The above views are mine, and not necessarily those of my >> employer >> > >> > >> > >> > >> > >> > Tim Polk >> > Sent by: owner-ietf-pkix@mail.imc.org >> > 05/10/2005 05:27 PM >> > >> > To: ietf-pkix@imc.org >> > cc: kent@bbn.com, stefans@microsoft.com, >> housley@vigilsec.com >> > Subject: WG Last Call: AIA CRL extension >> > >> > >> > >> > >> > This message initiates working group Last Call for the specification >> > "Internet X.509 Public Key Infrastructure: Authority Information Access >> > CRL >> > Extension". While some issues raised in the working group are >> unresolved, >> > >> > the editors believe that rough consensus supports the current >> > specification. >> > >> > The URL for this Internet-Draft is: >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt >> > >> > Last Call will run for (at least) two weeks. That is, Last Call will >> not >> > close before May 24. >> > >> > Thanks, >> > >> > Tim Polk >> > >> > >> > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OMgl0G093020; Tue, 24 May 2005 15:42:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OMgl5C093019; Tue, 24 May 2005 15:42:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OMgkDr093013 for ; Tue, 24 May 2005 15:42:47 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (pcp09271453pcs.arlngt01.va.comcast.net [69.143.129.49]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4OMga8e015975; Tue, 24 May 2005 18:42:36 -0400 From: "Santosh Chokhani" To: "'Tom Gindin'" , Cc: "'Julien Stern'" Subject: CRL Issue (Was RE: WG Last Call: AIA CRL extension) Date: Tue, 24 May 2005 18:42:31 -0400 Message-ID: <005601c560b1$e2034470$aa02a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050524194827.GA13972@cryptolog.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OMglDr093014 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, I assume you are talking about CRL certification path solution I proposed will not permit the scenario? I still do not see in your case, if the Subject CA (cross certified CA) is revoked, you will verify the path to it in the first place. May be I am not understanding your scenario properly. How does the revoked CA gets verified? Julien, We have defined and proven the solution for how to do this. The scenario you proposed is not something X.509 worries about (A CA that is still valid, but has gone bad). -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Julien Stern Sent: Tuesday, May 24, 2005 3:49 PM To: Stefan Santesson Cc: Tom Gindin; ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego > and I don't want to repeat it here. I'm not saying that this > discussion is invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use > of AIA in CRLs but a generic CRL validation issue that belongs with > RFC 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite > > > usual > way, > > > and issues cross certificates. After months or years of > > > operation, > it > > > revokes one of its cross certificates because the subject's > > > operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL > > > Signing certificate with the DN that the superior certificate has > > > been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of > > > an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break > > > into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL > > > certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time > > ago. Of course, it assumes the existence of a rogue CA at some point > > in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really > > > think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the > > > CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have > > > practical experience with CA structures which that rule would > > > prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued > > > by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" > > > certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued > > > by siblings, and "second-cousin" certificates would be issued by > > > first cousins - so they are both three levels down from the same > > > trust > anchor, > > > or from the last common CA in their paths. This issue is not > > > newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or > > > wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the > > > specification "Internet X.509 Public Key Infrastructure: Authority > > > Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call > > > will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OJmdQQ056041; Tue, 24 May 2005 12:48:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OJmd3H056040; Tue, 24 May 2005 12:48:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OJmc0k056032 for ; Tue, 24 May 2005 12:48:38 -0700 (PDT) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 3607262D06; Tue, 24 May 2005 21:48:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id DA292440ED; Tue, 24 May 2005 21:49:09 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19521-03; Tue, 24 May 2005 21:49:04 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id D647A440AF; Tue, 24 May 2005 21:49:04 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 24 May 2005 21:48:31 +0200 From: "Julien Stern" Date: Tue, 24 May 2005 21:48:31 +0200 To: Stefan Santesson Cc: Tom Gindin , ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension Message-ID: <20050524194827.GA13972@cryptolog.com> Mail-Followup-To: Julien Stern , Stefan Santesson , Tom Gindin , ietf-pkix@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, May 24, 2005 at 07:28:11PM +0100, Stefan Santesson wrote: > Tom and Julien, > > Since this is a repetition of the discussion we had before San Diego and > I don't want to repeat it here. I'm not saying that this discussion is > invalid; it is just directed towards the wrong draft. Stefan, I agree with you. Actually, I would tend to believe that a _real_ discussion would have to take place at some point regarding the overall security model of CRL validation, but I have absolutely no objection to the AIA, as soon as it is made clear that it's only goal is to simplify path building implementations, and not to adress security issues. My very humble take on the subject is that Denis and yourself have been arguing on the list on absolutely valid but different matters. So, I chose not to comment expect for my last mail (and will not any more) about AIA, but I still think that a discusssion regarding revocation validation should take place for RFC3280bis, eventually. Regards, -- Julien Stern > > As Tom pointed out: > > this fraudulently issued CRL will probably be validated whether it > > contains an AIA or not. > > This indicates once again that this is not an issue caused by the use of > AIA in CRLs but a generic CRL validation issue that belongs with RFC > 3280bis and not with the CRL-AIA draft. > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Julien Stern > > Sent: den 24 maj 2005 09:39 > > To: Tom Gindin > > Cc: ietf-pkix@imc.org > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > > > There is one scenario permitted by the "same trust anchor" > rule > > > for CRL signers which seems to me to be a serious security hole. > Let us > > > assume a valid CA which is a direct subordinate of one of the RP's > trust > > > anchors. This CA issues separate CRL's and ARL's, in a quite usual > way, > > > and issues cross certificates. After months or years of operation, > it > > > revokes one of its cross certificates because the subject's operator > has > > > gone rogue. That rogue subject then issues a fraudulent CRL Signing > > > certificate with the DN that the superior certificate has been using > to > > > sign ARL's, a public key which it has newly generated, and various > > > extensions including an SKID. It then issues an updated copy of an > old > > > ARL under the fraudulent CRL signer's certificate and with an AKID > > > matching the fraudulent signer's SKID. If the rogue can break into > the > > > repository where the CRL is expected, this fraudulently issued CRL > will > > > probably be validated whether it contains an AIA or not. It will > > > certainly pass the "same trust anchor" condition. > > > This scenario, in which a rogue CA issues an ARL certifiying > > that > > > its primary certificate has not been revoked and gets the ARL > accepted, > > is > > > possible under "same trust anchor" but not under "signed by path > > member". > > > > I agree with the validity of this scenario. I believe this is very > > close to the issue I attempted to bring on the list a short time ago. > > Of course, it assumes the existence of a rogue CA at some point in > time. > > > > Note that the CRL could be directly inserted into a "long term" > > signature (according to RFC3126 for example). This does not require > > a repository break-in and makes the "attack" even more realistic. > > > > Regards. > > > > -- > > Julien Stern > > > > > > > > Tom Gindin > > > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM > ----- > > > > > > > > > Tom Gindin > > > 05/23/2005 10:46 PM > > > > > > To: wpolk@nist.gov > > > cc: housley@vigilsec.com, ietf-pkix@imc.org, > kent@bbn.com, > > > stefans@microsoft.com > > > From: Tom Gindin/Watson/IBM@IBMUS > > > Subject: Re: WG Last Call: AIA CRL extension > > > > > > Tim: > > > > > > I should probably have brought this up earlier, but are we > > certain > > > that "same trust anchor" is a strong enough check that the CRL > signer is > > > the one expected by the issuing CA? While I was not in San Diego > when > > > this wording was included in the 3280 series, I do not really think > that > > > that check is strong enough. I would suggest instead that the CRL > > > signer's certificate needs to be directly issued by one of the CA's > in > > the > > > certification path back to the trust anchor used for the > certificate's > > > verification, or by that anchor itself, unless people have practical > > > experience with CA structures which that rule would prohibit. > Forcing > > the > > > CRL to be issued by the CA itself (as I understand Denis to have > > > suggested) prohibits the reasonable case where the CRL is issued by > a > > > hierarchical superior, so it is IMHO too strict. > > > I am personally not sure, FWIW, that a CRL should be > permitted > > to > > > be signed by a second-cousin certificate of the issuer's > certificate. > > By > > > analogy to the use of the terms in families, "sibling" certificates > > would > > > have the same issuer, "first-cousin" certificates would be issued by > > > siblings, and "second-cousin" certificates would be issued by first > > > cousins - so they are both three levels down from the same trust > anchor, > > > or from the last common CA in their paths. This issue is not newly > > caused > > > by CRL AIA, since the same issue can arise with CRL's containing > only > > > AKID. AIA only allows RP's to build a path (whether right or wrong) > > more > > > quickly. > > > In any case, nothing more than a note in Security > Considerations > > > is appropriate in any of our RFC's other than 3280 and its > successor. > > > > > > Tom Gindin > > > P.S. - The above views are mine, and not necessarily those of my > > employer > > > > > > > > > > > > > > > > > > Tim Polk > > > Sent by: owner-ietf-pkix@mail.imc.org > > > 05/10/2005 05:27 PM > > > > > > To: ietf-pkix@imc.org > > > cc: kent@bbn.com, stefans@microsoft.com, > > housley@vigilsec.com > > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > > > > > > This message initiates working group Last Call for the specification > > > "Internet X.509 Public Key Infrastructure: Authority Information > Access > > > CRL > > > Extension". While some issues raised in the working group are > > unresolved, > > > > > > the editors believe that rough consensus supports the current > > > specification. > > > > > > The URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > > > Last Call will run for (at least) two weeks. That is, Last Call will > not > > > close before May 24. > > > > > > Thanks, > > > > > > Tim Polk > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OIWQRa046883; Tue, 24 May 2005 11:32:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OIWQML046882; Tue, 24 May 2005 11:32:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4OIWQpQ046876 for ; Tue, 24 May 2005 11:32:26 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 1758 invoked by uid 0); 24 May 2005 18:32:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.156.225) by woodstock.binhost.com with SMTP; 24 May 2005 18:32:19 -0000 Message-Id: <6.2.1.2.2.20050524142144.068279f0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 24 May 2005 14:28:42 -0400 To: "Julien Stern" , Tom Gindin From: Russ Housley Subject: Re: WG Last Call: AIA CRL extension Cc: ietf-pkix@imc.org In-Reply-To: <20050524163852.GA13889@cryptolog.com> References: <20050524163852.GA13889@cryptolog.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Julien & Tom: Two points: 1. I understand this scenario. The change that you advocate as a countermeasure will prevent Indirect CRLs from working in scenarios that are intended. 2. This observation has noting to do with the CRL AIA extension. The attacker is inserting the bogus revocation information into the repository. Any relying party that uses that repository (when using the CRL AIA extension or any other configuration information to locate it) will get the bogus revocation information. If this is a concern, then it needs to be addressed in RFC3280bis, not here. Russ At 12:38 PM 5/24/2005, Julien Stern wrote: >On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > There is one scenario permitted by the "same trust anchor" rule > > for CRL signers which seems to me to be a serious security hole. Let us > > assume a valid CA which is a direct subordinate of one of the RP's trust > > anchors. This CA issues separate CRL's and ARL's, in a quite usual way, > > and issues cross certificates. After months or years of operation, it > > revokes one of its cross certificates because the subject's operator has > > gone rogue. That rogue subject then issues a fraudulent CRL Signing > > certificate with the DN that the superior certificate has been using to > > sign ARL's, a public key which it has newly generated, and various > > extensions including an SKID. It then issues an updated copy of an old > > ARL under the fraudulent CRL signer's certificate and with an AKID > > matching the fraudulent signer's SKID. If the rogue can break into the > > repository where the CRL is expected, this fraudulently issued CRL will > > probably be validated whether it contains an AIA or not. It will > > certainly pass the "same trust anchor" condition. > > This scenario, in which a rogue CA issues an ARL certifiying that > > its primary certificate has not been revoked and gets the ARL accepted, is > > possible under "same trust anchor" but not under "signed by path member". > >I agree with the validity of this scenario. I believe this is very >close to the issue I attempted to bring on the list a short time ago. >Of course, it assumes the existence of a rogue CA at some point in time. > >Note that the CRL could be directly inserted into a "long term" >signature (according to RFC3126 for example). This does not require >a repository break-in and makes the "attack" even more realistic. > >Regards. > >-- >Julien Stern > > > > > Tom Gindin > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > > > > > > Tom Gindin > > 05/23/2005 10:46 PM > > > > To: wpolk@nist.gov > > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, > > stefans@microsoft.com > > From: Tom Gindin/Watson/IBM@IBMUS > > Subject: Re: WG Last Call: AIA CRL extension > > > > Tim: > > > > I should probably have brought this up earlier, but are we certain > > that "same trust anchor" is a strong enough check that the CRL signer is > > the one expected by the issuing CA? While I was not in San Diego when > > this wording was included in the 3280 series, I do not really think that > > that check is strong enough. I would suggest instead that the CRL > > signer's certificate needs to be directly issued by one of the CA's in the > > certification path back to the trust anchor used for the certificate's > > verification, or by that anchor itself, unless people have practical > > experience with CA structures which that rule would prohibit. Forcing the > > CRL to be issued by the CA itself (as I understand Denis to have > > suggested) prohibits the reasonable case where the CRL is issued by a > > hierarchical superior, so it is IMHO too strict. > > I am personally not sure, FWIW, that a CRL should be permitted to > > be signed by a second-cousin certificate of the issuer's certificate. By > > analogy to the use of the terms in families, "sibling" certificates would > > have the same issuer, "first-cousin" certificates would be issued by > > siblings, and "second-cousin" certificates would be issued by first > > cousins - so they are both three levels down from the same trust anchor, > > or from the last common CA in their paths. This issue is not newly caused > > by CRL AIA, since the same issue can arise with CRL's containing only > > AKID. AIA only allows RP's to build a path (whether right or wrong) more > > quickly. > > In any case, nothing more than a note in Security Considerations > > is appropriate in any of our RFC's other than 3280 and its successor. > > > > Tom Gindin > > P.S. - The above views are mine, and not necessarily those of my employer > > > > > > > > > > > > Tim Polk > > Sent by: owner-ietf-pkix@mail.imc.org > > 05/10/2005 05:27 PM > > > > To: ietf-pkix@imc.org > > cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > This message initiates working group Last Call for the specification > > "Internet X.509 Public Key Infrastructure: Authority Information Access > > CRL > > Extension". While some issues raised in the working group are unresolved, > > > > the editors believe that rough consensus supports the current > > specification. > > > > The URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > Last Call will run for (at least) two weeks. That is, Last Call will not > > close before May 24. > > > > Thanks, > > > > Tim Polk > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OISQQn046572; Tue, 24 May 2005 11:28:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OISQ4S046571; Tue, 24 May 2005 11:28:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OISOQF046556 for ; Tue, 24 May 2005 11:28:25 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 19:28:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Last Call: AIA CRL extension Date: Tue, 24 May 2005 19:28:11 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call: AIA CRL extension Thread-Index: AcVghl4hQGnOpNmhQJqTj0yo+nDs+gABuyzA From: "Stefan Santesson" To: "Julien Stern" , "Tom Gindin" Cc: X-OriginalArrivalTime: 24 May 2005 18:28:19.0020 (UTC) FILETIME=[5BB5F0C0:01C5608E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OISPQF046566 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom and Julien, Since this is a repetition of the discussion we had before San Diego and I don't want to repeat it here. I'm not saying that this discussion is invalid; it is just directed towards the wrong draft. As Tom pointed out: > this fraudulently issued CRL will probably be validated whether it > contains an AIA or not. This indicates once again that this is not an issue caused by the use of AIA in CRLs but a generic CRL validation issue that belongs with RFC 3280bis and not with the CRL-AIA draft. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Julien Stern > Sent: den 24 maj 2005 09:39 > To: Tom Gindin > Cc: ietf-pkix@imc.org > Subject: Re: WG Last Call: AIA CRL extension > > > On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > > > There is one scenario permitted by the "same trust anchor" rule > > for CRL signers which seems to me to be a serious security hole. Let us > > assume a valid CA which is a direct subordinate of one of the RP's trust > > anchors. This CA issues separate CRL's and ARL's, in a quite usual way, > > and issues cross certificates. After months or years of operation, it > > revokes one of its cross certificates because the subject's operator has > > gone rogue. That rogue subject then issues a fraudulent CRL Signing > > certificate with the DN that the superior certificate has been using to > > sign ARL's, a public key which it has newly generated, and various > > extensions including an SKID. It then issues an updated copy of an old > > ARL under the fraudulent CRL signer's certificate and with an AKID > > matching the fraudulent signer's SKID. If the rogue can break into the > > repository where the CRL is expected, this fraudulently issued CRL will > > probably be validated whether it contains an AIA or not. It will > > certainly pass the "same trust anchor" condition. > > This scenario, in which a rogue CA issues an ARL certifiying > that > > its primary certificate has not been revoked and gets the ARL accepted, > is > > possible under "same trust anchor" but not under "signed by path > member". > > I agree with the validity of this scenario. I believe this is very > close to the issue I attempted to bring on the list a short time ago. > Of course, it assumes the existence of a rogue CA at some point in time. > > Note that the CRL could be directly inserted into a "long term" > signature (according to RFC3126 for example). This does not require > a repository break-in and makes the "attack" even more realistic. > > Regards. > > -- > Julien Stern > > > > > Tom Gindin > > > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > > > > > > Tom Gindin > > 05/23/2005 10:46 PM > > > > To: wpolk@nist.gov > > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, > > stefans@microsoft.com > > From: Tom Gindin/Watson/IBM@IBMUS > > Subject: Re: WG Last Call: AIA CRL extension > > > > Tim: > > > > I should probably have brought this up earlier, but are we > certain > > that "same trust anchor" is a strong enough check that the CRL signer is > > the one expected by the issuing CA? While I was not in San Diego when > > this wording was included in the 3280 series, I do not really think that > > that check is strong enough. I would suggest instead that the CRL > > signer's certificate needs to be directly issued by one of the CA's in > the > > certification path back to the trust anchor used for the certificate's > > verification, or by that anchor itself, unless people have practical > > experience with CA structures which that rule would prohibit. Forcing > the > > CRL to be issued by the CA itself (as I understand Denis to have > > suggested) prohibits the reasonable case where the CRL is issued by a > > hierarchical superior, so it is IMHO too strict. > > I am personally not sure, FWIW, that a CRL should be permitted > to > > be signed by a second-cousin certificate of the issuer's certificate. > By > > analogy to the use of the terms in families, "sibling" certificates > would > > have the same issuer, "first-cousin" certificates would be issued by > > siblings, and "second-cousin" certificates would be issued by first > > cousins - so they are both three levels down from the same trust anchor, > > or from the last common CA in their paths. This issue is not newly > caused > > by CRL AIA, since the same issue can arise with CRL's containing only > > AKID. AIA only allows RP's to build a path (whether right or wrong) > more > > quickly. > > In any case, nothing more than a note in Security Considerations > > is appropriate in any of our RFC's other than 3280 and its successor. > > > > Tom Gindin > > P.S. - The above views are mine, and not necessarily those of my > employer > > > > > > > > > > > > Tim Polk > > Sent by: owner-ietf-pkix@mail.imc.org > > 05/10/2005 05:27 PM > > > > To: ietf-pkix@imc.org > > cc: kent@bbn.com, stefans@microsoft.com, > housley@vigilsec.com > > Subject: WG Last Call: AIA CRL extension > > > > > > > > > > This message initiates working group Last Call for the specification > > "Internet X.509 Public Key Infrastructure: Authority Information Access > > CRL > > Extension". While some issues raised in the working group are > unresolved, > > > > the editors believe that rough consensus supports the current > > specification. > > > > The URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > > > Last Call will run for (at least) two weeks. That is, Last Call will not > > close before May 24. > > > > Thanks, > > > > Tim Polk > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OHpleL040117; Tue, 24 May 2005 10:51:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OHplEq040116; Tue, 24 May 2005 10:51:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OHpjDJ040110 for ; Tue, 24 May 2005 10:51:46 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft6.fr.colt.net with ESMTP id j4OHpep31682 for ; Tue, 24 May 2005 19:51:45 +0200 Message-ID: <429369AA.1030502@free.fr> Date: Tue, 24 May 2005 19:51:38 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050517 MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension References: <20050524163852.GA13889@cryptolog.com> In-Reply-To: <20050524163852.GA13889@cryptolog.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Julien Stern wrote: >Note that the CRL could be directly inserted into a "long term" >signature (according to RFC3126 for example). This does not require >a repository break-in and makes the "attack" even more realistic. > > Or in a CMS messages, together with the certificates that validate it. The problem is not restricted to the AIA. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OH3Epr024900; Tue, 24 May 2005 10:03:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OH3EoB024899; Tue, 24 May 2005 10:03:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OH36PG024877 for ; Tue, 24 May 2005 10:03:13 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 744A0352A9; Wed, 25 May 2005 05:03:05 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17304-21; Wed, 25 May 2005 05:03:05 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 5C3ED35272; Wed, 25 May 2005 05:03:05 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 25E873774B; Wed, 25 May 2005 05:03:05 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DacoF-0004nR-00; Wed, 25 May 2005 05:03:15 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, sroberts@certicom.com Subject: Re: Trying to relate PKCS & IETF standards to encoding rules In-Reply-To: <20050524161310.GA31429@certicom.com> Message-Id: Date: Wed, 25 May 2005 05:03:15 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam Roberts writes: >Maybe an informational I-D would be useful to help bring some consistency to >the practice. Given the deployed base, I doubt it'd make much difference to existing implementations. What you could do though is document current practice to help others who're coming along and want to implement something that interoperates. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGed3P020785; Tue, 24 May 2005 09:40:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OGedd2020784; Tue, 24 May 2005 09:40:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGecAL020719 for ; Tue, 24 May 2005 09:40:38 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 17:40:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: FW: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates Date: Tue, 24 May 2005 17:40:24 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates Thread-Index: AcVgDSuDicrMu1CBT4uAbJVfP4XUNgAcDOAgAABndaA= From: "Stefan Santesson" To: X-OriginalArrivalTime: 24 May 2005 16:40:32.0247 (UTC) FILETIME=[4D36B070:01C5607F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4OGecAL020776 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Forwarding this also to the pkix WG for those who don't follow the Kerberos list. /Stefan -----Original Message----- From: Stefan Santesson Sent: den 24 maj 2005 09:37 To: 'Sam Hartman' Cc: Nicolas Williams; Liqiang(Larry) Zhu; ietf-krb-wg@anl.gov Subject: RE: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates Sam, Reading your reply actually makes me think that we are in agreement. I agree that it is impossible to bind to a SRV record unless a symbolic name has been defined and the security considerations assigned to that definition should always be followed. However, I can't see that you need to do more than that. Once the symbolic name has been defined and it is used according to it's definition and security considerations to discover services, then I can't se any negative security effects from binding that SRV RR name to a public key certificate to enable authentication of the host's authorization to deliver that service. In summary I don't think it is reasonable for a standard defining an otherName for a SRV RR to explicitly define what services it can be used with. But I would agree to describe the principles in the security considerations. /Stefan > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: den 23 maj 2005 20:03 > To: Stefan Santesson > Cc: Nicolas Williams; Liqiang(Larry) Zhu; ietf-krb-wg@anl.gov > Subject: Re: Required binding method - Was RE: PKINIT-26 changes: > identifying the kdc certificates > > >>>>> "Stefan" == Stefan Santesson writes: > > Stefan> Sam, > > >> I hope the PKIX working group does not approve a version of the > >> SRV OtherName that would allow it to be used with an > >> application without some standard enabling such usage. So I > >> would expect some document to explicitly mention that it can be > >> used with pkinit. But I agree that if PKIX were to approve an > >> overly broad standard, the current text would allow it to be > >> used. > >> > >> > > Stefan> [Stefan] I don't think you can constrain its usage in a > Stefan> PKIX RFC or force some RFC to enable it for each service > Stefan> type. > > Stefan> RFC 2782 already makes it possible to bind to a service > Stefan> only based on service name, protocol and domain. There are > Stefan> no limitations to that. > > > Please See the following text from RFC 2782: > > > Applicability Statement > > In general, it is expected that SRV records will be used by clients > for applications where the relevant protocol specification > indicates > that clients should use the SRV record. Such specification MUST > define the symbolic name to be used in the Service field of > the SRV > record as described below. It also MUST include security > considerations. Service SRV records SHOULD NOT be used > in the absence > of such specification. > > > > So your proposal clearly should not be used for applications that do > not use SRV records in the first place. Some applications that use > SRV records (most of the IMPP protocols fall into this examlpe) > already specify how certificates should be bound to these > applications. It is undesirable to have two methods of doing the same > certificate binding without compelling reason to do so.Failing this > would lead to decreased interoperability. From this I conclude that > your name type should only be used when explicitly specified. Things > are of course more fuzzy for applications that do not have formal > published specifications. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGd7wL019774; Tue, 24 May 2005 09:39:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OGd7W4019772; Tue, 24 May 2005 09:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGd6Q1019734 for ; Tue, 24 May 2005 09:39:06 -0700 (PDT) (envelope-from julien.stern@cryptolog.com) Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id E0C8F62D07; Tue, 24 May 2005 18:39:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id CC9DA440ED; Tue, 24 May 2005 18:39:37 +0200 (CEST) Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19169-04; Tue, 24 May 2005 18:39:31 +0200 (CEST) Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id D7FB7440AF; Tue, 24 May 2005 18:39:31 +0200 (CEST) Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 24 May 2005 18:38:58 +0200 From: "Julien Stern" Date: Tue, 24 May 2005 18:38:58 +0200 To: Tom Gindin Cc: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension Message-ID: <20050524163852.GA13889@cryptolog.com> Mail-Followup-To: Julien Stern , Tom Gindin , ietf-pkix@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Tue, May 24, 2005 at 10:36:16AM -0400, Tom Gindin wrote: > > There is one scenario permitted by the "same trust anchor" rule > for CRL signers which seems to me to be a serious security hole. Let us > assume a valid CA which is a direct subordinate of one of the RP's trust > anchors. This CA issues separate CRL's and ARL's, in a quite usual way, > and issues cross certificates. After months or years of operation, it > revokes one of its cross certificates because the subject's operator has > gone rogue. That rogue subject then issues a fraudulent CRL Signing > certificate with the DN that the superior certificate has been using to > sign ARL's, a public key which it has newly generated, and various > extensions including an SKID. It then issues an updated copy of an old > ARL under the fraudulent CRL signer's certificate and with an AKID > matching the fraudulent signer's SKID. If the rogue can break into the > repository where the CRL is expected, this fraudulently issued CRL will > probably be validated whether it contains an AIA or not. It will > certainly pass the "same trust anchor" condition. > This scenario, in which a rogue CA issues an ARL certifiying that > its primary certificate has not been revoked and gets the ARL accepted, is > possible under "same trust anchor" but not under "signed by path member". I agree with the validity of this scenario. I believe this is very close to the issue I attempted to bring on the list a short time ago. Of course, it assumes the existence of a rogue CA at some point in time. Note that the CRL could be directly inserted into a "long term" signature (according to RFC3126 for example). This does not require a repository break-in and makes the "attack" even more realistic. Regards. -- Julien Stern > > Tom Gindin > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > > > Tom Gindin > 05/23/2005 10:46 PM > > To: wpolk@nist.gov > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, > stefans@microsoft.com > From: Tom Gindin/Watson/IBM@IBMUS > Subject: Re: WG Last Call: AIA CRL extension > > Tim: > > I should probably have brought this up earlier, but are we certain > that "same trust anchor" is a strong enough check that the CRL signer is > the one expected by the issuing CA? While I was not in San Diego when > this wording was included in the 3280 series, I do not really think that > that check is strong enough. I would suggest instead that the CRL > signer's certificate needs to be directly issued by one of the CA's in the > certification path back to the trust anchor used for the certificate's > verification, or by that anchor itself, unless people have practical > experience with CA structures which that rule would prohibit. Forcing the > CRL to be issued by the CA itself (as I understand Denis to have > suggested) prohibits the reasonable case where the CRL is issued by a > hierarchical superior, so it is IMHO too strict. > I am personally not sure, FWIW, that a CRL should be permitted to > be signed by a second-cousin certificate of the issuer's certificate. By > analogy to the use of the terms in families, "sibling" certificates would > have the same issuer, "first-cousin" certificates would be issued by > siblings, and "second-cousin" certificates would be issued by first > cousins - so they are both three levels down from the same trust anchor, > or from the last common CA in their paths. This issue is not newly caused > by CRL AIA, since the same issue can arise with CRL's containing only > AKID. AIA only allows RP's to build a path (whether right or wrong) more > quickly. > In any case, nothing more than a note in Security Considerations > is appropriate in any of our RFC's other than 3280 and its successor. > > Tom Gindin > P.S. - The above views are mine, and not necessarily those of my employer > > > > > > Tim Polk > Sent by: owner-ietf-pkix@mail.imc.org > 05/10/2005 05:27 PM > > To: ietf-pkix@imc.org > cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com > Subject: WG Last Call: AIA CRL extension > > > > > This message initiates working group Last Call for the specification > "Internet X.509 Public Key Infrastructure: Authority Information Access > CRL > Extension". While some issues raised in the working group are unresolved, > > the editors believe that rough consensus supports the current > specification. > > The URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > Last Call will run for (at least) two weeks. That is, Last Call will not > close before May 24. > > Thanks, > > Tim Polk > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OGDT2o006534; Tue, 24 May 2005 09:13:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OGDTvS006533; Tue, 24 May 2005 09:13:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4OGDSQR006510 for ; Tue, 24 May 2005 09:13:28 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 3B1B2100B7 for ; Tue, 24 May 2005 12:13:24 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22742-25 for ; Tue, 24 May 2005 12:13:11 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 5612A10084 for ; Tue, 24 May 2005 12:13:11 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005052412122949-37465 ; Tue, 24 May 2005 12:12:29 -0400 Date: Tue, 24 May 2005 12:13:10 -0400 From: Sam Roberts To: "'ietf-pkix@imc.org'" Subject: Re: Trying to relate PKCS & IETF standards to encoding rules Message-ID: <20050524161310.GA31429@certicom.com> Mail-Followup-To: "'ietf-pkix@imc.org'" References: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> Mime-Version: 1.0 In-Reply-To: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/24/2005 12:12:29 PM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/24/2005 12:12:30 PM, Serialize complete at 05/24/2005 12:12:30 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Goulet Walter-CWG009 , on Tue, May 24, 2005 at 09:57:13AM -0500: > Is there a set of RFCs that describes these standards? Maybe there is > a standard describing in general how to encode from DER -> PEM and > describes how the headers/footers are built. Not that I'm aware of, the names to use in the PEM headers are "customary", you have to see whats out there (and there is a fair amount of variation), and do what others do. Maybe an informational I-D would be useful to help bring some consistency to the practice. Cheers, Sam -- http://www.certicom.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFu6Qe004827; Tue, 24 May 2005 08:56:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OFu6fa004826; Tue, 24 May 2005 08:56:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFu4aT004819 for ; Tue, 24 May 2005 08:56:05 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA44396; Tue, 24 May 2005 18:11:06 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005052417555722:408 ; Tue, 24 May 2005 17:55:57 +0200 Message-ID: <42934ECA.3020508@bull.net> Date: Tue, 24 May 2005 17:56:58 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Tom Gindin CC: ietf-pkix@imc.org Subject: Re: WG Last Call: AIA CRL extension References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/05/2005 17:55:57, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/05/2005 17:55:58, Serialize complete at 24/05/2005 17:55:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tom, Thank you for bringing water to my mill. :-) To respond to your previous e-mail, you said: "Forcing the CRL to be issued by the CA itself (as I understand Denis to have suggested) prohibits the reasonable case where the CRL is issued by a hierarchical superior, so it is IMHO too strict". I am saying that this case is secure. Expending it to the certification tree, would need to demonstrate that it is secure, ... and this has not be yet done at the moment (in particular for the case of same DN for the CRL issuer name). Denis > There is one scenario permitted by the "same trust anchor" rule > for CRL signers which seems to me to be a serious security hole. Let us > assume a valid CA which is a direct subordinate of one of the RP's trust > anchors. This CA issues separate CRL's and ARL's, in a quite usual way, > and issues cross certificates. After months or years of operation, it > revokes one of its cross certificates because the subject's operator has > gone rogue. That rogue subject then issues a fraudulent CRL Signing > certificate with the DN that the superior certificate has been using to > sign ARL's, a public key which it has newly generated, and various > extensions including an SKID. It then issues an updated copy of an old > ARL under the fraudulent CRL signer's certificate and with an AKID > matching the fraudulent signer's SKID. If the rogue can break into the > repository where the CRL is expected, this fraudulently issued CRL will > probably be validated whether it contains an AIA or not. It will > certainly pass the "same trust anchor" condition. > This scenario, in which a rogue CA issues an ARL certifiying that > its primary certificate has not been revoked and gets the ARL accepted, is > possible under "same trust anchor" but not under "signed by path member". > > Tom Gindin > > ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- > > > Tom Gindin > 05/23/2005 10:46 PM > > To: wpolk@nist.gov > cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, > stefans@microsoft.com > From: Tom Gindin/Watson/IBM@IBMUS > Subject: Re: WG Last Call: AIA CRL extension > > Tim: > > I should probably have brought this up earlier, but are we certain > that "same trust anchor" is a strong enough check that the CRL signer is > the one expected by the issuing CA? While I was not in San Diego when > this wording was included in the 3280 series, I do not really think that > that check is strong enough. I would suggest instead that the CRL > signer's certificate needs to be directly issued by one of the CA's in the > certification path back to the trust anchor used for the certificate's > verification, or by that anchor itself, unless people have practical > experience with CA structures which that rule would prohibit. Forcing the > CRL to be issued by the CA itself (as I understand Denis to have > suggested) prohibits the reasonable case where the CRL is issued by a > hierarchical superior, so it is IMHO too strict. > I am personally not sure, FWIW, that a CRL should be permitted to > be signed by a second-cousin certificate of the issuer's certificate. By > analogy to the use of the terms in families, "sibling" certificates would > have the same issuer, "first-cousin" certificates would be issued by > siblings, and "second-cousin" certificates would be issued by first > cousins - so they are both three levels down from the same trust anchor, > or from the last common CA in their paths. This issue is not newly caused > by CRL AIA, since the same issue can arise with CRL's containing only > AKID. AIA only allows RP's to build a path (whether right or wrong) more > quickly. > In any case, nothing more than a note in Security Considerations > is appropriate in any of our RFC's other than 3280 and its successor. > > Tom Gindin > P.S. - The above views are mine, and not necessarily those of my employer > > > > > > Tim Polk > Sent by: owner-ietf-pkix@mail.imc.org > 05/10/2005 05:27 PM > > To: ietf-pkix@imc.org > cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com > Subject: WG Last Call: AIA CRL extension > > > > > This message initiates working group Last Call for the specification > "Internet X.509 Public Key Infrastructure: Authority Information Access > CRL > Extension". While some issues raised in the working group are unresolved, > > the editors believe that rough consensus supports the current > specification. > > The URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt > > Last Call will run for (at least) two weeks. That is, Last Call will not > close before May 24. > > Thanks, > > Tim Polk > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFZakE003757; Tue, 24 May 2005 08:35:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OFZaCP003756; Tue, 24 May 2005 08:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFZZrK003742 for ; Tue, 24 May 2005 08:35:35 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4OFZS2o008998; Tue, 24 May 2005 11:35:29 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> References: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> Date: Tue, 24 May 2005 11:35:27 -0400 To: Goulet Walter-CWG009 From: Stephen Kent Subject: Re: Trying to relate PKCS & IETF standards to encoding rules Cc: "'ietf-pkix@imc.org'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Walter, The ITU-T X.509 and the IETF PKIX specs call for binary encoding of the ASN.1 for certs and CRLs, specifically DER, as you noted. PEM, which is now historical, also called for binary encoding (DER) of the ASN.1, and then specified the base64 encoding of the binary representation for "safe" carriage over SMTP. So the two sets of specs were not in conflict. It's just that PEM specified an additional layer of encoding for content transfer purposes, which is what MIME does as well, when necessary. DER to base64 is an easy encoding, because base64 takes any binary sytring and says how to encode it as text. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFZSNW003740; Tue, 24 May 2005 08:35:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OFZS61003739; Tue, 24 May 2005 08:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4OFZRxF003733 for ; Tue, 24 May 2005 08:35:28 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 26223 invoked by uid 0); 24 May 2005 15:35:22 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.170.22) by woodstock.binhost.com with SMTP; 24 May 2005 15:35:22 -0000 Message-Id: <6.2.1.2.2.20050524104606.03fab960@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 24 May 2005 11:35:10 -0400 To: Sam Hartman From: Russ Housley Subject: Re: AD Review for draft-ietf-pkix-rfc3770bis Cc: timmoore@microsoft.com, ietf-pkix@imc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam: Thanks for the AD review. It has improved the document. Here is how I addressed each of your comments. I have CCed the PKIX mail list to stan any WG member can raise the alarm if they do not like the way that any comment was resolved. >The document sites RFC 2284, not RFC 3748 which supersedes 2284. In >addition the document's terminology is inconsistent with RFC 3748. >EAP defines an exchange between a peer and an EAP server. The term >client is not typically used. My preference is that you fix the >terminology but this is not a requirement. The reference does need to >be updated. Also, I wonder whether it should be normative. [EAP] changed to normative, and it references RFC 3748. The terminology was updated to use "supplicant" when talking about 802.1X and "peer" when talking about EAP. The term "EAP server" is also used. >section 1: >There are two places in an EAP protocol where it seems obvious you >might want to use a certificate: the peer might want a certificate to >prove its identity to the EAP server and a EAP server might want a >certificate to prove its identity to the peer. This document deals >with the first case but does not make that clear. >The following change helps. > >s/for/by/ >old: > Automated selection of certificates for PPP and IEEE 802.1X clients > is highly desirable. By using certificate extensions to identify the >new: > Automated selection of certificates by PPP and IEEE 802.1X clients > is highly desirable. By using certificate extensions to identify the The "client" in this sentence causes problems with your earlier comment. How about: "Automated selection of client certificates for use with PPP and IEEE 802.1X is highly desirable." >I'd like to see text like the following worked into section 1 >though to make things completely clear. > > This document defines key usage values and certificate extensions to > be used in certificates issued to clients of PPP and wireless > networks. How about a new paragraph at the end of section 1: "This document defines extended key usage values and a WLAN-specific certificate extension for use in certificates issued to clients of PPP and WLANs." >section 2: > >Do these key purpose IDs apply to EAP server certificates or to client >certificates or to both? The intent was peer certificates. I do not recall any discussion of EAP server certificates using them. Proposed revision: "Inclusion of the EAP over PPP value indicates that the certified public key is appropriate for use by a peer with EAP in the PPP environment. The inclusion of the EAPOL value indicates that the certified public key is appropriate for use by a peer with the EAP in the LAN environment. Inclusion of both values indicates that the certified public key is appropriate for use by a peer in either of the environments." >The text quotes the description of extend key usages from RFC 3280 and >points out that an application can require extended key usage and a >particular KeyPurposeId. Is the intent for this to be defined by the >EAP method, the EAP method implementation, site policy, or something >else? How should implementers handle the situation where the EAP >implementation does not know what environment it is being used in? >(I'm not sure whether this situation is actually common.) I do not think there is a problem here. EAP methods that use certificates can require the presence of a particular KeyPurposeId, but I do not think that any have done so. >The extended key usage should presumably be checked both by the EAP peer >and the EAP server. The text should probably make this more clear. I see it more as a selection criteria when more than one certificate is available. >Section 3: > >The following text seems to be trying to imply that the ssid extension >can only be used with the extended key usage extension. If that's >true the requirement needs to be stated more clearly. However I don't >understand why you would want that requirement--it seems reasonable to >use the ssid extension with an application (EAP method) that does not >require extended key usage. > > When more than one certificate includes an extended key usage > extension indicating that the certified public key is appropriate for > use with the EAP in the LAN environment, then the list of SSIDs MAY > be used to select the correct certificate for authentication in a > particular WLAN. It is not a requirement. It is trying to say that the KeyPurposeId could narrow the certificate selection, and then this extension could provide further assistance. It is perfectly fine for only one of the extensions to be used. I suggest replacing the first paragraph of setcion 3 with: The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key certificate extension is always non-critical. It contains a list of SSIDs. The list of SSIDs MAY be used to select the correct certificate for authentication in a particular WLAN. If the extended key usage extension appears in the same certificate as the SSID extension, then the extended key usage extension MUST indicate that the certified public key is appropriate for use with the EAP in the LAN environment by including the id-kp-eapOverLAN KeyPurposeId value. -- Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEvLSn000610; Tue, 24 May 2005 07:57:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OEvL4i000609; Tue, 24 May 2005 07:57:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from motgate8.mot.com (motgate8.mot.com [129.188.136.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEvJPi000603 for ; Tue, 24 May 2005 07:57:20 -0700 (PDT) (envelope-from Walter.Goulet@motorola.com) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate7) with ESMTP id j4OF59P7026815 for ; Tue, 24 May 2005 08:05:10 -0700 (MST) Received: from il02exm15.corp.mot.com (il02exm15.corp.mot.com [10.0.111.27]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id j4OF19kj004327 for ; Tue, 24 May 2005 10:01:09 -0500 (CDT) Received: by il02exm15.corp.mot.com with Internet Mail Service (5.5.2657.72) id ; Tue, 24 May 2005 09:57:17 -0500 Message-ID: <53F44AF77A9F9B458DCE1910C2E6263807D42EAA@il02exm15.corp.mot.com> From: Goulet Walter-CWG009 To: "'ietf-pkix@imc.org'" Subject: Trying to relate PKCS & IETF standards to encoding rules Date: Tue, 24 May 2005 09:57:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C56070.C8FDA77C" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C56070.C8FDA77C Content-Type: text/plain Hi, I'm trying to grasp how certificates and associated artifacts of PKI (private keys, CRLs, CSRs etc) are encoded and how the standards are related to eachother. My understanding of the relationships is: Standards for x.509 (spec. in RFC3280 and ITU-T x.509) as well as the various PKCS standards developed primarily by RSA labs are specified as ASN.1. ASN.1 cannot be directly encoded since it consists of abstract types, so the standards specify DER (which is a more restrictive BER encoding; basically it's a binary representation of ASN.1 values). PEM (defined in RFC 1421 - 1424, but what I care about is in 1421) defines a way to encode binary cryptographically sensitive data so it can be transported in text over SMTP. However, I haven't seen standards, notably for x.509 itself, that describe how to encode data from DER -> PEM. I suspect there must be a standard since for x.509 files there is a standard 'BEGIN CERTIFICATE/END CERTIFICATE' header and footer for certificates (and similarly, private keys and CSRs). Is there a set of RFCs that describes these standards? Maybe there is a standard describing in general how to encode from DER -> PEM and describes how the headers/footers are built. Any help would be appreciated. Thanks, - Walter Goulet walter.goulet@motorola.com Nextel: (847)366-9519 Pvt. ID 9519 Desk: (847)576-7036 ------_=_NextPart_001_01C56070.C8FDA77C Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI2NTguMiI+DQo8VElUTEU+VHJ5aW5nIHRv IHJlbGF0ZSBQS0NTICZhbXA7IElFVEYgc3RhbmRhcmRzIHRvIGVuY29kaW5nIHJ1bGVzPC9USVRM RT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkhpLDwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5JJ20gdHJ5aW5nIHRv IGdyYXNwIGhvdyBjZXJ0aWZpY2F0ZXMgYW5kIGFzc29jaWF0ZWQgYXJ0aWZhY3RzIG9mIFBLSTwv Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPihwcml2YXRlIGtleXMsIENSTHMs IENTUnMgZXRjKSBhcmUgZW5jb2RlZCBhbmQgaG93IHRoZSBzdGFuZGFyZHMgYXJlPC9GT05UPg0K PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+cmVsYXRlZCB0byBlYWNob3RoZXIuPC9GT05U Pg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPk15IHVuZGVyc3RhbmRpbmcg b2YgdGhlIHJlbGF0aW9uc2hpcHMgaXM6PC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIg RkFDRT0iQXJpYWwiPlN0YW5kYXJkcyBmb3IgeC41MDkgKHNwZWMuIGluIFJGQzMyODAgYW5kIElU VS1UIHguNTA5KSBhcyB3ZWxsIGFzIHRoZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i QXJpYWwiPnZhcmlvdXMgUEtDUyBzdGFuZGFyZHMgZGV2ZWxvcGVkIHByaW1hcmlseSBieSBSU0Eg bGFicyBhcmUgc3BlY2lmaWVkPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ YXMgQVNOLjEuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkFT Ti4xIGNhbm5vdCBiZSBkaXJlY3RseSBlbmNvZGVkIHNpbmNlIGl0IGNvbnNpc3RzIG9mIGFic3Ry YWN0IHR5cGVzLDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnNvIHRoZSBz dGFuZGFyZHMgc3BlY2lmeSBERVIgKHdoaWNoIGlzIGEgbW9yZSByZXN0cmljdGl2ZSBCRVI8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5lbmNvZGluZzsgYmFzaWNhbGx5IGl0 J3MgYSBiaW5hcnkgcmVwcmVzZW50YXRpb24gb2YgQVNOLjEgdmFsdWVzKS48L0ZPTlQ+DQo8L1A+ DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+UEVNIChkZWZpbmVkIGluIFJGQyAxNDIx IC0gMTQyNCwgYnV0IHdoYXQgSSBjYXJlIGFib3V0IGlzIGluIDE0MjEpPC9GT05UPg0KPEJSPjxG T05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+ZGVmaW5lcyBhIHdheSB0byBlbmNvZGUgYmluYXJ5IGNy eXB0b2dyYXBoaWNhbGx5IHNlbnNpdGl2ZSBkYXRhIHNvIGl0PC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9MiBGQUNFPSJBcmlhbCI+Y2FuIGJlIHRyYW5zcG9ydGVkIGluIHRleHQgb3ZlciBTTVRQLjwv Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Ib3dldmVyLCBJIGhh dmVuJ3Qgc2VlbiBzdGFuZGFyZHMsIG5vdGFibHkgZm9yIHguNTA5IGl0c2VsZiwgdGhhdDwvRk9O VD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmRlc2NyaWJlIGhvdyB0byBlbmNvZGUg ZGF0YSBmcm9tIERFUiAtJmd0OyBQRU0uPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIg RkFDRT0iQXJpYWwiPkkgc3VzcGVjdCB0aGVyZSBtdXN0IGJlIGEgc3RhbmRhcmQgc2luY2UgZm9y IHguNTA5IGZpbGVzIHRoZXJlIGlzIGE8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFy aWFsIj5zdGFuZGFyZCAnQkVHSU4gQ0VSVElGSUNBVEUvRU5EIENFUlRJRklDQVRFJyBoZWFkZXIg YW5kIGZvb3RlciBmb3I8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5jZXJ0 aWZpY2F0ZXMgKGFuZCBzaW1pbGFybHksIHByaXZhdGUga2V5cyBhbmQgQ1NScykuPC9GT05UPg0K PC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPklzIHRoZXJlIGEgc2V0IG9mIFJG Q3MgdGhhdCBkZXNjcmliZXMgdGhlc2Ugc3RhbmRhcmRzPyBNYXliZSB0aGVyZSBpczwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmEgc3RhbmRhcmQgZGVzY3JpYmluZyBpbiBn ZW5lcmFsIGhvdyB0byBlbmNvZGUgZnJvbSBERVIgLSZndDsgUEVNIGFuZDwvRk9OVD4NCjxCUj48 Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPmRlc2NyaWJlcyBob3cgdGhlIGhlYWRlcnMvZm9vdGVy cyBhcmUgYnVpbHQuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi PkFueSBoZWxwIHdvdWxkIGJlIGFwcHJlY2lhdGVkLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yIEZBQ0U9IkFyaWFsIj5UaGFua3MsPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF PSJBcmlhbCI+LTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPldhbHRlciBH b3VsZXQ8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj53YWx0ZXIuZ291bGV0 QG1vdG9yb2xhLmNvbSBOZXh0ZWw6ICg4NDcpMzY2LTk1MTkgUHZ0LiBJRCA5NTE5PC9GT05UPg0K PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+RGVzazogKDg0Nyk1NzYtNzAzNjwvRk9OVD4N CjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C56070.C8FDA77C-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEaRbM098522; Tue, 24 May 2005 07:36:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OEaRq9098521; Tue, 24 May 2005 07:36:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OEaPbW098507 for ; Tue, 24 May 2005 07:36:26 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEaKQJ028816 for ; Tue, 24 May 2005 10:36:20 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4OEaKLu144790 for ; Tue, 24 May 2005 10:36:20 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4OEaJtR003099 for ; Tue, 24 May 2005 10:36:20 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4OEaJgZ003087 for ; Tue, 24 May 2005 10:36:19 -0400 To: ietf-pkix@imc.org MIME-Version: 1.0 Subject: Re: WG Last Call: AIA CRL extension X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Tue, 24 May 2005 10:36:16 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/24/2005 10:36:19, Serialize complete at 05/24/2005 10:36:19 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There is one scenario permitted by the "same trust anchor" rule for CRL signers which seems to me to be a serious security hole. Let us assume a valid CA which is a direct subordinate of one of the RP's trust anchors. This CA issues separate CRL's and ARL's, in a quite usual way, and issues cross certificates. After months or years of operation, it revokes one of its cross certificates because the subject's operator has gone rogue. That rogue subject then issues a fraudulent CRL Signing certificate with the DN that the superior certificate has been using to sign ARL's, a public key which it has newly generated, and various extensions including an SKID. It then issues an updated copy of an old ARL under the fraudulent CRL signer's certificate and with an AKID matching the fraudulent signer's SKID. If the rogue can break into the repository where the CRL is expected, this fraudulently issued CRL will probably be validated whether it contains an AIA or not. It will certainly pass the "same trust anchor" condition. This scenario, in which a rogue CA issues an ARL certifiying that its primary certificate has not been revoked and gets the ARL accepted, is possible under "same trust anchor" but not under "signed by path member". Tom Gindin ----- Forwarded by Tom Gindin/Watson/IBM on 05/24/2005 10:13 AM ----- Tom Gindin 05/23/2005 10:46 PM To: wpolk@nist.gov cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, stefans@microsoft.com From: Tom Gindin/Watson/IBM@IBMUS Subject: Re: WG Last Call: AIA CRL extension Tim: I should probably have brought this up earlier, but are we certain that "same trust anchor" is a strong enough check that the CRL signer is the one expected by the issuing CA? While I was not in San Diego when this wording was included in the 3280 series, I do not really think that that check is strong enough. I would suggest instead that the CRL signer's certificate needs to be directly issued by one of the CA's in the certification path back to the trust anchor used for the certificate's verification, or by that anchor itself, unless people have practical experience with CA structures which that rule would prohibit. Forcing the CRL to be issued by the CA itself (as I understand Denis to have suggested) prohibits the reasonable case where the CRL is issued by a hierarchical superior, so it is IMHO too strict. I am personally not sure, FWIW, that a CRL should be permitted to be signed by a second-cousin certificate of the issuer's certificate. By analogy to the use of the terms in families, "sibling" certificates would have the same issuer, "first-cousin" certificates would be issued by siblings, and "second-cousin" certificates would be issued by first cousins - so they are both three levels down from the same trust anchor, or from the last common CA in their paths. This issue is not newly caused by CRL AIA, since the same issue can arise with CRL's containing only AKID. AIA only allows RP's to build a path (whether right or wrong) more quickly. In any case, nothing more than a note in Security Considerations is appropriate in any of our RFC's other than 3280 and its successor. Tom Gindin P.S. - The above views are mine, and not necessarily those of my employer Tim Polk Sent by: owner-ietf-pkix@mail.imc.org 05/10/2005 05:27 PM To: ietf-pkix@imc.org cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com Subject: WG Last Call: AIA CRL extension This message initiates working group Last Call for the specification "Internet X.509 Public Key Infrastructure: Authority Information Access CRL Extension". While some issues raised in the working group are unresolved, the editors believe that rough consensus supports the current specification. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt Last Call will run for (at least) two weeks. That is, Last Call will not close before May 24. Thanks, Tim Polk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O408Ph053502; Mon, 23 May 2005 21:00:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4O4089c053501; Mon, 23 May 2005 21:00:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O4067U053442 for ; Mon, 23 May 2005 21:00:07 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 May 2005 05:00:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Tue, 24 May 2005 04:59:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVgDlSoP4TVHzHCRAOP3e5pHb6BCgABiZ6g From: "Stefan Santesson" To: "Tom Gindin" Cc: "Sam Hartman" , X-OriginalArrivalTime: 24 May 2005 04:00:00.0481 (UTC) FILETIME=[0E8FC510:01C56015] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4O4077U053493 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, The intention was actually primary to include the lookup key. Yes there are some clarifications needed in this aspect but I waited with trying to formulate the limitations until we have got a bit further towards accepting the work item. Thanks for noticing the issue. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Tom Gindin [mailto:tgindin@us.ibm.com] > Sent: den 23 maj 2005 20:11 > To: Stefan Santesson > Cc: Sam Hartman; ietf-pkix@imc.org > Subject: RE: Request for new work item - Defining an SRV RR otherName > > Stefan: > > Maybe I'm being a bit thick here, but do you really intend to > include the entire RR contents, including the weight, target and port, in > this otherName? Or do you intend to include only the lookup key > (_service._protocol.DNSName) instead? Some of your wording makes IMHO > more sense in that case, and the assertion you're conveying is "the CA > issuer has authorized this entity to provide this service for this > domain". > Whatever may be the case for Kerberos, I don't see why this > feature is problematic for (say) LDAP, except insofar as it's an argument > for name constraints. I do think that you'd need to state that the use of > this field in a certificate is governed by DNSName name constraints. > > Tom Gindin > > > > > > > "Stefan Santesson" > Sent by: owner-ietf-pkix@mail.imc.org > 05/20/2005 06:44 PM > > To: "Sam Hartman" , > cc: > Subject: RE: Request for new work item - Defining an SRV RR > otherName > > > Sam, > > My recollection of this issue is a bit different from yours. > > The central need here is to enable the KDC to express in a certificate > the fact that it is a KDC in a way that male sense to clients. > > In a traditional Kerberos environment the KDC can be known as a KDC > since it can demonstrate knowledge of the user's key. > > In PKI initiated Kerberos, this property is lost. > > If the client knows the host name, IP address or any other identity of > the KDC, which can be mapped to information in the KDC certificate, then > we are good and appropriate binding is possible. > > However, from what I have learned, we may face situations where a client > only know the name of the domain it wants to access and the fact that it > looks for a PKINIT enabled KDC. In this case it is assumed that the > client would do a SRV RR query to the DNS to get the host name of the > currently available KDC. > > If the SRV RR is NOT the appropriate name to bind to in this case, then > my question is what the alternative is. > > > Finally, the reason to do this in PKIX is since this in principle is a > generic way of service discovery that may be useful also for other > services where the client only know service name, protocol and domain. I > have indications that it is becoming more and more interesting to > dynamically search for services in this manner for other services but > I'm very interested of other opinions here. > > I don't however understand in what way we need to be careful to limit > this only to some specific services. Could you clarify this concern? > > /Stefan > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Sam Hartman > > Sent: den 20 maj 2005 12:39 > > To: ietf-pkix@imc.org > > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > > > > > > > Hi. I'm speaking as an individual not as an AD. > > > > This proposal was originally introduced as a use of dnsname in the > > Kerberos working group for pkinit. > > > > The authors of the proposal would like to name services as they are > > identified by users. For example a user types foo.bar.example.com > > into some program. The program looks up a SRV record for some service > > and then connects to that service. If insecure DNS is used then the > > dns lookup should not be part of the name against which a certificate > > is checkde. > > > > We're seeing a similar situation in the kitten working group ; see > > draft-ietf-kitten-gssapi-domain-based-names-00.txt. > > > > > > The idea of this proposal is that the certificate contain the name > > that the client system would look up in the same form as the client > > uses to look in DNS. > > > > I'm not sure how this proposal has evolved since it was first > > presented to me. Originally the goal was so that application > > libraries could use some sort of automatic mechanism to: > > > > * Look up SRV records > > > > * Bind to TLS certificates > > > > * Find the Kerberos principal name > > > > * Bind to pkinit certificates. > > > > All the application author would do would be to pass the service > > protocol and name into some magic function. > > > > That bothers me. There is no guarantee that the SRV record tag will > > match the GSS/Kerberos principal name. There is no guarantee that the > > service in question doesn't have some better choice for certificate > > binding like one of the IMPP-specific solutions. > > > > > > I'm also not quite sure that SRV tags are real/really the right thing > > to be binding to. > > > > If the PKIX working group does adopt this proposal I would recommend > > being very careful. Make sure to scope it only to be used for > > applications/services where it is appropriate. Make sure to discuss > > applications that already have a mechanism for binding their > > certificates. > > > > It might also be important to find out if there is actually a use case > > for this name type before standardizing it. There wasn't really that > > much support in krb-wg for the earlier version of this. > > > > --Sam > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O3BvNZ037886; Mon, 23 May 2005 20:11:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4O3BvB6037885; Mon, 23 May 2005 20:11:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O3BtcV037851 for ; Mon, 23 May 2005 20:11:56 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4O3Bomr001257 for ; Mon, 23 May 2005 23:11:50 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4O3Bo2H055824 for ; Mon, 23 May 2005 23:11:50 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4O3Bo6F014877 for ; Mon, 23 May 2005 23:11:50 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4O3BnFw014803; Mon, 23 May 2005 23:11:50 -0400 In-Reply-To: To: "Stefan Santesson" Cc: "Sam Hartman" , ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: Request for new work item - Defining an SRV RR otherName X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Mon, 23 May 2005 23:10:38 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/23/2005 23:11:50, Serialize complete at 05/23/2005 23:11:50 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: Maybe I'm being a bit thick here, but do you really intend to include the entire RR contents, including the weight, target and port, in this otherName? Or do you intend to include only the lookup key (_service._protocol.DNSName) instead? Some of your wording makes IMHO more sense in that case, and the assertion you're conveying is "the CA issuer has authorized this entity to provide this service for this domain". Whatever may be the case for Kerberos, I don't see why this feature is problematic for (say) LDAP, except insofar as it's an argument for name constraints. I do think that you'd need to state that the use of this field in a certificate is governed by DNSName name constraints. Tom Gindin "Stefan Santesson" Sent by: owner-ietf-pkix@mail.imc.org 05/20/2005 06:44 PM To: "Sam Hartman" , cc: Subject: RE: Request for new work item - Defining an SRV RR otherName Sam, My recollection of this issue is a bit different from yours. The central need here is to enable the KDC to express in a certificate the fact that it is a KDC in a way that male sense to clients. In a traditional Kerberos environment the KDC can be known as a KDC since it can demonstrate knowledge of the user's key. In PKI initiated Kerberos, this property is lost. If the client knows the host name, IP address or any other identity of the KDC, which can be mapped to information in the KDC certificate, then we are good and appropriate binding is possible. However, from what I have learned, we may face situations where a client only know the name of the domain it wants to access and the fact that it looks for a PKINIT enabled KDC. In this case it is assumed that the client would do a SRV RR query to the DNS to get the host name of the currently available KDC. If the SRV RR is NOT the appropriate name to bind to in this case, then my question is what the alternative is. Finally, the reason to do this in PKIX is since this in principle is a generic way of service discovery that may be useful also for other services where the client only know service name, protocol and domain. I have indications that it is becoming more and more interesting to dynamically search for services in this manner for other services but I'm very interested of other opinions here. I don't however understand in what way we need to be careful to limit this only to some specific services. Could you clarify this concern? /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Sam Hartman > Sent: den 20 maj 2005 12:39 > To: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > > Hi. I'm speaking as an individual not as an AD. > > This proposal was originally introduced as a use of dnsname in the > Kerberos working group for pkinit. > > The authors of the proposal would like to name services as they are > identified by users. For example a user types foo.bar.example.com > into some program. The program looks up a SRV record for some service > and then connects to that service. If insecure DNS is used then the > dns lookup should not be part of the name against which a certificate > is checkde. > > We're seeing a similar situation in the kitten working group ; see > draft-ietf-kitten-gssapi-domain-based-names-00.txt. > > > The idea of this proposal is that the certificate contain the name > that the client system would look up in the same form as the client > uses to look in DNS. > > I'm not sure how this proposal has evolved since it was first > presented to me. Originally the goal was so that application > libraries could use some sort of automatic mechanism to: > > * Look up SRV records > > * Bind to TLS certificates > > * Find the Kerberos principal name > > * Bind to pkinit certificates. > > All the application author would do would be to pass the service > protocol and name into some magic function. > > That bothers me. There is no guarantee that the SRV record tag will > match the GSS/Kerberos principal name. There is no guarantee that the > service in question doesn't have some better choice for certificate > binding like one of the IMPP-specific solutions. > > > I'm also not quite sure that SRV tags are real/really the right thing > to be binding to. > > If the PKIX working group does adopt this proposal I would recommend > being very careful. Make sure to scope it only to be used for > applications/services where it is appropriate. Make sure to discuss > applications that already have a mechanism for binding their > certificates. > > It might also be important to find out if there is actually a use case > for this name type before standardizing it. There wasn't really that > much support in krb-wg for the earlier version of this. > > --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O3BuYX037876; Mon, 23 May 2005 20:11:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4O3Bu8s037875; Mon, 23 May 2005 20:11:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O3BsVO037834 for ; Mon, 23 May 2005 20:11:55 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4O3BnmO030459 for ; Mon, 23 May 2005 23:11:49 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4O3Bn2H117414 for ; Mon, 23 May 2005 23:11:49 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4O3BmcA012182 for ; Mon, 23 May 2005 23:11:49 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4O3BmfM012135; Mon, 23 May 2005 23:11:48 -0400 In-Reply-To: To: "Stefan Santesson" Cc: "Sam Hartman" , ietf-pkix@imc.org MIME-Version: 1.0 Subject: RE: Request for new work item - Defining an SRV RR otherName X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Mon, 23 May 2005 23:10:38 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/23/2005 23:11:48, Serialize complete at 05/23/2005 23:11:48 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan: Maybe I'm being a bit thick here, but do you really intend to include the entire RR contents, including the weight, target and port, in this otherName? Or do you intend to include only the lookup key (_service._protocol.DNSName) instead? Some of your wording makes IMHO more sense in that case, and the assertion you're conveying is "the CA issuer has authorized this entity to provide this service for this domain". Whatever may be the case for Kerberos, I don't see why this feature is problematic for (say) LDAP, except insofar as it's an argument for name constraints. I do think that you'd need to state that the use of this field in a certificate is governed by DNSName name constraints. Tom Gindin "Stefan Santesson" Sent by: owner-ietf-pkix@mail.imc.org 05/20/2005 06:44 PM To: "Sam Hartman" , cc: Subject: RE: Request for new work item - Defining an SRV RR otherName Sam, My recollection of this issue is a bit different from yours. The central need here is to enable the KDC to express in a certificate the fact that it is a KDC in a way that male sense to clients. In a traditional Kerberos environment the KDC can be known as a KDC since it can demonstrate knowledge of the user's key. In PKI initiated Kerberos, this property is lost. If the client knows the host name, IP address or any other identity of the KDC, which can be mapped to information in the KDC certificate, then we are good and appropriate binding is possible. However, from what I have learned, we may face situations where a client only know the name of the domain it wants to access and the fact that it looks for a PKINIT enabled KDC. In this case it is assumed that the client would do a SRV RR query to the DNS to get the host name of the currently available KDC. If the SRV RR is NOT the appropriate name to bind to in this case, then my question is what the alternative is. Finally, the reason to do this in PKIX is since this in principle is a generic way of service discovery that may be useful also for other services where the client only know service name, protocol and domain. I have indications that it is becoming more and more interesting to dynamically search for services in this manner for other services but I'm very interested of other opinions here. I don't however understand in what way we need to be careful to limit this only to some specific services. Could you clarify this concern? /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Sam Hartman > Sent: den 20 maj 2005 12:39 > To: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > > Hi. I'm speaking as an individual not as an AD. > > This proposal was originally introduced as a use of dnsname in the > Kerberos working group for pkinit. > > The authors of the proposal would like to name services as they are > identified by users. For example a user types foo.bar.example.com > into some program. The program looks up a SRV record for some service > and then connects to that service. If insecure DNS is used then the > dns lookup should not be part of the name against which a certificate > is checkde. > > We're seeing a similar situation in the kitten working group ; see > draft-ietf-kitten-gssapi-domain-based-names-00.txt. > > > The idea of this proposal is that the certificate contain the name > that the client system would look up in the same form as the client > uses to look in DNS. > > I'm not sure how this proposal has evolved since it was first > presented to me. Originally the goal was so that application > libraries could use some sort of automatic mechanism to: > > * Look up SRV records > > * Bind to TLS certificates > > * Find the Kerberos principal name > > * Bind to pkinit certificates. > > All the application author would do would be to pass the service > protocol and name into some magic function. > > That bothers me. There is no guarantee that the SRV record tag will > match the GSS/Kerberos principal name. There is no guarantee that the > service in question doesn't have some better choice for certificate > binding like one of the IMPP-specific solutions. > > > I'm also not quite sure that SRV tags are real/really the right thing > to be binding to. > > If the PKIX working group does adopt this proposal I would recommend > being very careful. Make sure to scope it only to be used for > applications/services where it is appropriate. Make sure to discuss > applications that already have a mechanism for binding their > certificates. > > It might also be important to find out if there is actually a use case > for this name type before standardizing it. There wasn't really that > much support in krb-wg for the earlier version of this. > > --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O2kwgE033041; Mon, 23 May 2005 19:46:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4O2kwBC033040; Mon, 23 May 2005 19:46:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4O2kuXE033022 for ; Mon, 23 May 2005 19:46:57 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4O2koRk013793 for ; Mon, 23 May 2005 22:46:51 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4O2ko2H122012 for ; Mon, 23 May 2005 22:46:50 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4O2kooC017782 for ; Mon, 23 May 2005 22:46:50 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4O2kokZ017778; Mon, 23 May 2005 22:46:50 -0400 In-Reply-To: <5.1.0.14.2.20050510170022.02cc5b08@email.nist.gov> To: wpolk@nist.gov Cc: housley@vigilsec.com, ietf-pkix@imc.org, kent@bbn.com, stefans@microsoft.com MIME-Version: 1.0 Subject: Re: WG Last Call: AIA CRL extension X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Mon, 23 May 2005 22:46:48 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/23/2005 22:46:50, Serialize complete at 05/23/2005 22:46:50 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tim: I should probably have brought this up earlier, but are we certain that "same trust anchor" is a strong enough check that the CRL signer is the one expected by the issuing CA? While I was not in San Diego when this wording was included in the 3280 series, I do not really think that that check is strong enough. I would suggest instead that the CRL signer's certificate needs to be directly issued by one of the CA's in the certification path back to the trust anchor used for the certificate's verification, or by that anchor itself, unless people have practical experience with CA structures which that rule would prohibit. Forcing the CRL to be issued by the CA itself (as I understand Denis to have suggested) prohibits the reasonable case where the CRL is issued by a hierarchical superior, so it is IMHO too strict. I am personally not sure, FWIW, that a CRL should be permitted to be signed by a second-cousin certificate of the issuer's certificate. By analogy to the use of the terms in families, "sibling" certificates would have the same issuer, "first-cousin" certificates would be issued by siblings, and "second-cousin" certificates would be issued by first cousins - so they are both three levels down from the same trust anchor, or from the last common CA in their paths. This issue is not newly caused by CRL AIA, since the same issue can arise with CRL's containing only AKID. AIA only allows RP's to build a path (whether right or wrong) more quickly. In any case, nothing more than a note in Security Considerations is appropriate in any of our RFC's other than 3280 and its successor. Tom Gindin P.S. - The above views are mine, and not necessarily those of my employer Tim Polk Sent by: owner-ietf-pkix@mail.imc.org 05/10/2005 05:27 PM To: ietf-pkix@imc.org cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com Subject: WG Last Call: AIA CRL extension This message initiates working group Last Call for the specification "Internet X.509 Public Key Infrastructure: Authority Information Access CRL Extension". While some issues raised in the working group are unresolved, the editors believe that rough consensus supports the current specification. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt Last Call will run for (at least) two weeks. That is, Last Call will not close before May 24. Thanks, Tim Polk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NMWH1T064202; Mon, 23 May 2005 15:32:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4NMWHjm064201; Mon, 23 May 2005 15:32:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ci.sugar-land.tx.us (mail.ci.sugar-land.tx.us [66.150.129.211]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NMWGJg064151 for ; Mon, 23 May 2005 15:32:17 -0700 (PDT) (envelope-from rfc-editor@rfc-editor.org) Received: from svrpd14 ([192.168.2.137]) by mail.ci.sugar-land.tx.us; Mon, 23 May 2005 17:31:44 -0500 MIME-Version: 1.0 Date: Mon, 23 May 2005 17:31:44 -0500 X-Priority: 3 (Normal) To: ietf-announce@ietf.org, ietf-pkix@imc.org, rfc-editor@rfc-editor.org Subject: RFC 4043 on Internet X.509 Public Key Infrastructure PermanentIdentifier From: rfc-editor@rfc-editor.org X-Mailer: GWAVA Archive Mailer Content-Type: multipart/mixed; boundary="----=_NextPart_bad_1948_5bfb4720.c4009003_.MIX" Message-ID: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A new Request for Comments is now available in online RFC libraries. RFC 4043 Title: Internet X.509 Public Key Infrastructure Permanent Identifier Author(s): D. Pinkas, T. Gindin Status: Standards Track Date: May 2005 Mailbox: Denis.Pinkas@bull.net, tgindin@us.ibm.com Pages: 15 Characters: 30092 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-pi-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4043.txt This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body=20 help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute =2E.. Below is the data which will enable a MIME compliant Mail Reader=20 implementation to automatically retrieve the ASCII version of the RFCs. ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: application/octet-stream; name="2#Part.001" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2#Part.001" Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxMDIzLlJG Q0BSRkMtRURJVE9SLk9SRz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDQzDQo= ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: text/plain; name="3#rfc4043.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="3#rfc4043.txt" Content-Type: text/plain Content-ID: <050523141023.RFC@RFC-EDITOR.ORG> ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: application/octet-stream; name="4#Part.003" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="4#Part.003" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYt QW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQo= ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: application/octet-stream; name="5#Mime.822" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="5#Mime.822" UmVjZWl2ZWQ6IGZyb20gbWVnYXRyb24uaWV0Zi5vcmcgWzEzMi4xNTEuNi43MV0NCglieSBt YWlsLmNpLnN1Z2FyLWxhbmQudHgudXM7IE1vbiwgMjMgTWF5IDIwMDUgMTY6MzU6MTYgLTA1 MDANClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdC5sb2NhbGRvbWFpbiAoWzEyNy4wLjAuMV0g aGVsbz1tZWdhdHJvbi5pZXRmLm9yZykNCglieSBtZWdhdHJvbi5pZXRmLm9yZyB3aXRoIGVz bXRwIChFeGltIDQuMzIpDQoJaWQgMURhS0hDLTAwMDNNRC05NzsgTW9uLCAyMyBNYXkgMjAw NSAxNzoxNTo1NCAtMDQwMA0KUmVjZWl2ZWQ6IGZyb20gb2Rpbi5pZXRmLm9yZyAoWzEzMi4x NTEuMS4xNzZdIGhlbG89aWV0Zi5vcmcpDQoJYnkgbWVnYXRyb24uaWV0Zi5vcmcgd2l0aCBl c210cCAoRXhpbSA0LjMyKSBpZCAxRGFLSDgtMDAwM000LTVCDQoJZm9yIGlldGYtYW5ub3Vu Y2VAbWVnYXRyb24uaWV0Zi5vcmc7IE1vbiwgMjMgTWF5IDIwMDUgMTc6MTU6NTAgLTA0MDAN ClJlY2VpdmVkOiBmcm9tIGlldGYtbXguaWV0Zi5vcmcgKGlldGYtbXguaWV0Zi5vcmcgWzEz Mi4xNTEuNi4xXSkNCglieSBpZXRmLm9yZyAoOC45LjFhLzguOS4xYSkgd2l0aCBFU01UUCBp ZCBSQUEyMTc2Ng0KCWZvciA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz47IE1vbiwgMjMgTWF5 IDIwMDUgMTc6MTU6NDggLTA0MDAgKEVEVCkNClJlY2VpdmVkOiBmcm9tIGJvcmVhcy5pc2ku ZWR1IChbMTI4LjkuMTYwLjE2MV0pDQoJYnkgaWV0Zi1teC5pZXRmLm9yZyB3aXRoIGVzbXRw IChFeGltIDQuMzMpIGlkIDFEYUtaQi0wMDAxSDEtOXcNCglmb3IgaWV0Zi1hbm5vdW5jZUBp ZXRmLm9yZzsgTW9uLCAyMyBNYXkgMjAwNSAxNzozNDoyOSAtMDQwMA0KUmVjZWl2ZWQ6IGZy b20gSVNJLkVEVSAoYWRtYS5pc2kuZWR1IFsxMjguOS4xNjAuMjM5XSkNCglieSBib3JlYXMu aXNpLmVkdSAoOC4xMS42cDIrMDkxNy84LjExLjIpIHdpdGggRVNNVFAgaWQgajROTENTMzA1 MjE0Ow0KCU1vbiwgMjMgTWF5IDIwMDUgMTQ6MTI6MjggLTA3MDAgKFBEVCkNCk1lc3NhZ2Ut SWQ6IDwyMDA1MDUyMzIxMTIuajROTENTMzA1MjE0QGJvcmVhcy5pc2kuZWR1Pg0KVG86IGll dGYtYW5ub3VuY2VAaWV0Zi5vcmcNCkZyb206IHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcN Ck1pbWUtVmVyc2lvbjogMS4wDQpDb250ZW50LVR5cGU6IE11bHRpcGFydC9NaXhlZDsgQm91 bmRhcnk9TmV4dFBhcnQNCkRhdGU6IE1vbiwgMjMgTWF5IDIwMDUgMTQ6MTI6MjggLTA3MDAN ClgtSVNJLTQtMzktNi1NYWlsU2Nhbm5lcjogRm91bmQgdG8gYmUgY2xlYW4NClgtTWFpbFNj YW5uZXItRnJvbTogcmZjLWVkQGlzaS5lZHUNClgtU3BhbS1TY29yZTogLTE0LjYgKC0tLS0t LS0tLS0tLS0tKQ0KWC1TY2FuLVNpZ25hdHVyZTogYzgzY2NiNWNjMTBlNzUxNDk2Mzk4ZjEy MzNjYTljM2ENCkNjOiBpZXRmLXBraXhAaW1jLm9yZywgcmZjLWVkaXRvckByZmMtZWRpdG9y Lm9yZw0KU3ViamVjdDogUkZDIDQwNDMgb24gSW50ZXJuZXQgWC41MDkgUHVibGljIEtleSBJ bmZyYXN0cnVjdHVyZSBQZXJtYW5lbnQNCglJZGVudGlmaWVyDQpYLUJlZW5UaGVyZTogaWV0 Zi1hbm5vdW5jZUBpZXRmLm9yZw0KWC1NYWlsbWFuLVZlcnNpb246IDIuMS41DQpQcmVjZWRl bmNlOiBsaXN0DQpMaXN0LUlkOiBpZXRmLWFubm91bmNlLmlldGYub3JnDQpMaXN0LVVuc3Vi c2NyaWJlOiA8aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWV0Zi1h bm5vdW5jZT4sDQoJPG1haWx0bzppZXRmLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3Vi amVjdD11bnN1YnNjcmliZT4NCkxpc3QtUG9zdDogPG1haWx0bzppZXRmLWFubm91bmNlQGll dGYub3JnPg0KTGlzdC1IZWxwOiA8bWFpbHRvOmlldGYtYW5ub3VuY2UtcmVxdWVzdEBpZXRm Lm9yZz9zdWJqZWN0PWhlbHA+DQpMaXN0LVN1YnNjcmliZTogPGh0dHBzOi8vd3d3MS5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2U+LA0KCTxtYWlsdG86aWV0Zi1h bm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9c3Vic2NyaWJlPg0KU2VuZGVyOiBp ZXRmLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmcNCkVycm9ycy1UbzogaWV0Zi1hbm5vdW5j ZS1ib3VuY2VzQGlldGYub3JnDQoNCg0KLS1OZXh0UGFydA0KDQoNCkEgbmV3IFJlcXVlc3Qg Zm9yIENvbW1lbnRzIGlzIG5vdyBhdmFpbGFibGUgaW4gb25saW5lIFJGQyBsaWJyYXJpZXMu DQoNCg0KICAgICAgICBSRkMgNDA0Mw0KDQogICAgICAgIFRpdGxlOiAgICAgIEludGVybmV0 IFguNTA5IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUNCiAgICAgICAgICAgICAgICAgICAg UGVybWFuZW50IElkZW50aWZpZXINCiAgICAgICAgQXV0aG9yKHMpOiAgRC4gUGlua2FzLCBU LiBHaW5kaW4NCiAgICAgICAgU3RhdHVzOiAgICAgU3RhbmRhcmRzIFRyYWNrDQogICAgICAg IERhdGU6ICAgICAgIE1heSAyMDA1DQogICAgICAgIE1haWxib3g6ICAgIERlbmlzLlBpbmth c0BidWxsLm5ldCwgdGdpbmRpbkB1cy5pYm0uY29tDQogICAgICAgIFBhZ2VzOiAgICAgIDE1 DQogICAgICAgIENoYXJhY3RlcnM6IDMwMDkyDQogICAgICAgIFVwZGF0ZXMvT2Jzb2xldGVz L1NlZUFsc286ICAgIE5vbmUNCg0KICAgICAgICBJLUQgVGFnOiAgICBkcmFmdC1pZXRmLXBr aXgtcGktMTEudHh0DQoNCiAgICAgICAgVVJMOiAgICAgICAgZnRwOi8vZnRwLnJmYy1lZGl0 b3Iub3JnL2luLW5vdGVzL3JmYzQwNDMudHh0DQoNCg0KVGhpcyBkb2N1bWVudCBkZWZpbmVz IGEgbmV3IGZvcm0gb2YgbmFtZSwgY2FsbGVkIHBlcm1hbmVudA0KaWRlbnRpZmllciwgdGhh dCBtYXkgYmUgaW5jbHVkZWQgaW4gdGhlIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbg0Kb2Yg YSBwdWJsaWMga2V5IGNlcnRpZmljYXRlIGlzc3VlZCB0byBhbiBlbnRpdHkuDQoNClRoZSBw ZXJtYW5lbnQgaWRlbnRpZmllciBpcyBhbiBvcHRpb25hbCBmZWF0dXJlIHRoYXQgbWF5IGJl IHVzZWQNCmJ5IGEgQ0EgdG8gaW5kaWNhdGUgdGhhdCB0d28gb3IgbW9yZSBjZXJ0aWZpY2F0 ZXMgcmVsYXRlIHRvIHRoZQ0Kc2FtZSBlbnRpdHksIGV2ZW4gaWYgdGhleSBjb250YWluIGRp ZmZlcmVudCBzdWJqZWN0IG5hbWUgKEROcykgb3INCmRpZmZlcmVudCBuYW1lcyBpbiB0aGUg c3ViamVjdEFsdE5hbWUgZXh0ZW5zaW9uLCBvciBpZiB0aGUgbmFtZQ0Kb3IgdGhlIGFmZmls aWF0aW9uIG9mIHRoYXQgZW50aXR5IHN0b3JlZCBpbiB0aGUgc3ViamVjdCBvciBhbm90aGVy DQpuYW1lIGZvcm0gaW4gdGhlIHN1YmplY3RBbHROYW1lIGV4dGVuc2lvbiBoYXMgY2hhbmdl ZC4NCg0KVGhlIHN1YmplY3QgbmFtZSwgY2FycmllZCBpbiB0aGUgc3ViamVjdCBmaWVsZCwg aXMgb25seSB1bmlxdWUNCmZvciBlYWNoIHN1YmplY3QgZW50aXR5IGNlcnRpZmllZCBieSB0 aGUgb25lIENBIGFzIGRlZmluZWQgYnkgdGhlDQppc3N1ZXIgbmFtZSBmaWVsZC4gIEhvd2V2 ZXIsIHRoZSBuZXcgbmFtZSBmb3JtIGNhbiBjYXJyeSBhDQpuYW1lIHRoYXQgaXMgdW5pcXVl IGZvciBlYWNoIHN1YmplY3QgZW50aXR5IGNlcnRpZmllZCBieSBhIENBLg0KDQpUaGlzIGRv Y3VtZW50IGlzIGEgcHJvZHVjdCBvZiB0aGUgUHVibGljLUtleSBJbmZyYXN0cnVjdHVyZSAo WC41MDkpDQpXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQpUaGlzIGlzIG5vdyBhIFBy b3Bvc2VkIFN0YW5kYXJkIFByb3RvY29sLg0KDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBh biBJbnRlcm5ldCBzdGFuZGFyZHMgdHJhY2sgcHJvdG9jb2wgZm9yDQp0aGUgSW50ZXJuZXQg Y29tbXVuaXR5LCBhbmQgcmVxdWVzdHMgZGlzY3Vzc2lvbiBhbmQgc3VnZ2VzdGlvbnMNCmZv ciBpbXByb3ZlbWVudHMuICBQbGVhc2UgcmVmZXIgdG8gdGhlIGN1cnJlbnQgZWRpdGlvbiBv ZiB0aGUNCiJJbnRlcm5ldCBPZmZpY2lhbCBQcm90b2NvbCBTdGFuZGFyZHMiIChTVEQgMSkg Zm9yIHRoZQ0Kc3RhbmRhcmRpemF0aW9uIHN0YXRlIGFuZCBzdGF0dXMgb2YgdGhpcyBwcm90 b2NvbC4gIERpc3RyaWJ1dGlvbg0Kb2YgdGhpcyBtZW1vIGlzIHVubGltaXRlZC4NCg0KVGhp cyBhbm5vdW5jZW1lbnQgaXMgc2VudCB0byB0aGUgSUVURiBsaXN0IGFuZCB0aGUgUkZDLURJ U1QgbGlzdC4NClJlcXVlc3RzIHRvIGJlIGFkZGVkIHRvIG9yIGRlbGV0ZWQgZnJvbSB0aGUg SUVURiBkaXN0cmlidXRpb24gbGlzdA0Kc2hvdWxkIGJlIHNlbnQgdG8gSUVURi1SRVFVRVNU QElFVEYuT1JHLiAgUmVxdWVzdHMgdG8gYmUNCmFkZGVkIHRvIG9yIGRlbGV0ZWQgZnJvbSB0 aGUgUkZDLURJU1QgZGlzdHJpYnV0aW9uIGxpc3Qgc2hvdWxkDQpiZSBzZW50IHRvIFJGQy1E SVNULVJFUVVFU1RAUkZDLUVESVRPUi5PUkcuDQoNCkRldGFpbHMgb24gb2J0YWluaW5nIFJG Q3MgdmlhIEZUUCBvciBFTUFJTCBtYXkgYmUgb2J0YWluZWQgYnkgc2VuZGluZw0KYW4gRU1B SUwgbWVzc2FnZSB0byByZmMtaW5mb0BSRkMtRURJVE9SLk9SRyB3aXRoIHRoZSBtZXNzYWdl IGJvZHkgDQpoZWxwOiB3YXlzX3RvX2dldF9yZmNzLiAgRm9yIGV4YW1wbGU6DQoNCiAgICAg ICAgVG86IHJmYy1pbmZvQFJGQy1FRElUT1IuT1JHDQogICAgICAgIFN1YmplY3Q6IGdldHRp bmcgcmZjcw0KDQogICAgICAgIGhlbHA6IHdheXNfdG9fZ2V0X3JmY3MNCg0KUmVxdWVzdHMg Zm9yIHNwZWNpYWwgZGlzdHJpYnV0aW9uIHNob3VsZCBiZSBhZGRyZXNzZWQgdG8gZWl0aGVy IHRoZQ0KYXV0aG9yIG9mIHRoZSBSRkMgaW4gcXVlc3Rpb24sIG9yIHRvIFJGQy1NYW5hZ2Vy QFJGQy1FRElUT1IuT1JHLiAgVW5sZXNzDQpzcGVjaWZpY2FsbHkgbm90ZWQgb3RoZXJ3aXNl IG9uIHRoZSBSRkMgaXRzZWxmLCBhbGwgUkZDcyBhcmUgZm9yDQp1bmxpbWl0ZWQgZGlzdHJp YnV0aW9uLg0KDQpTdWJtaXNzaW9ucyBmb3IgUmVxdWVzdHMgZm9yIENvbW1lbnRzIHNob3Vs ZCBiZSBzZW50IHRvDQpSRkMtRURJVE9SQFJGQy1FRElUT1IuT1JHLiAgUGxlYXNlIGNvbnN1 bHQgUkZDIDIyMjMsIEluc3RydWN0aW9ucyB0byBSRkMNCkF1dGhvcnMsIGZvciBmdXJ0aGVy IGluZm9ybWF0aW9uLg0KDQoNCkpveWNlIEsuIFJleW5vbGRzIGFuZCBTYW5keSBHaW5vemEN ClVTQy9JbmZvcm1hdGlvbiBTY2llbmNlcyBJbnN0aXR1dGUNCg0KLi4uDQoNCkJlbG93IGlz IHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgTWFpbCBSZWFk ZXIgDQppbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJ SSB2ZXJzaW9uDQpvZiB0aGUgUkZDcy4NCg0KLS1OZXh0UGFydA0KQ29udGVudC1UeXBlOiBN dWx0aXBhcnQvQWx0ZXJuYXRpdmU7IEJvdW5kYXJ5PSJPdGhlckFjY2VzcyINCg0KLS1PdGhl ckFjY2Vzcw0KQ29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10 eXBlPSJtYWlsLXNlcnZlciI7DQoJc2VydmVyPSJSRkMtSU5GT0BSRkMtRURJVE9SLk9SRyIN Cg0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluDQpDb250ZW50LUlEOiA8MDUwNTIzMTQxMDIz LlJGQ0BSRkMtRURJVE9SLk9SRz4NCg0KUkVUUklFVkU6IHJmYw0KRE9DLUlEOiByZmM0MDQz DQoNCi0tT3RoZXJBY2Nlc3MNCkNvbnRlbnQtVHlwZTogTWVzc2FnZS9FeHRlcm5hbC1ib2R5 OyBuYW1lPSJyZmM0MDQzLnR4dCI7IHNpdGU9ImZ0cC5pc2kuZWR1IjsNCglhY2Nlc3MtdHlw ZT0iYW5vbi1mdHAiOyBkaXJlY3Rvcnk9ImluLW5vdGVzIg0KDQpDb250ZW50LVR5cGU6IHRl eHQvcGxhaW4NCkNvbnRlbnQtSUQ6IDwwNTA1MjMxNDEwMjMuUkZDQFJGQy1FRElUT1IuT1JH Pg0KDQoNCi0tT3RoZXJBY2Nlc3MtLQ0KLS1OZXh0UGFydA0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCk1JTUUtVmVyc2lvbjogMS4wDQpDb250ZW50 LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBpbmxpbmUN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklF VEYtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFubm91bmNlDQoNCi0t TmV4dFBhcnQtLQ0KDQo= ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX Content-Type: text/plain; name="GWAVADAT.TXT" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="GWAVADAT.TXT" AdmID:217BFB629F3CF22BFC888D9128A2CB31 ------=_NextPart_bad_1948_5bfb4720.c4009003_.MIX-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NLFu1c050710; Mon, 23 May 2005 14:15:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4NLFujQ050708; Mon, 23 May 2005 14:15:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NLFt9u050682 for ; Mon, 23 May 2005 14:15:55 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j4NLCS305214; Mon, 23 May 2005 14:12:28 -0700 (PDT) Message-Id: <200505232112.j4NLCS305214@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4043 on Internet X.509 Public Key Infrastructure Permanent Identifier Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 23 May 2005 14:12:28 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4043 Title: Internet X.509 Public Key Infrastructure Permanent Identifier Author(s): D. Pinkas, T. Gindin Status: Standards Track Date: May 2005 Mailbox: Denis.Pinkas@bull.net, tgindin@us.ibm.com Pages: 15 Characters: 30092 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-pi-11.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4043.txt This document defines a new form of name, called permanent identifier, that may be included in the subjectAltName extension of a public key certificate issued to an entity. The permanent identifier is an optional feature that may be used by a CA to indicate that two or more certificates relate to the same entity, even if they contain different subject name (DNs) or different names in the subjectAltName extension, or if the name or the affiliation of that entity stored in the subject or another name form in the subjectAltName extension has changed. The subject name, carried in the subject field, is only unique for each subject entity certified by the one CA as defined by the issuer name field. However, the new name form can carry a name that is unique for each subject entity certified by a CA. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050523141023.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4043 --OtherAccess Content-Type: Message/External-body; name="rfc4043.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050523141023.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NJkBZd024137; Mon, 23 May 2005 12:46:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4NJkBfC024136; Mon, 23 May 2005 12:46:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NJkA7e024128 for ; Mon, 23 May 2005 12:46:10 -0700 (PDT) (envelope-from dinaras@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03424; Mon, 23 May 2005 15:46:08 -0400 (EDT) Message-Id: <200505231946.PAA03424@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ietf-pkix@imc.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pkix-sim-04.txt Date: Mon, 23 May 2005 15:46:07 -0400 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Internet X.509 Public Key Infrastructure Subject Identification Method (SIM) Author(s) : J. Park, et al. Filename : draft-ietf-pkix-sim-04.txt Pages : 16 Date : 2005-5-23 This document defines Privacy-Enhanced Protected Subject Identifier (PEPSI) format for including a privacy sensitive identifier in the subjectAltName extension of a certificate. The PEPSI is an optional feature that may be used by a relying parties to determine whether the subject of a particular certificate is also the person corresponding to a particular sensitive identifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pkix-sim-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pkix-sim-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-5-23145024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pkix-sim-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pkix-sim-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-5-23145024.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NGLMGV060385; Mon, 23 May 2005 09:21:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4NGLM39060384; Mon, 23 May 2005 09:21:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4NGLKp1060363 for ; Mon, 23 May 2005 09:21:21 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 17:21:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Mon, 23 May 2005 17:21:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVdqjlzGfeXzgRTRJ69gx2kPtxlOgAFRDNAAHz7flA= From: "Stefan Santesson" To: "Sam Hartman" Cc: X-OriginalArrivalTime: 23 May 2005 16:21:15.0140 (UTC) FILETIME=[711C6C40:01C55FB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4NGLLp1060379 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI The SRV RR draft is now available from internet-drafts. http://www.ietf.org/internet-drafts/draft-santesson-pkix-srvrr-00.txt /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Stefan Santesson > Sent: den 20 maj 2005 22:07 > To: Sam Hartman > Cc: ietf-pkix@imc.org > Subject: RE: Request for new work item - Defining an SRV RR otherName > > > Sorry for being a bit unclear. > Yes, you could use the Kerberos principal name specifically for Kerberos > but not for other service types. > > The benefit from the proposed SRV RR other name is that you could deploy > a generic approach, which maps 1:1 to service lookup via DNS for a wider > range of services and avoid different solutions for each service type. > > Yes, this means that we need to go through the pain to recognize a new > otherName, but now when we have to go there, the thought is that we then > may be better served with a more generic approach for client side > service validation rather than doing it just for Kerberos. > > /Stefan > > > > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: den 20 maj 2005 19:10 > > To: Stefan Santesson > > Cc: ietf-pkix@imc.org > > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > >>>>> "Stefan" == Stefan Santesson writes: > > > > Stefan> Sam, My recollection of this issue is a bit different from > > Stefan> yours. > > > > Stefan> The central need here is to enable the KDC to express in a > > Stefan> certificate the fact that it is a KDC in a way that male > > Stefan> sense to clients. > > > > > > If this is all you want, bind the KDC certificate to the TGS principal > > for the realm. That's what Larry's pkinit 26 text does. > > > > The original problem with that solution is that it required CAs to > > implement the kerberos OtherName. However this approach also requires > > the CA to implement a new OtherName. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L57SeH016810; Fri, 20 May 2005 22:07:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4L57SZH016809; Fri, 20 May 2005 22:07:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L57Qx5016764 for ; Fri, 20 May 2005 22:07:27 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 May 2005 06:07:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Sat, 21 May 2005 06:07:16 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVdqjlzGfeXzgRTRJ69gx2kPtxlOgAFRDNA From: "Stefan Santesson" To: "Sam Hartman" Cc: X-OriginalArrivalTime: 21 May 2005 05:07:20.0487 (UTC) FILETIME=[F75A8370:01C55DC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4L57Rx5016800 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry for being a bit unclear. Yes, you could use the Kerberos principal name specifically for Kerberos but not for other service types. The benefit from the proposed SRV RR other name is that you could deploy a generic approach, which maps 1:1 to service lookup via DNS for a wider range of services and avoid different solutions for each service type. Yes, this means that we need to go through the pain to recognize a new otherName, but now when we have to go there, the thought is that we then may be better served with a more generic approach for client side service validation rather than doing it just for Kerberos. /Stefan > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: den 20 maj 2005 19:10 > To: Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > >>>>> "Stefan" == Stefan Santesson writes: > > Stefan> Sam, My recollection of this issue is a bit different from > Stefan> yours. > > Stefan> The central need here is to enable the KDC to express in a > Stefan> certificate the fact that it is a KDC in a way that male > Stefan> sense to clients. > > > If this is all you want, bind the KDC certificate to the TGS principal > for the realm. That's what Larry's pkinit 26 text does. > > The original problem with that solution is that it required CAs to > implement the kerberos OtherName. However this approach also requires > the CA to implement a new OtherName. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L2A6sP066727; Fri, 20 May 2005 19:10:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4L2A6qb066726; Fri, 20 May 2005 19:10:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (carter-zimmerman.suchdamage.org [69.25.196.178]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4L2A4Uo066719 for ; Fri, 20 May 2005 19:10:05 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7065AE0063; Fri, 20 May 2005 22:09:47 -0400 (EDT) To: "Stefan Santesson" Cc: Subject: Re: Request for new work item - Defining an SRV RR otherName References: From: Sam Hartman Date: Fri, 20 May 2005 22:09:47 -0400 In-Reply-To: (Stefan Santesson's message of "Fri, 20 May 2005 23:44:38 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >>>>> "Stefan" == Stefan Santesson writes: Stefan> Sam, My recollection of this issue is a bit different from Stefan> yours. Stefan> The central need here is to enable the KDC to express in a Stefan> certificate the fact that it is a KDC in a way that male Stefan> sense to clients. If this is all you want, bind the KDC certificate to the TGS principal for the realm. That's what Larry's pkinit 26 text does. The original problem with that solution is that it required CAs to implement the kerberos OtherName. However this approach also requires the CA to implement a new OtherName. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KMiq07098243; Fri, 20 May 2005 15:44:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KMiqTl098242; Fri, 20 May 2005 15:44:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KMipUm098197 for ; Fri, 20 May 2005 15:44:51 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 23:44:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Fri, 20 May 2005 23:44:38 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVdeiEOK9B4RpTtSGeuNKNrSv6I4QABkYaQ From: "Stefan Santesson" To: "Sam Hartman" , X-OriginalArrivalTime: 20 May 2005 22:44:45.0746 (UTC) FILETIME=[85430120:01C55D8D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KMipUm098237 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam, My recollection of this issue is a bit different from yours. The central need here is to enable the KDC to express in a certificate the fact that it is a KDC in a way that male sense to clients. In a traditional Kerberos environment the KDC can be known as a KDC since it can demonstrate knowledge of the user's key. In PKI initiated Kerberos, this property is lost. If the client knows the host name, IP address or any other identity of the KDC, which can be mapped to information in the KDC certificate, then we are good and appropriate binding is possible. However, from what I have learned, we may face situations where a client only know the name of the domain it wants to access and the fact that it looks for a PKINIT enabled KDC. In this case it is assumed that the client would do a SRV RR query to the DNS to get the host name of the currently available KDC. If the SRV RR is NOT the appropriate name to bind to in this case, then my question is what the alternative is. Finally, the reason to do this in PKIX is since this in principle is a generic way of service discovery that may be useful also for other services where the client only know service name, protocol and domain. I have indications that it is becoming more and more interesting to dynamically search for services in this manner for other services but I'm very interested of other opinions here. I don't however understand in what way we need to be careful to limit this only to some specific services. Could you clarify this concern? /Stefan > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Sam Hartman > Sent: den 20 maj 2005 12:39 > To: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > > > Hi. I'm speaking as an individual not as an AD. > > This proposal was originally introduced as a use of dnsname in the > Kerberos working group for pkinit. > > The authors of the proposal would like to name services as they are > identified by users. For example a user types foo.bar.example.com > into some program. The program looks up a SRV record for some service > and then connects to that service. If insecure DNS is used then the > dns lookup should not be part of the name against which a certificate > is checkde. > > We're seeing a similar situation in the kitten working group ; see > draft-ietf-kitten-gssapi-domain-based-names-00.txt. > > > The idea of this proposal is that the certificate contain the name > that the client system would look up in the same form as the client > uses to look in DNS. > > I'm not sure how this proposal has evolved since it was first > presented to me. Originally the goal was so that application > libraries could use some sort of automatic mechanism to: > > * Look up SRV records > > * Bind to TLS certificates > > * Find the Kerberos principal name > > * Bind to pkinit certificates. > > All the application author would do would be to pass the service > protocol and name into some magic function. > > That bothers me. There is no guarantee that the SRV record tag will > match the GSS/Kerberos principal name. There is no guarantee that the > service in question doesn't have some better choice for certificate > binding like one of the IMPP-specific solutions. > > > I'm also not quite sure that SRV tags are real/really the right thing > to be binding to. > > If the PKIX working group does adopt this proposal I would recommend > being very careful. Make sure to scope it only to be used for > applications/services where it is appropriate. Make sure to discuss > applications that already have a mechanism for binding their > certificates. > > It might also be important to find out if there is actually a use case > for this name type before standardizing it. There wasn't really that > much support in krb-wg for the earlier version of this. > > --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KJdY4a046608; Fri, 20 May 2005 12:39:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KJdYfY046607; Fri, 20 May 2005 12:39:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from carter-zimmerman.mit.edu (CARTER-ZIMMERMAN.MIT.EDU [18.18.3.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KJdYSk046598 for ; Fri, 20 May 2005 12:39:34 -0700 (PDT) (envelope-from hartmans@mit.edu) Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A401FE0063; Fri, 20 May 2005 15:39:14 -0400 (EDT) To: ietf-pkix@imc.org Subject: Re: Request for new work item - Defining an SRV RR otherName From: Sam Hartman Date: Fri, 20 May 2005 15:39:14 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi. I'm speaking as an individual not as an AD. This proposal was originally introduced as a use of dnsname in the Kerberos working group for pkinit. The authors of the proposal would like to name services as they are identified by users. For example a user types foo.bar.example.com into some program. The program looks up a SRV record for some service and then connects to that service. If insecure DNS is used then the dns lookup should not be part of the name against which a certificate is checkde. We're seeing a similar situation in the kitten working group ; see draft-ietf-kitten-gssapi-domain-based-names-00.txt. The idea of this proposal is that the certificate contain the name that the client system would look up in the same form as the client uses to look in DNS. I'm not sure how this proposal has evolved since it was first presented to me. Originally the goal was so that application libraries could use some sort of automatic mechanism to: * Look up SRV records * Bind to TLS certificates * Find the Kerberos principal name * Bind to pkinit certificates. All the application author would do would be to pass the service protocol and name into some magic function. That bothers me. There is no guarantee that the SRV record tag will match the GSS/Kerberos principal name. There is no guarantee that the service in question doesn't have some better choice for certificate binding like one of the IMPP-specific solutions. I'm also not quite sure that SRV tags are real/really the right thing to be binding to. If the PKIX working group does adopt this proposal I would recommend being very careful. Make sure to scope it only to be used for applications/services where it is appropriate. Make sure to discuss applications that already have a mechanism for binding their certificates. It might also be important to find out if there is actually a use case for this name type before standardizing it. There wasn't really that much support in krb-wg for the earlier version of this. --Sam Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KHSH0B018644; Fri, 20 May 2005 10:28:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KHSHIN018643; Fri, 20 May 2005 10:28:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KHSFc3018631 for ; Fri, 20 May 2005 10:28:16 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 May 2005 18:28:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Fri, 20 May 2005 18:28:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVdIqykBgO6iCzbRSSh2o3yA/2QBwAPfF5Q From: "Stefan Santesson" To: "Jean-Marc Desperrier" , X-OriginalArrivalTime: 20 May 2005 17:28:09.0872 (UTC) FILETIME=[4AD6A900:01C55D61] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4KHSGc3018637 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Yes, The initial background thought was that more demanding encodings would be more of an issue for host labels rather than service resource records and thus IA5String would be sufficient, but I agree at this point to the suggestions to specify UTF8String instead. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Jean-Marc Desperrier > Sent: den 20 maj 2005 01:42 > To: ietf-pkix@imc.org > Subject: Re: Request for new work item - Defining an SRV RR otherName > > > Manger, James H wrote: > > >How about using UTF8String, instead of IA5String? The latter does not > gain much (it can still include chars such as 0x00, newline, bell that are > presumably not valid in SRV RR names), while the former should be more > future-proof. > > > > SRVRRName ::= UTF8String > > > > > > >Could you post the suggestion to the pkix list to see if there are any > >other reactions? > > > > > It's already really a pity that dNSName forces us to store SAN in ACE > encoding, instead of being able to put the real unicode value, so I'm > all for not doing the mistake again. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KEK88l060870; Fri, 20 May 2005 07:20:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KEK8Vx060869; Fri, 20 May 2005 07:20:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4KEK7I5060855 for ; Fri, 20 May 2005 07:20:07 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id C7A44100D0 for ; Fri, 20 May 2005 10:20:06 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07929-36 for ; Fri, 20 May 2005 10:19:52 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 8A101100C5 for ; Fri, 20 May 2005 10:19:52 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005052010191665-31076 ; Fri, 20 May 2005 10:19:16 -0400 Date: Fri, 20 May 2005 10:19:51 -0400 From: Sam Roberts To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Message-ID: <20050520141951.GD26985@certicom.com> References: Mime-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/20/2005 10:19:16 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/20/2005 10:19:17 AM, Serialize complete at 05/20/2005 10:19:17 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Simon McMahon , on Fri, May 20, 2005 at 07:50:03AM +1000: > The example should match typical usage and doesn't have to cover every > possibility. It probably isn't "typical", but the TCG uses RSA private keys encrypted with RSA public keys of the same strength. IIRC, instead of encrypting d,p-1,q-1,... (which would be too large), they only encrypt p. The decryptor can recreate the rest of the private key from the public key and knowledge of p. Cheers, Sam > > Simon. > > > Simon McMahon > > Work: (07) 31311420 > Mobile: (043) 2294180 > > > >>> 05/18/05 12:15am >>> > But, if the asymmetric private key is based on elliptic curves? > > Diego > > ----- Mensaje Original ----- > Remitente: "Simon McMahon" Simon_McMahon@health.qld.gov.au > Destinatario: housley@vigilsec.com, ietf-pkix@vpnc.org > Fecha: Martes, Mayo 17, 2005 1:03am > Asunto: Re: key usage - key encipherment or data encipherment > > > > >The example for 'keyEncipherment' should not include an "RSA public > >key encrypting an asymmetric private key", which, if it is also RSA > >is too big to encrypt with the public key. Surely, an RFC shouldn't > >list impossible cases as examples. > > > >Simon. > > > > > > > > *********************************************************************************** > This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. > > Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. > > If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. > *********************************************************************************** > -- http://www.certicom.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K8gVwm020980; Fri, 20 May 2005 01:42:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4K8gVt1020979; Fri, 20 May 2005 01:42:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K8gU2A020954 for ; Fri, 20 May 2005 01:42:30 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft3.fr.colt.net with ESMTP id j4K8gSF05914 for ; Fri, 20 May 2005 10:42:28 +0200 Message-ID: <428DA2F4.4080401@free.fr> Date: Fri, 20 May 2005 10:42:28 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050517 MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Request for new work item - Defining an SRV RR otherName References: <73388857A695D31197EF00508B08F29816B38C88@ntmsg0131.corpmail.telstra.com.au> In-Reply-To: <73388857A695D31197EF00508B08F29816B38C88@ntmsg0131.corpmail.telstra.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Manger, James H wrote: >How about using UTF8String, instead of IA5String? The latter does not gain much (it can still include chars such as 0x00, newline, bell that are presumably not valid in SRV RR names), while the former should be more future-proof. > > SRVRRName ::= UTF8String > > >Could you post the suggestion to the pkix list to see if there are any >other reactions? > > It's already really a pity that dNSName forces us to store SAN in ACE encoding, instead of being able to put the real unicode value, so I'm all for not doing the mistake again. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K1WtmD004776; Thu, 19 May 2005 18:32:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4K1WtxS004775; Thu, 19 May 2005 18:32:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K1Ws8D004763 for ; Thu, 19 May 2005 18:32:54 -0700 (PDT) (envelope-from James.H.Manger@team.telstra.com) Received: from mailbi.vtcif.telstra.com.au (mailbi.vtcif.telstra.com.au [202.12.142.19]) by mailbo.vtcif.telstra.com.au (Postfix) with ESMTP id 4793822AEC for ; Fri, 20 May 2005 11:32:53 +1000 (EST) Received: from mail2.cdn.telstra.com.au (localhost [127.0.0.1]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id A273E1DA85 for ; Fri, 20 May 2005 11:32:52 +1000 (EST) Received: from WSMSG0005.srv.dir.telstra.com (wsmsg0005.srv.dir.telstra.com [192.74.168.134]) by mail2.cdn.telstra.com.au (Postfix) with ESMTP id 31B06424E5 for ; Fri, 20 May 2005 11:32:52 +1000 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: Request for new work item - Defining an SRV RR otherName Date: Fri, 20 May 2005 11:26:23 +1000 Message-ID: <73388857A695D31197EF00508B08F29816B38C88@ntmsg0131.corpmail.telstra.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVa49B3OIJ65dJPQLOybWmgvDp/swBDTguwAAWxwyAAHHGHwAAVf99Q From: "Manger, James H" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id j4K1Wt8D004765 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: RE: draft-santesson-pkix-srvrr-00 How about using UTF8String, instead of IA5String? The latter does not gain much (it can still include chars such as 0x00, newline, bell that are presumably not valid in SRV RR names), while the former should be more future-proof. SRVRRName ::= UTF8String -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com] Sent: Thursday, 19 May 2005 11:53 PM To: Manger, James H When I talked to Russ we thought that IA5String would be sufficient so I did put that in as a start, but I'm completely open to a change to UTF8String. Could you post the suggestion to the pkix list to see if there are any other reactions? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K1Enu7001202; Thu, 19 May 2005 18:14:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4K1Envg001201; Thu, 19 May 2005 18:14:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4K1Elew001170 for ; Thu, 19 May 2005 18:14:48 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Fri, 20 May 2005 11:13:39 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Fri, 20 May 2005 11:13:40 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Fri, 20 May 2005 11:13:24 +1000 From: "Simon McMahon" To: , Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4K1Emew001196 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Eric, > The user doesn't really care or even want to know whether an intermediate symmetric key in involved or not. I agree. The increased complexity of the rewording for 'keyEncipherment' is even more information that the user, or implementer, doesn't need to know. Having two bits for encryption just makes room for interoperability problems like those already mentioned. Where exactly is the benefit? Earlier remarks that it should be preserved until people are "smart enough" to make good use of it dont help much. If the use of 'dataEncipherment' is deprecated, but not reused for another purpose, we would have only 1 bit 'keyEncipherment' that could be renamed 'encipherment'. The proposed rewording discourages use of 'dataEncipherment' anyway. This would have little impact on implementations that use 'keyEncipherment' already, or implementations that set both bits because the distinction is so unclear and irrelevant. Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Eric Norman 05/20/05 07:16am >>> On May 19, 2005, at 1:33 PM, Hallam-Baker, Phillip wrote: > I have been following the thread, I think the cures proposed may be > worse than the problem. > > I think that the sentences can be adequately clarified by stating that > dataEncipherment is to be set if the key is to be used to directly > encipher data, i.e. without the use of an intermediate session key. I might as well chime in with my take, which is different yet. And since those two bits have already appeared in standards documents, probably not worth anything. I think that from a user's point of view, all the user cares about is that the data is protected in transit and perhaps at rest. The user doesn't really care or even want to know whether an intermediate symmetric key in involved or not. From that point of view, the distinction seems rather silly. Now, if someone came up with a key escrow scheme that would escrow the symmetric key, then that might be interesting. But that's yet another thread. Eric Norman University of WIsconsin *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLpVkY063804; Thu, 19 May 2005 14:51:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JLpVkf063803; Thu, 19 May 2005 14:51:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLpTef063774 for ; Thu, 19 May 2005 14:51:30 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Fri, 20 May 2005 07:50:22 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Fri, 20 May 2005 07:50:22 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Fri, 20 May 2005 07:50:03 +1000 From: "Simon McMahon" To: Cc: "<" Subject: RE: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JLpUef063790 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sure, but the rewording mentions "RSA" for the public key and doesn't specify anything for the private. Do asymmetric ciphers often get combined this way in practice? A device would need full implementations of both RSA and elliptic curve to support this. The example should match typical usage and doesn't have to cover every possibility. The current wording implies RSA. Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> 05/18/05 12:15am >>> But, if the asymmetric private key is based on elliptic curves? Diego ----- Mensaje Original ----- Remitente: "Simon McMahon" Simon_McMahon@health.qld.gov.au Destinatario: housley@vigilsec.com, ietf-pkix@vpnc.org Fecha: Martes, Mayo 17, 2005 1:03am Asunto: Re: key usage - key encipherment or data encipherment > >The example for 'keyEncipherment' should not include an "RSA public >key encrypting an asymmetric private key", which, if it is also RSA >is too big to encrypt with the public key. Surely, an RFC shouldn't >list impossible cases as examples. > >Simon. > *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLGlAn056196; Thu, 19 May 2005 14:16:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JLGl9w056195; Thu, 19 May 2005 14:16:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp7.wiscmail.wisc.edu (hagen.doit.wisc.edu [144.92.197.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JLGkac056169 for ; Thu, 19 May 2005 14:16:46 -0700 (PDT) (envelope-from ejnorman@doit.wisc.edu) Received: from avs-daemon.smtp7.wiscmail.wisc.edu by smtp7.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) id <0IGR00I4R9RQAB@smtp7.wiscmail.wisc.edu> for ietf-pkix@imc.org; Thu, 19 May 2005 16:16:38 -0500 (CDT) Received: from [128.104.4.39] (dyn-4-39.doit.wisc.edu [128.104.4.39]) by smtp7.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTPSA id <0IGR008NU9RND2@smtp7.wiscmail.wisc.edu> for ietf-pkix@imc.org; Thu, 19 May 2005 16:16:36 -0500 (CDT) Date: Thu, 19 May 2005 16:16:28 -0500 From: Eric Norman Subject: Re: key usage - key encipherment or data encipherment In-reply-to: <198A730C2044DE4A96749D13E167AD372502B3@MOU1WNEXMB04.vcorp.ad.vrsn.com> To: ietf-pkix@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Report: AuthenticatedSender=yes, SenderIP=128.104.4.39 X-Spam-PmxInfo: Server=avs-3, Version=4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.5.19.26, SenderIP=128.104.4.39 References: <198A730C2044DE4A96749D13E167AD372502B3@MOU1WNEXMB04.vcorp.ad.vrsn.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On May 19, 2005, at 1:33 PM, Hallam-Baker, Phillip wrote: > I have been following the thread, I think the cures proposed may be > worse than the problem. > > I think that the sentences can be adequately clarified by stating that > dataEncipherment is to be set if the key is to be used to directly > encipher data, i.e. without the use of an intermediate session key. I might as well chime in with my take, which is different yet. And since those two bits have already appeared in standards documents, probably not worth anything. I think that from a user's point of view, all the user cares about is that the data is protected in transit and perhaps at rest. The user doesn't really care or even want to know whether an intermediate symmetric key in involved or not. From that point of view, the distinction seems rather silly. Now, if someone came up with a key escrow scheme that would escrow the symmetric key, then that might be interesting. But that's yet another thread. Eric Norman University of WIsconsin Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JIXAHS021349; Thu, 19 May 2005 11:33:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JIXA86021348; Thu, 19 May 2005 11:33:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JIX7vn021339 for ; Thu, 19 May 2005 11:33:07 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by colibri.verisign.com (8.12.11/8.12.11) with ESMTP id j4JIX5FJ005341; Thu, 19 May 2005 11:33:05 -0700 (PDT) Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 19 May 2005 11:33:04 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: key usage - key encipherment or data encipherment Date: Thu, 19 May 2005 11:33:04 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD372502B3@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: key usage - key encipherment or data encipherment Thread-Index: AcVZG8i79X1vB1dGQRqztW/jU2Re7QDhJMjg From: "Hallam-Baker, Phillip" To: "Peter Gutmann" , , X-OriginalArrivalTime: 19 May 2005 18:33:05.0032 (UTC) FILETIME=[321F2880:01C55CA1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JIX7vn021340 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have been following the thread, I think the cures proposed may be worse than the problem. I think that the sentences can be adequately clarified by stating that dataEncipherment is to be set if the key is to be used to directly encipher data, i.e. without the use of an intermediate session key. I accept that this is not a particularly interesting use of dataEncipherment, the only protocols I can think of in which data is directly enciphered with a public key is Chaumian cash schemes and similar where blinding is used. Everywhere else you want to use a packaging scheme because the strength of bit 0 in RSA is pretty good but the strength of bit 1024 with a 1024 bit key is pretty bad. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JGXu2f001892; Thu, 19 May 2005 09:33:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JGXuNU001891; Thu, 19 May 2005 09:33:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JGXs1o001863 for ; Thu, 19 May 2005 09:33:55 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA43054; Thu, 19 May 2005 18:48:38 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051918333354:1933 ; Thu, 19 May 2005 18:33:33 +0200 Message-ID: <428CC017.4050707@bull.net> Date: Thu, 19 May 2005 18:34:31 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Gutmann CC: ietf-pkix@vpnc.org Subject: Re: Improving PKCS#11 References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 18:33:33, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 18:33:40, Serialize complete at 19/05/2005 18:33:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, See my comment at the bottom of this e-mail. >>The purpose is to make impossible, whatever the user application asks, to >>extract the private key in the clear. > Since the flags are ultimately controlled by the user app (no matter what you > call them or where you put them), the user app is *always* going to get the > key if it really wants it. The only thing that'll stop it is if the hardware > prevents this (see below). >>>If the hardware makes >>>it unextractable (e.g. in Fortezza cards), it'll implicitly set >>>CKA_EXTRACTABLE for you. >>The hardware cannot do anything since currently the setting of the flag >>CKA_EXTRACTABLE is left to the application. > That's merely a request from the software side. A Fortezza card isn't going > to give you the key, no matter what you set CKA_EXTRACTABLE to. Conversely, a > Cryptoflex (at least the older ones) will always give you the key because it > only contains a private-key engine (you can't even do public-key encryption > with it). So if you try and set the flag in a way that isn't supported by the > hardware, you'll get a template-inconsistent error (or you may get the object > created but with the template modified according to the hardware capabilities, > depending on the implementation). Ultimately, the crypto hardware gets the > last word, not an application-set flag. Unlike PKIX, the PKCS #11 folks are > somewhat reluctant to set standards requirements that violate the laws of > physics. >>I do not think so: the purpose is not to modify any existing command, but to >>add only ONE new one which might be called something like: >>C_UnwrapKeyCkaExtractableFalse >>where the certificate used to perform the operation would have a key usage >>like: keyEnciphermentNoExtract. This means that the "cryptographic material", >>once decrypted, cannot be extracted. > But again, this depends *entirely* on the calling software. It doesn't matter > how you dress this up, if the calling app wants the key, all it has to do is > call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse, or set > CKA_EXTRACTABLE to true in the template for C_UnwrapKey, or whatever. I did not made my explanations clear enough. A private key, when generated within the token, would be marked to be usable only with C_UnwrapKeyCkaExtractableFalse. So if the application attempts to use it with C_UnwrapKey this will fail. This would mean that the certificate corresponding to that private key would then be marked with keyEncipherment-no-extract. Denis > If the > calling app wants to it can look at the cert, see that keyEncipherment is set > to true and dataEncipherment false, and then go ahead and set CKA_EXTRACTABLE > to true or call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse. There > is therefore no difference between C_UnwrapKeyCkaExtractableFalse and > C_UnwrapKey with CKA_EXTRACTABLE set to false. > > Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JGJx0E099673; Thu, 19 May 2005 09:19:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JGJxLw099672; Thu, 19 May 2005 09:19:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.firstdata.com (mail2.firstdata.com [198.184.5.29]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JGJvDq099663 for ; Thu, 19 May 2005 09:19:58 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Received: from ([198.184.5.26]) by mail2.firstdata.com with SMTP id KP-TRRA2.23332520; Thu, 19 May 2005 12:19:26 -0400 Received: from mdhagsmtp01.firstdata.com (198.184.5.21) by MDSIGABA01.firstadata.com (Sigaba Gateway v3.8) with ESMTP id 2068871; Thu, 19 May 2005 12:25:59 -0400 Subject: Re: EuroPKI 2005 - Call for Participation To: "Anders Rundgren" Cc: "David Chadwick" , PKIX X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Thu, 19 May 2005 10:19:09 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP01/MD/FDMS/FDC(Release 6.5.2|June 01, 2004) at 05/19/2005 12:25:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: at 3:25pm 5/18/05, anders rundgen wrote: > The problem is that none these systems are supported by PCs as this industry > have shown to be incapable of defining a mobile, secure container. > Esoteric explanations may be more fun to talk about but they have little > validity as ID TTP liability etc.has not been put to test in any major way yet. > "non-repudiation", has probably not happened once! > > BTW, maybe you guys should begin to look on the next ID "revolution" > Microsoft's InfoCard stuff? slightly related thread in http://www.garlic.com/~lynn/2005h.html#36 Security via hardware? includes some reference to patent activity on authentication token integrity. and a press release from today http://www.gamesindustry.biz/press_release.php?aid=9008 an aads offering http://www.garlic.com/~lynn/index.html#aads a couple minor other postings in somewhat related threads: http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JG1dN0098370; Thu, 19 May 2005 09:01:39 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JG1dfM098369; Thu, 19 May 2005 09:01:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JG1ZYG098358 for ; Thu, 19 May 2005 09:01:35 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 17:01:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Structuring Denis issues RE: Comments on Date: Thu, 19 May 2005 17:01:19 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVci0wPlQ2MVD4RSwmFNNn/d9a6+QAAEw0Q From: "Stefan Santesson" To: "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 19 May 2005 16:01:29.0760 (UTC) FILETIME=[04EACA00:01C55C8C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JG1aYG098364 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I do want to understand! Yes, let's talk in Sophia Antipolis and save some bandwidth on this list. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 19 maj 2005 08:57 > To: Stefan Santesson > Cc: pkix > Subject: Re: Structuring Denis issues RE: Comments on crlaia-00.txt> > > Stefan, > > I'm afraid that you do not want to understand. Since you and me will be in > Sophia Antipolis in about one week from now, I propose that we stop to > discuss on this list now and have a face to face discussion there. > > Denis > > > Denis, > > > > I'm afraid that this e-mail from you doesn't help me understand your > > answer to my question (how your raised issues are related specifically > > to the use of the AIA extension in CRLs). > > > > The only argument I find in this context is that you fear that the CRL > > user would simply accept and trust the certificate they obtain through > > this extension. > > > > But this would be in violation to RFC 3280 path validation which > > specifies what you need to do to validate a certificate. These rules > > apply also to the certificate you obtained through the CRL AIA extension > > (It applies to all certificates you want to validate). Thus, an > > implementation that follows RFC 3280 when validating the certificate > > they obtained through CRL-AIA will not be subject to man-in-the-middle > > attacks and will not "simply use what they got from the pointer". > > > > Validation of the CRL Issuer certificate (and its path) is nothing new. > > The only difference introduced in this draft is an alternative way to > > discover/locate a certificate that can validate the CRL you already > > picked as a candidate CRL. > > > > To incorporate any of your proposed amendments we still need you to > > explain how each of your issues and proposed resolutions specifically > > ties to THAT particular feature introduced by this draft. > > > > > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > >>-----Original Message----- > >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >>Sent: den 19 maj 2005 08:18 > >>To: Stefan Santesson > >>Cc: pkix > >>Subject: Re: Structuring Denis issues RE: Comments on > > > > > > >>crlaia-00.txt> > >> > >>Stefan, > >> > >> > >>>Denis, > >> > >>>Thanks for the clarification. > >>>Yes, we agree on issue number 1 (remove SHOULD and MUST) > >> > >>We also agree on a typo. :-| > >> > >> > >>>So the remaining issue is: > >>> > >>>Problem: The security considerations talk about "mitigation" of the > >> > > name > > > >>>collision problem but gives inadequate advice. > >>> > >>>Your proposed resolution > >>> > >>> a) warn the user that the CRL where this extension was found may > >> > > not be > > > >>> the right one. > >> > >>The AIA extension in found in a CRL that is not yet checked to be the > >>right one. > >> > >> > >>> b) warn the user that the CRL issuer certificate he might obtain > >> > > using > > > >>> this extension may not be the right one. > >> > >>The AIA extension does not provide enough information so that the CRL > >>issuer > >> certificate that is found there is indeed the right one, since at > > > > this > > > >>time the certification path is not yet formed. There may be a > >>man-in-the-middle attack. > >> > >> > >>> c) provide guidance on how to GUARANTEE that the CRL Issuer is > >> > > indeed > > > >>> the one nominated by the CA that has issued the target > >> > > certificate > > > >>> (i.e. when the CRL Issuer certification path and the target > >>> certificate certification path are identical). > >> > >>This would indeed be a useful guidance given the two above statements. > >> > >> > >>> d) say that other possibilities exists, but need additional trust > >>> conditions (there are zillions of such possible trust > >> > > conditions). > > > >>This would indeed be a useful guidance given the previous statement. > >> > >>I am spending a *considerable* time on this issue and I believe that > > > > you > > > >>have now perfectly understood what the problem is. > >> > >>You know that I do not consider the AIA extension useful in the > > > > "basic" > > > >>case. > >> > >>Since the other cases (the "zillions" of other cases) rely anyway on > >>additional local trust conditions, some local configuration values may > > > > be > > > >>used to know where to fetch the missing CRL issuer certificates, hence > > > > why > > > >>this extension is not really useful and may even be dangerous to be > > > > used > > > >>if > >>people simply use what they get from the pointer. > >> > >>Denis > >> > >> > >>>To complete the picture it would now be very helpful if you, for > >> > > each of > > > >>>these statements, could confirm or explain how these issues are a > >> > > result > > > >>>of using the AIA extension in CRLs. Or in other words, which of > >> > > these > > > >>>security considerations could you ignore (would go away) if you were > >> > > NOT > > > >>>using the AIA extension in a CRL to locate the CRL Issuer > >> > > certificate. > > > >>> > >>> > >>>Stefan Santesson > >>>Program Manager, Standards Liaison > >>>Windows Security > >>> > >>> > >>> > >>> > >> > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFu4UL097994; Thu, 19 May 2005 08:56:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JFu4fU097993; Thu, 19 May 2005 08:56:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFu2nW097976 for ; Thu, 19 May 2005 08:56:03 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA13042; Thu, 19 May 2005 18:10:59 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051917555444:1912 ; Thu, 19 May 2005 17:55:54 +0200 Message-ID: <428CB744.1000701@bull.net> Date: Thu, 19 May 2005 17:56:52 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: Structuring Denis issues RE: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 17:55:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 17:55:56, Serialize complete at 19/05/2005 17:55:56 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, I'm afraid that you do not want to understand. Since you and me will be in Sophia Antipolis in about one week from now, I propose that we stop to discuss on this list now and have a face to face discussion there. Denis > Denis, > > I'm afraid that this e-mail from you doesn't help me understand your > answer to my question (how your raised issues are related specifically > to the use of the AIA extension in CRLs). > > The only argument I find in this context is that you fear that the CRL > user would simply accept and trust the certificate they obtain through > this extension. > > But this would be in violation to RFC 3280 path validation which > specifies what you need to do to validate a certificate. These rules > apply also to the certificate you obtained through the CRL AIA extension > (It applies to all certificates you want to validate). Thus, an > implementation that follows RFC 3280 when validating the certificate > they obtained through CRL-AIA will not be subject to man-in-the-middle > attacks and will not "simply use what they got from the pointer". > > Validation of the CRL Issuer certificate (and its path) is nothing new. > The only difference introduced in this draft is an alternative way to > discover/locate a certificate that can validate the CRL you already > picked as a candidate CRL. > > To incorporate any of your proposed amendments we still need you to > explain how each of your issues and proposed resolutions specifically > ties to THAT particular feature introduced by this draft. > > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: den 19 maj 2005 08:18 >>To: Stefan Santesson >>Cc: pkix >>Subject: Re: Structuring Denis issues RE: Comments on > > >>crlaia-00.txt> >> >>Stefan, >> >> >>>Denis, >> >>>Thanks for the clarification. >>>Yes, we agree on issue number 1 (remove SHOULD and MUST) >> >>We also agree on a typo. :-| >> >> >>>So the remaining issue is: >>> >>>Problem: The security considerations talk about "mitigation" of the >> > name > >>>collision problem but gives inadequate advice. >>> >>>Your proposed resolution >>> >>> a) warn the user that the CRL where this extension was found may >> > not be > >>> the right one. >> >>The AIA extension in found in a CRL that is not yet checked to be the >>right one. >> >> >>> b) warn the user that the CRL issuer certificate he might obtain >> > using > >>> this extension may not be the right one. >> >>The AIA extension does not provide enough information so that the CRL >>issuer >> certificate that is found there is indeed the right one, since at > > this > >>time the certification path is not yet formed. There may be a >>man-in-the-middle attack. >> >> >>> c) provide guidance on how to GUARANTEE that the CRL Issuer is >> > indeed > >>> the one nominated by the CA that has issued the target >> > certificate > >>> (i.e. when the CRL Issuer certification path and the target >>> certificate certification path are identical). >> >>This would indeed be a useful guidance given the two above statements. >> >> >>> d) say that other possibilities exists, but need additional trust >>> conditions (there are zillions of such possible trust >> > conditions). > >>This would indeed be a useful guidance given the previous statement. >> >>I am spending a *considerable* time on this issue and I believe that > > you > >>have now perfectly understood what the problem is. >> >>You know that I do not consider the AIA extension useful in the > > "basic" > >>case. >> >>Since the other cases (the "zillions" of other cases) rely anyway on >>additional local trust conditions, some local configuration values may > > be > >>used to know where to fetch the missing CRL issuer certificates, hence > > why > >>this extension is not really useful and may even be dangerous to be > > used > >>if >>people simply use what they get from the pointer. >> >>Denis >> >> >>>To complete the picture it would now be very helpful if you, for >> > each of > >>>these statements, could confirm or explain how these issues are a >> > result > >>>of using the AIA extension in CRLs. Or in other words, which of >> > these > >>>security considerations could you ignore (would go away) if you were >> > NOT > >>>using the AIA extension in a CRL to locate the CRL Issuer >> > certificate. > >>> >>> >>>Stefan Santesson >>>Program Manager, Standards Liaison >>>Windows Security >>> >>> >>> >>> >> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFlBtG097005; Thu, 19 May 2005 08:47:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JFlBHC097004; Thu, 19 May 2005 08:47:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFlA2c096977 for ; Thu, 19 May 2005 08:47:10 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 May 2005 16:47:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Structuring Denis issues RE: Comments on Date: Thu, 19 May 2005 16:46:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVchcOzseRg2KtJRVOPauPghsh8WQAASM0A From: "Stefan Santesson" To: "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 19 May 2005 15:47:04.0490 (UTC) FILETIME=[012D10A0:01C55C8A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4JFlB2c096998 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, I'm afraid that this e-mail from you doesn't help me understand your answer to my question (how your raised issues are related specifically to the use of the AIA extension in CRLs). The only argument I find in this context is that you fear that the CRL user would simply accept and trust the certificate they obtain through this extension. But this would be in violation to RFC 3280 path validation which specifies what you need to do to validate a certificate. These rules apply also to the certificate you obtained through the CRL AIA extension (It applies to all certificates you want to validate). Thus, an implementation that follows RFC 3280 when validating the certificate they obtained through CRL-AIA will not be subject to man-in-the-middle attacks and will not "simply use what they got from the pointer". Validation of the CRL Issuer certificate (and its path) is nothing new. The only difference introduced in this draft is an alternative way to discover/locate a certificate that can validate the CRL you already picked as a candidate CRL. To incorporate any of your proposed amendments we still need you to explain how each of your issues and proposed resolutions specifically ties to THAT particular feature introduced by this draft. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 19 maj 2005 08:18 > To: Stefan Santesson > Cc: pkix > Subject: Re: Structuring Denis issues RE: Comments on crlaia-00.txt> > > Stefan, > > > Denis, > > > Thanks for the clarification. > > Yes, we agree on issue number 1 (remove SHOULD and MUST) > > We also agree on a typo. :-| > > > So the remaining issue is: > > > > Problem: The security considerations talk about "mitigation" of the name > > collision problem but gives inadequate advice. > > > > Your proposed resolution > > > > a) warn the user that the CRL where this extension was found may not be > > the right one. > > The AIA extension in found in a CRL that is not yet checked to be the > right one. > > > b) warn the user that the CRL issuer certificate he might obtain using > > this extension may not be the right one. > > The AIA extension does not provide enough information so that the CRL > issuer > certificate that is found there is indeed the right one, since at this > time the certification path is not yet formed. There may be a > man-in-the-middle attack. > > > c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed > > the one nominated by the CA that has issued the target certificate > > (i.e. when the CRL Issuer certification path and the target > > certificate certification path are identical). > > This would indeed be a useful guidance given the two above statements. > > > d) say that other possibilities exists, but need additional trust > > conditions (there are zillions of such possible trust conditions). > > This would indeed be a useful guidance given the previous statement. > > I am spending a *considerable* time on this issue and I believe that you > have now perfectly understood what the problem is. > > You know that I do not consider the AIA extension useful in the "basic" > case. > > Since the other cases (the "zillions" of other cases) rely anyway on > additional local trust conditions, some local configuration values may be > used to know where to fetch the missing CRL issuer certificates, hence why > this extension is not really useful and may even be dangerous to be used > if > people simply use what they get from the pointer. > > Denis > > > To complete the picture it would now be very helpful if you, for each of > > these statements, could confirm or explain how these issues are a result > > of using the AIA extension in CRLs. Or in other words, which of these > > security considerations could you ignore (would go away) if you were NOT > > using the AIA extension in a CRL to locate the CRL Issuer certificate. > > > > > > > > Stefan Santesson > > Program Manager, Standards Liaison > > Windows Security > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFGkKb091400; Thu, 19 May 2005 08:16:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JFGkqY091399; Thu, 19 May 2005 08:16:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JFGixK091378 for ; Thu, 19 May 2005 08:16:45 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA03780; Thu, 19 May 2005 17:31:40 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051917163569:1872 ; Thu, 19 May 2005 17:16:35 +0200 Message-ID: <428CAE0E.8000406@bull.net> Date: Thu, 19 May 2005 17:17:34 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: Structuring Denis issues RE: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 17:16:35, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 19/05/2005 17:16:37, Serialize complete at 19/05/2005 17:16:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, > Denis, > Thanks for the clarification. > Yes, we agree on issue number 1 (remove SHOULD and MUST) We also agree on a typo. :-| > So the remaining issue is: > > Problem: The security considerations talk about "mitigation" of the name > collision problem but gives inadequate advice. > > Your proposed resolution > > a) warn the user that the CRL where this extension was found may not be > the right one. The AIA extension in found in a CRL that is not yet checked to be the right one. > b) warn the user that the CRL issuer certificate he might obtain using > this extension may not be the right one. The AIA extension does not provide enough information so that the CRL issuer certificate that is found there is indeed the right one, since at this time the certification path is not yet formed. There may be a man-in-the-middle attack. > c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed > the one nominated by the CA that has issued the target certificate > (i.e. when the CRL Issuer certification path and the target > certificate certification path are identical). This would indeed be a useful guidance given the two above statements. > d) say that other possibilities exists, but need additional trust > conditions (there are zillions of such possible trust conditions). This would indeed be a useful guidance given the previous statement. I am spending a *considerable* time on this issue and I believe that you have now perfectly understood what the problem is. You know that I do not consider the AIA extension useful in the "basic" case. Since the other cases (the "zillions" of other cases) rely anyway on additional local trust conditions, some local configuration values may be used to know where to fetch the missing CRL issuer certificates, hence why this extension is not really useful and may even be dangerous to be used if people simply use what they get from the pointer. Denis > To complete the picture it would now be very helpful if you, for each of > these statements, could confirm or explain how these issues are a result > of using the AIA extension in CRLs. Or in other words, which of these > security considerations could you ignore (would go away) if you were NOT > using the AIA extension in a CRL to locate the CRL Issuer certificate. > > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JAg34F088767; Thu, 19 May 2005 03:42:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4JAg35T088766; Thu, 19 May 2005 03:42:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4JAg1h6088734 for ; Thu, 19 May 2005 03:42:01 -0700 (PDT) (envelope-from diegofv@eresmas.com) Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 1DY2rV-0006tN-00; Tue, 17 May 2005 16:15:57 +0200 From: To: Simon_McMahon@health.qld.gov.au Cc: housley@vigilsec.com, ietf-pkix@vpnc.org Message-ID: Date: Tue, 17 May 2005 14:15:59 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: RE: Re: key usage - key encipherment or data encipherment X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: But, if the asymmetric private key is based on elliptic curves? Diego ----- Mensaje Original ----- Remitente: "Simon McMahon" Simon_McMahon@health.qld.gov.au Destinatario: housley@vigilsec.com, ietf-pkix@vpnc.org Fecha: Martes, Mayo 17, 2005 1:03am Asunto: Re: key usage - key encipherment or data encipherment > >The example for 'keyEncipherment' should not include an "RSA public >key encrypting an asymmetric private key", which, if it is also RSA >is too big to encrypt with the public key. Surely, an RFC shouldn't >list impossible cases as examples. > >Simon. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ILoImY076118; Wed, 18 May 2005 14:50:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4ILoIik076117; Wed, 18 May 2005 14:50:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ILoGkZ076089 for ; Wed, 18 May 2005 14:50:17 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 May 2005 22:50:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Request for new work item - Defining an SRV RR otherName Date: Wed, 18 May 2005 22:49:32 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for new work item - Defining an SRV RR otherName Thread-Index: AcVa49B3OIJ65dJPQLOybWmgvDp/swBDTguw From: "Stefan Santesson" To: X-OriginalArrivalTime: 18 May 2005 21:50:11.0221 (UTC) FILETIME=[90AAA450:01C55BF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4ILoHkZ076112 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I have just submitted a new personal draft under the name: draft-santesson-pkix-srvrr-00 and I hope this draft will be available from the IETF server soon. With this mail, I request this WG to consider acceptance of this draft as a PKIX work item. The purpose of this draft is to facilitate inclusion of a service name to a X.509 certificate subject in the form of a DNS Service Resource Record (SRV RR). The primary immediate need for this draft is to resolve some of the last hard issues with Kerberos PKINIT which still lack a way to express that a certificate is issued to a host which act as a kdc server. The PKINIT draft suggested recently that a SRV RR (_kdc._tcp.realm) could be placed in a dNSName in SubjectAltName extension, but this would be incompatible with RFC 3280 definition of dNSName and would cause issues with name constraints. To fill this void, implementation of PKINIT will strongly benefit from the definition of a new otherName to express SRV RR in X.509 certificates. Since the use of SRV RR is a generic feature, not only relevant to Kerberos, the proposal is to define this otherName in PKIX. Below is the introduction and otherName definition pasted from the submitted draft. 1. Introduction RFC 2782 [N3] Defines a DNS RR (Resource Record) for specifying the location of services (SRV RR) which allows clients to ask for a specific service/protocol for a specific domain and get back the names of any available servers. Current defined dNSName GeneralName name forms only provide for DNS host names to be expressed in "preferred name syntax," as specified by RFC 1034 [N4]. This definition is not broad enough to allow expression of a SRV RR. To accommodate expression of a SRV RR in X.509 certificates this document therefore defines an otherName for SRV RR. As DNS query based on an SRV RR returns the name of the host currently available for the requested service, reasonable subsequent authentication of that host as the appropriate host for the service will require the host to demonstrate that it is an authorized to provide the requested service. The ability to associate a host with a SRV RR in an X.509 certificate therefore facilitates the binding of the host to the originally requested SRV RR in order to protect against DNS spoofing attacks where an altered DNS could return the host name of a rouge or hacked host. One example where expression of a SRV RR can be very useful is to identify a host as a legitimate Kerberos KDC server. 2. SRV RR otherName This section defines the SRVRRName as a form of otherName from the GeneralName structure in SubjectAltName. The SRVRRName if present MUST contain a Service Resource Record (SRV RR) formed according to RFC 2782 [N3]. The use of a SRVRRName is OPTIONAL. The SRVRRName is defined as follows: id-on-sRVRRName OBJECT IDENTIFIER ::= { id-on ? } SRVRRName ::= IA5String Stefan Santesson Program Manager, Standards Liaison Windows Security Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IIfBlG035250; Wed, 18 May 2005 11:41:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4IIfBSk035249; Wed, 18 May 2005 11:41:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail3.firstdata.com (mail3.firstdata.com [198.184.5.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IIf9HM035223 for ; Wed, 18 May 2005 11:41:10 -0700 (PDT) (envelope-from lynn.wheeler@firstdata.com) Received: from ([198.184.5.26]) by mail3.firstdata.com with SMTP id KP-AXLZC.11341770; Wed, 18 May 2005 14:40:46 -0400 Received: from mdhagsmtp01.firstdata.com (198.184.5.21) by MDSIGABA01.firstadata.com (Sigaba Gateway v3.8) with ESMTP id 2040605; Wed, 18 May 2005 14:47:18 -0400 Subject: Re: EuroPKI 2005 - Call for Participation To: David Chadwick Cc: PKIX X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: lynn.wheeler@firstdata.com Date: Wed, 18 May 2005 12:40:23 -0600 X-MIMETrack: Serialize by Router on MDHAGSMTP01/MD/FDMS/FDC(Release 6.5.2|June 01, 2004) at 05/18/2005 02:46:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: at 8:14 am 5/18/05, d.w.chadwick@salford.ac.uk wrote: > > CALL FOR PARTICIPATION > > The EuroPKI 2005 Conference will be held in Canterbury, England, 30 June > - 1 July 2005. > > Registration is now open. See > > http://sec.cs.kent.ac.uk/europki2005/registration.shtml > > Early registration closes on 1 June, so book now to secure your place. > > The Keynote Speech will be given by Dr Carlise Adams, and is entitled > "PKI: Views from the Dispassionate "I", in which he will present his > thoughts on why PKI has been available as an authentication technology > for many years now, but has only enjoyed large-scale success in fairly > limited contexts to date. He will also present his thoughts on the > possible future(s) of this technology, with emphasis on the major > factors hindering adoption and some potential directions for future > research in these areas. from 3-factor authentication paradigm http://www.garlic.com/~lynn/subpubkey.html#3factor * something you have * something you know * something you are that verification of a digital signature with a public key is a form of "something you have" authentication ... i.e. the subject has access and use of the corresponding private key. note, however, it has seemed that the majority of certification authorities (mainstay of most formal PKIs) are embroiled in identification issues, not authentication ... aka the certification binding of some information to a public key (and the production of the resulting certificate). i've frequently claimed that this paradigm was disigned to address the offline email scenario from the early 80s ... where the recipient had absolutely no recourse to information about an otherwise anomomous sender that the recipient never had any previous communication with (aka the letters of credit model from the sailing ship days). the recipient, dialed their local electronic postoffice, exchanged email, and then hungup. the recipient then found themself with an email from a total stranger, there had never been any prior communication, and the recipient lack any means for discoverying any information about the stanger. the early 90s saw x.509 identification certificates. however, there was some tendency by certification authorities looking at significantly overload such certificates with enormous amounts of personal information (not really being able to predict the future about what relying parties and/or what business processes might be targets for such certificates, and therefor not reliably being able to predict what relying parties might expect in the way of identification information). in the mid-90s some of the institutions (like financial) industry) ... looking at such identity certificates realized that they represented enormous privacy and liability issues and you saw some retrenchment to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo these certificates frequently contained little more certified information than some form of account number bound to a public key. however, it was trivial to show that such reply-party-only certificates not only violated the original certiicate design point (total stranger communicating for the first time with a offline relying-party that had no other recourse to information about the originator), but also were redundant and superfluous (aka the relying-party having registered the public key and issued the relying-party-only certificate ... would have a superset of every bit of information contained in a certificate ... including the public key). in the financial industry situation ... where the redundant and superfluous certificates were being targeted at payment transactions ... aka a consumer would create a payment transaction, digitally signed it and transmit the transaction, the digital signature, and the reply-party-only certificate back to the issuing institution. Not only did the relying-party (destination of the payment transaction) alerady have access to a superset of the information contained in a redundant and superfluous digital certificate ... but it turns out that the nominal payment transaction size is on the order of 60-80 bytes. The typical redundant and superfluous relying-party-only certificate from the period could be on the order of 4k-12k bytes. So not only were the relying-party-only certificates redundant and superfluous, but in such situations they also represented a factor of 100 times payload bloat. It is actually possible to deploy authentication infrastructures that use digital signature verification http://www.garlic.com/~lynn/subpubkey.html#certless that avoid getting embroiled in the identification issues that seem to accompany many PKI deployments. -- Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IF26Fq093069; Wed, 18 May 2005 08:02:06 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4IF26BL093068; Wed, 18 May 2005 08:02:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from lon1-mail-2.visp.demon.net (IDENT:mirapoint@lon1-mail-2.visp.demon.net [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4IF25jP093061 for ; Wed, 18 May 2005 08:02:06 -0700 (PDT) (envelope-from d.w.chadwick@salford.ac.uk) Received: from [195.158.102.164] (as9p164.access.maltanet.net [195.158.102.164]) by lon1-mail-2.visp.demon.net (MOS 3.4.6-GR) with ESMTP id CHL63992 (AUTH maggiewilliams@beeb.net); Wed, 18 May 2005 15:14:44 +0100 (BST) Message-ID: <428B4DCE.3040005@salford.ac.uk> Date: Wed, 18 May 2005 15:14:38 +0100 From: David Chadwick Organization: University of Salford User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: PKIX Subject: EuroPKI 2005 - Call for Participation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: CALL FOR PARTICIPATION The EuroPKI 2005 Conference will be held in Canterbury, England, 30 June - 1 July 2005. Registration is now open. See http://sec.cs.kent.ac.uk/europki2005/registration.shtml Early registration closes on 1 June, so book now to secure your place. The Keynote Speech will be given by Dr Carlise Adams, and is entitled "PKI: Views from the Dispassionate "I", in which he will present his thoughts on why PKI has been available as an authentication technology for many years now, but has only enjoyed large-scale success in fairly limited contexts to date. He will also present his thoughts on the possible future(s) of this technology, with emphasis on the major factors hindering adoption and some potential directions for future research in these areas. The Programme will have sessions on: authorization, risks/attacks to PKI systems, interoperability between systems, evaluating a CA, ID ring based signatures, new protocols, practical implementations and long term archiving. The full programme can be seen at http://sec.cs.kent.ac.uk/europki2005/programme.shtml The Conference Banquet will take place in the historic Dover Castle and will be preceeded by a trip around the labyrinth of tunnels holding World War Two archives where Winston Churchill did must of his war time planning http://www.plus44.com/heritage/dover/dovercast.htm I look forward to meeting you there David Chadwick -- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security IS Institute, University of Salford, Salford M5 4WT Tel: +44 161 295 5351 Fax +44 1484 532930 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@salford.ac.uk Home Page: http://www.salford.ac.uk/its024/chadwick.htm Research Web site: http://sec.isi.salford.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I6CrUp093705; Tue, 17 May 2005 23:12:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4I6CrXu093704; Tue, 17 May 2005 23:12:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I6CpxD093683 for ; Tue, 17 May 2005 23:12:52 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 2B0C935B08; Wed, 18 May 2005 18:12:50 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17798-12; Wed, 18 May 2005 18:12:50 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id D0B5835B1F; Wed, 18 May 2005 18:12:46 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4970E3774B; Wed, 18 May 2005 18:12:46 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DYHnX-0005Gc-00; Wed, 18 May 2005 18:12:51 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, pgut001@cs.auckland.ac.nz Subject: Re: Improving PKCS#11 Cc: ietf-pkix@vpnc.org, kent@bbn.com In-Reply-To: <4289E310.9020407@bull.net> Message-Id: Date: Wed, 18 May 2005 18:12:51 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas writes: >The purpose is to make impossible, whatever the user application asks, to >extract the private key in the clear. Since the flags are ultimately controlled by the user app (no matter what you call them or where you put them), the user app is *always* going to get the key if it really wants it. The only thing that'll stop it is if the hardware prevents this (see below). >> If the hardware makes >> it unextractable (e.g. in Fortezza cards), it'll implicitly set >> CKA_EXTRACTABLE for you. > >The hardware cannot do anything since currently the setting of the flag >CKA_EXTRACTABLE is left to the application. That's merely a request from the software side. A Fortezza card isn't going to give you the key, no matter what you set CKA_EXTRACTABLE to. Conversely, a Cryptoflex (at least the older ones) will always give you the key because it only contains a private-key engine (you can't even do public-key encryption with it). So if you try and set the flag in a way that isn't supported by the hardware, you'll get a template-inconsistent error (or you may get the object created but with the template modified according to the hardware capabilities, depending on the implementation). Ultimately, the crypto hardware gets the last word, not an application-set flag. Unlike PKIX, the PKCS #11 folks are somewhat reluctant to set standards requirements that violate the laws of physics. >I do not think so: the purpose is not to modify any existing command, but to >add only ONE new one which might be called something like: > >C_UnwrapKeyCkaExtractableFalse > >where the certificate used to perform the operation would have a key usage >like: keyEnciphermentNoExtract. This means that the "cryptographic material", >once decrypted, cannot be extracted. But again, this depends *entirely* on the calling software. It doesn't matter how you dress this up, if the calling app wants the key, all it has to do is call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse, or set CKA_EXTRACTABLE to true in the template for C_UnwrapKey, or whatever. If the calling app wants to it can look at the cert, see that keyEncipherment is set to true and dataEncipherment false, and then go ahead and set CKA_EXTRACTABLE to true or call C_UnwrapKey instead of C_UnwrapKeyCkaExtractableFalse. There is therefore no difference between C_UnwrapKeyCkaExtractableFalse and C_UnwrapKey with CKA_EXTRACTABLE set to false. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I0Gepv090924; Tue, 17 May 2005 17:16:40 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4I0GeRA090923; Tue, 17 May 2005 17:16:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4I0GYfq090885 for ; Tue, 17 May 2005 17:16:35 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Wed, 18 May 2005 09:57:00 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Wed, 18 May 2005 09:57:00 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Wed, 18 May 2005 09:56:46 +1000 From: "Simon McMahon" To: , Cc: , , Subject: Re: Improving PKCS#11 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4I0Gafq090899 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, This discussion belongs on the PKCS11 list. > C_UnwrapKeyCkaExtractableFalse This adds nothing that isn't already in PKCS11 since the app still has to choose to call this function. Having spent many years in that working group I also know that adding top level functions is usually a last resort for any new feature. The intent appears to be to map certificate key-usage attributes, for the public key, into PKCS11 key attributes of the private key and make the PKCS11 library do it. Regardless of whether it is appropriate to do that, this is just a new C_Unwrap mechanism and they can be defined in the 'vendor defined' space so this problem already has a solution - or at least a way to do it. If no-one has written such a mechanism then they probably already solved this problem another way. If they have then that mechanism can be promoted to one of the standard mechanisms. Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Denis Pinkas 05/17/05 10:26pm >>> Peter, >>If PKCS#11 gets improved, then we could distinguish between: >> keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE >> keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE > I can't see that ever being added. If you want to make it unextractable in > the user app, No. The purpose is to make impossible, whatever the user application asks, to extract the private key in the clear. > set the CKA_EXTRACTABLE flag in the key template to false (this > is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE). If the hardware makes > it unextractable (e.g. in Fortezza cards), it'll implicitly set > CKA_EXTRACTABLE for you. The hardware cannot do anything since currently the setting of the flag CKA_EXTRACTABLE is left to the application. > There are also practical considerations. The reason for the common use of > DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage, > what'd you'd be asking there is for app developers to break compatibility with > all existing drivers in exchange for a gain so abstruse that most of them > won't even understand why it's there. I do not think so: the purpose is not to modify any existing command, but to add only ONE new one which might be called something like: C_UnwrapKeyCkaExtractableFalse where the certificate used to perform the operation would have a key usage like: keyEnciphermentNoExtract. This means that the "cryptographic material", once decrypted, cannot be extracted. So there would be no backward compatibility problem. > An addition, given the longevity of > crypto hardware devices, even if vendors (for some reason) decided to do this, > it'd take years for everything to implement it. Yes, this may take years, but since this is fairly simple, it might only take only a couple of years. :-) > Finally, some hardware (e.g. > many smart cards) can't support this, since all the card can usefully do is > the private-key op. This would apply to new smart cards only. > As a result the unwrapped key is always extractable from the card, Yes, this is the current situation, and hence why we should change it. Denis > either because it doesn't do symmetric crypto at all, because it > does it in a crippled manner that makes it useless (e.g. it zeroes all but 40 > bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or > even if it does do symmetric crypto, it's so slow that it's unusable. So > CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be > overridden by the hardware. > > Peter. > > *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HHSKmY006776; Tue, 17 May 2005 10:28:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4HHSKuY006775; Tue, 17 May 2005 10:28:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from nb2.stroeder.com (d33-84.dip.isp-service.de [83.121.33.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HHSJdA006744 for ; Tue, 17 May 2005 10:28:19 -0700 (PDT) (envelope-from michael@stroeder.com) Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id CE6D74AB0; Tue, 17 May 2005 18:23:06 +0200 (CEST) Received: from nb2.stroeder.com ([127.0.0.1]) by localhost (nb2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15066-03; Tue, 17 May 2005 18:22:53 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 389A37FE6F; Tue, 17 May 2005 18:22:47 +0200 (CEST) Message-ID: <428A1A56.9070006@stroeder.com> Date: Tue, 17 May 2005 18:22:46 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> In-Reply-To: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at stroeder.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley wrote: > > There has been a whole lot of discussion about these paragraphs. Since > some of the discussion has not been CCed to the PKIX mail list, I am > posting the resulting words. Since this discussions started by providing examples how about adding a short example section for demonstrating the appropriate usage of these bits? Ciao, Michael. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HH5uWC002855; Tue, 17 May 2005 10:05:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4HH5ucO002854; Tue, 17 May 2005 10:05:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HH5tjZ002839 for ; Tue, 17 May 2005 10:05:55 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4HH4oaN019899; Tue, 17 May 2005 13:05:25 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4HH4P6v000416; Tue, 17 May 2005 13:04:25 -0400 (EDT) Message-Id: <5.1.0.14.2.20050517125916.0303b1e8@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 17 May 2005 13:06:17 -0400 To: Sam Hartman From: Tim Polk Subject: Progressing 3770bis Cc: ietf-pkix@imc.org, housley@vigilsec.com, timmoore@microsoft.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sam, The PKIX WG has achieved rough consensus on 3770bis, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)". This document is ready for progression, and upon approval will obsolete RFC 3770. As with its predecessor, we are recommending progression as standards track document. (The document should cycle at Proposed Standard.) The current draft is available at http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-02.txt Thanks, Tim Polk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HCQRWD040025; Tue, 17 May 2005 05:26:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4HCQRIg040024; Tue, 17 May 2005 05:26:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4HCQPVt039978 for ; Tue, 17 May 2005 05:26:26 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA44950; Tue, 17 May 2005 14:41:00 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051714255652:181 ; Tue, 17 May 2005 14:25:56 +0200 Message-ID: <4289E310.9020407@bull.net> Date: Tue, 17 May 2005 14:26:56 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Peter Gutmann CC: kent@bbn.com, BKaliski@rsasecurity.com, ietf-pkix@vpnc.org Subject: Re: Improving PKCS#11 References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/05/2005 14:25:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/05/2005 14:26:04, Serialize complete at 17/05/2005 14:26:04 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, >>If PKCS#11 gets improved, then we could distinguish between: >> keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE >> keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE > I can't see that ever being added. If you want to make it unextractable in > the user app, No. The purpose is to make impossible, whatever the user application asks, to extract the private key in the clear. > set the CKA_EXTRACTABLE flag in the key template to false (this > is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE). If the hardware makes > it unextractable (e.g. in Fortezza cards), it'll implicitly set > CKA_EXTRACTABLE for you. The hardware cannot do anything since currently the setting of the flag CKA_EXTRACTABLE is left to the application. > There are also practical considerations. The reason for the common use of > DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage, > what'd you'd be asking there is for app developers to break compatibility with > all existing drivers in exchange for a gain so abstruse that most of them > won't even understand why it's there. I do not think so: the purpose is not to modify any existing command, but to add only ONE new one which might be called something like: C_UnwrapKeyCkaExtractableFalse where the certificate used to perform the operation would have a key usage like: keyEnciphermentNoExtract. This means that the "cryptographic material", once decrypted, cannot be extracted. So there would be no backward compatibility problem. > An addition, given the longevity of > crypto hardware devices, even if vendors (for some reason) decided to do this, > it'd take years for everything to implement it. Yes, this may take years, but since this is fairly simple, it might only take only a couple of years. :-) > Finally, some hardware (e.g. > many smart cards) can't support this, since all the card can usefully do is > the private-key op. This would apply to new smart cards only. > As a result the unwrapped key is always extractable from the card, Yes, this is the current situation, and hence why we should change it. Denis > either because it doesn't do symmetric crypto at all, because it > does it in a crippled manner that makes it useless (e.g. it zeroes all but 40 > bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or > even if it does do symmetric crypto, it's so slow that it's unusable. So > CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be > overridden by the hardware. > > Peter. > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H9W4bI078482; Tue, 17 May 2005 02:32:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4H9W4JR078481; Tue, 17 May 2005 02:32:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H9W2Ru078467 for ; Tue, 17 May 2005 02:32:03 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id CE8383551E; Tue, 17 May 2005 21:32:01 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08014-22; Tue, 17 May 2005 21:32:01 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id C25B2355BA; Tue, 17 May 2005 21:31:59 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 677F137746; Tue, 17 May 2005 21:31:59 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXyQo-00077W-00; Tue, 17 May 2005 21:32:06 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, kent@bbn.com Subject: Re: Improving PKCS#11 Cc: BKaliski@rsasecurity.com, ietf-pkix@vpnc.org In-Reply-To: <4289AF59.4030500@bull.net> Message-Id: Date: Tue, 17 May 2005 21:32:06 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas writes: >If PKCS#11 gets improved, then we could distinguish between: > > keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE > keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE I can't see that ever being added. If you want to make it unextractable in the user app, set the CKA_EXTRACTABLE flag in the key template to false (this is the same as using CKA_UNWRAP_CKA_EXTRACTABLE_FALSE). If the hardware makes it unextractable (e.g. in Fortezza cards), it'll implicitly set CKA_EXTRACTABLE for you. There are also practical considerations. The reason for the common use of DECRYPT/UNWRAP duality is for compatibility with existing drivers and usage, what'd you'd be asking there is for app developers to break compatibility with all existing drivers in exchange for a gain so abstruse that most of them won't even understand why it's there. An addition, given the longevity of crypto hardware devices, even if vendors (for some reason) decided to do this, it'd take years for everything to implement it. Finally, some hardware (e.g. many smart cards) can't support this, since all the card can usefully do is the private-key op. As a result the unwrapped key is always extractable from the card, either because it doesn't do symmetric crypto at all, because it does it in a crippled manner that makes it useless (e.g. it zeroes all but 40 bits of a 56-bit DES key, it only allows the use of a fixed key, etc etc), or even if it does do symmetric crypto, it's so slow that it's unusable. So CKA_EXTRACTABLE is at best advisory from the user's point of view, and can be overridden by the hardware. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H8jZCY062218; Tue, 17 May 2005 01:45:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4H8jZ7b062217; Tue, 17 May 2005 01:45:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H8jXNq062163 for ; Tue, 17 May 2005 01:45:34 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA36660; Tue, 17 May 2005 11:00:20 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051710451824:70 ; Tue, 17 May 2005 10:45:18 +0200 Message-ID: <4289AF59.4030500@bull.net> Date: Tue, 17 May 2005 10:46:17 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@vpnc.org, Burt Kaliski Subject: Improving PKCS#11 References: <200505131442.AHZ76956@whoami.cisco.com> <4284D424.7050509@bull.net> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/05/2005 10:45:18, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 17/05/2005 10:45:20, Serialize complete at 17/05/2005 10:45:20 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve (and Burt), I concur with you and Peter that PKCS#11 is not currently enforcing an appropriate key protection against key extraction, but this could be easily improved. Maybe RSA Security would like to improve PKCS#11 ? If PKCS#11 gets improved, then we could distinguish between: keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE Denis > At 6:21 PM +0200 5/13/05, Denis Pinkas wrote: > >> Steve, >> >> I wished that what you say would be true, however it isn't. See below. >> >>> At 8:41 AM -0600 5/13/05, Bob Bell wrote: >> >> >>>> Stephen - >>> >> >>>> Just a question for clarification. Since these bits are located in the >>>> certificate. How does that translate into knowing without knowledge >>>> based on >>>> the actual data structure itself that the data encrypted is keying >>>> material >>>> or data. It would seem to me that the contextual information based >>>> on the >>>> information exchange is more the determiner of what is intended. The >>>> bits in >>>> the certificate are to indicate if it is acceptable to use the >>>> public key >>>> for the stated purpose. At least that is my understanding. If I am >>>> wrong, >>>> please educate me. >>> >> >>>> Bob Bell >>> >> >>> Bob, >> >> >>> I can implement crypto software that never releases the bytes >>> decrypted with a private key that appears in a cert which has enabled >>> the "keyEncipherment" but not "dataEncipherment" key usage bits. The >>> intent is that a peer should never have used the public key to >>> encrypt anything but key (or key and associated control info) bits, >>> given the marking. In contrast, if the bytes I receive and decrypt >>> were encrypted using a public key from a cert that has enabled the >>> "dataEncipherment" key usage bit but not the "keyEncipherment" bit, >>> then I would expect to hand these bits to an app, and that would be >>> bad if they were really key bits. >> >> >> At this time someone who uses a certificate that has the key usage >> keyEncipherment set cannot know whether the "keying material" can be >> released or not by the receiving application (that owns the private key). > > > that's true. > >> Let us look what PKCS#11 states about the mapping of X.509 key usage >> flags to cryptoki attributes for private keys for CKA_DECRYPT and >> CKA_UNWRAP: >> >> Table 35, Mapping of X.509 key usage flags to cryptoki attributes >> for private keys >> >> Key usage flags for public keys Corresponding cryptoki attributes >> in X.509 public key certificates for private keys >> >> dataEncipherment CKA_DECRYPT >> keyAgreement CKA_DERIVE >> keyEncipherment CKA_UNWRAP >> >> C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private >> key or secret key object. >> >> The CKA_UNWRAP attribute of the unwrapping key, which indicates whether >> the key supports unwrapping, must be TRUE. The new key will have the >> CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the >> CKA_NEVER_EXTRACTABLE >> attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default >> set to >> TRUE. >> >> It would be "nice" to be able to distinguish between C_UnwrapKey where >> the secret cannot be extractable and where it can be. >> >> We would then be able to distinguish between: >> >> keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE >> keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE >> >> I would thus propose to be able to support that distinction. > > > yes, this distinction would be nice, but Peter's messages suggests that > PKCS #11 code does not really pay much attention to the key usage bits > anyway. so, it does not seem worht pursuing. > > Steve > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H7gixE041254; Tue, 17 May 2005 00:42:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4H7giq7041253; Tue, 17 May 2005 00:42:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4H7gfE6041229 for ; Tue, 17 May 2005 00:42:42 -0700 (PDT) (envelope-from diegofv@eresmas.com) Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 1DXwid-0005jL-00; Tue, 17 May 2005 09:42:23 +0200 From: To: Simon_McMahon@health.qld.gov.au Cc: housley@vigilsec.com, ietf-pkix@vpnc.org Message-ID: Date: Tue, 17 May 2005 07:42:24 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: RE: Re: key usage - key encipherment or data encipherment X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Mensaje Original ----- Remitente: "Simon McMahon" Simon_McMahon@health.qld.gov.au Destinatario: housley@vigilsec.com, ietf-pkix@vpnc.org Fecha: Martes, Mayo 17, 2005 1:03am Asunto: Re: key usage - key encipherment or data encipherment > >The example for 'keyEncipherment' should not include an "RSA public >key encrypting an asymmetric private key", which, if it is also RSA >is too big to encrypt with the public key. Surely, an RFC shouldn't >list impossible cases as examples. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GN4WMp043798; Mon, 16 May 2005 16:04:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GN4V4U043797; Mon, 16 May 2005 16:04:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GN4TKG043785 for ; Mon, 16 May 2005 16:04:30 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Tue, 17 May 2005 09:03:17 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Tue, 17 May 2005 09:03:16 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Tue, 17 May 2005 09:03:05 +1000 From: "Simon McMahon" To: , Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GN4VKG043792 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The example for 'keyEncipherment' should not include an "RSA public key encrypting an asymmetric private key", which, if it is also RSA is too big to encrypt with the public key. Surely, an RFC shouldn't list impossible cases as examples. Simon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Russ Housley 05/13/05 05:21am >>> There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GLwiXW039317; Mon, 16 May 2005 14:58:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GLwika039316; Mon, 16 May 2005 14:58:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GLwglj039305 for ; Mon, 16 May 2005 14:58:42 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [10.84.131.244] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4GLw12o010739; Mon, 16 May 2005 17:58:04 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4284D424.7050509@bull.net> References: <200505131442.AHZ76956@whoami.cisco.com> <4284D424.7050509@bull.net> Date: Mon, 16 May 2005 17:58:00 -0400 To: Denis Pinkas From: Stephen Kent Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 6:21 PM +0200 5/13/05, Denis Pinkas wrote: >Steve, > >I wished that what you say would be true, however it isn't. See below. > >>At 8:41 AM -0600 5/13/05, Bob Bell wrote: > >>>Stephen - > >>>Just a question for clarification. Since these bits are located in the >>>certificate. How does that translate into knowing without knowledge based on >>>the actual data structure itself that the data encrypted is keying material >>>or data. It would seem to me that the contextual information based on the >>>information exchange is more the determiner of what is intended. The bits in >>>the certificate are to indicate if it is acceptable to use the public key >>>for the stated purpose. At least that is my understanding. If I am wrong, >>>please educate me. > >>>Bob Bell > >>Bob, > >>I can implement crypto software that never releases the bytes >>decrypted with a private key that appears in a cert which has >>enabled the "keyEncipherment" but not "dataEncipherment" key usage >>bits. The intent is that a peer should never have used the public >>key to encrypt anything but key (or key and associated control >>info) bits, given the marking. In contrast, if the bytes I receive >>and decrypt were encrypted using a public key from a cert that has >>enabled the "dataEncipherment" key usage bit but not the >>"keyEncipherment" bit, then I would expect to hand these bits to an >>app, and that would be bad if they were really key bits. > >At this time someone who uses a certificate that has the key usage >keyEncipherment set cannot know whether the "keying material" can be >released or not by the receiving application (that owns the private >key). that's true. >Let us look what PKCS#11 states about the mapping of X.509 key usage >flags to cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP: > >Table 35, Mapping of X.509 key usage flags to cryptoki attributes >for private keys > >Key usage flags for public keys Corresponding cryptoki attributes >in X.509 public key certificates for private keys > >dataEncipherment CKA_DECRYPT >keyAgreement CKA_DERIVE >keyEncipherment CKA_UNWRAP > >C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private >key or secret key object. > >The CKA_UNWRAP attribute of the unwrapping key, which indicates whether >the key supports unwrapping, must be TRUE. The new key will have the >CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the CKA_NEVER_EXTRACTABLE >attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default set to >TRUE. > > It would be "nice" to be able to distinguish between C_UnwrapKey where > the secret cannot be extractable and where it can be. > > We would then be able to distinguish between: > > keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE > keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE > > I would thus propose to be able to support that distinction. yes, this distinction would be nice, but Peter's messages suggests that PKCS #11 code does not really pay much attention to the key usage bits anyway. so, it does not seem worht pursuing. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GHQgqh016776; Mon, 16 May 2005 10:26:42 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GHQgF1016775; Mon, 16 May 2005 10:26:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GHQfLG016766 for ; Mon, 16 May 2005 10:26:41 -0700 (PDT) (envelope-from tgindin@us.ibm.com) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e1.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j4GHQZRi014530 for ; Mon, 16 May 2005 13:26:35 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j4GHQWXn108540 for ; Mon, 16 May 2005 13:26:35 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j4GHQVpR030800 for ; Mon, 16 May 2005 13:26:31 -0400 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j4GHQVJG030762; Mon, 16 May 2005 13:26:31 -0400 In-Reply-To: <008501c55a29$db9b3c70$9a00a8c0@hq.orionsec.com> To: "Santosh Chokhani" Cc: "'Russ Housley'" , ietf-pkix@vpnc.org MIME-Version: 1.0 Subject: RE: key usage - key encipherment or data encipherment X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Tom Gindin Message-ID: Date: Mon, 16 May 2005 13:26:26 -0400 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/16/2005 13:26:29, Serialize complete at 05/16/2005 13:26:30, Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF14|April 18, 2005) at 05/16/2005 13:26:30 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It should probably just be "without the use of any symmetric cipher", instead of wondering whether it's intermediate or not. Tom Gindin "Santosh Chokhani" Sent by: owner-ietf-pkix@mail.imc.org 05/16/2005 11:13 AM To: "'Russ Housley'" , cc: Subject: RE: key usage - key encipherment or data encipherment Russ, Looks good except the "intermediate symmetric cipher" in the last paragraph should be "symmetric cipher" since the symmetric cipher in most cases in not "intermediate". Another alternative is to use the term "intermediate asymmetric cipher", but that might be confusing. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 3:21 PM To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GFDoYD005379; Mon, 16 May 2005 08:13:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GFDot1005378; Mon, 16 May 2005 08:13:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GFDnvS005372 for ; Mon, 16 May 2005 08:13:50 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (static-70-21-127-143.res.east.verizon.net [70.21.127.143]) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4GFDkff018520; Mon, 16 May 2005 11:13:47 -0400 From: "Santosh Chokhani" To: "'Russ Housley'" , Subject: RE: key usage - key encipherment or data encipherment Date: Mon, 16 May 2005 11:13:41 -0400 Message-ID: <008501c55a29$db9b3c70$9a00a8c0@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4GFDovS005373 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Looks good except the "intermediate symmetric cipher" in the last paragraph should be "symmetric cipher" since the symmetric cipher in most cases in not "intermediate". Another alternative is to use the term "intermediate asymmetric cipher", but that might be confusing. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 3:21 PM To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4GDQqFT091400; Mon, 16 May 2005 06:26:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4GDQqM6091399; Mon, 16 May 2005 06:26:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from 21cn.com (send.forptr.21cn.com [202.105.45.47]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4GDQFq7091352 for ; Mon, 16 May 2005 06:26:48 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.6 P2) with SMTP id jm94288d637; Mon, 16 May 2005 21:28:11 +0800 Received: from 21cn.com([10.2.1.9]) by 21cn.com(AIMC 2.9.5.4) with SMTP id AISP action; Mon, 16 May 2005 21:28:11 +0800 Received: from above.proper.com([10.2.100.8]) by 21cn.com(AIMC 2.9.5.6) with SMTP id jm904283ba6f; Fri, 13 May 2005 03:27:30 +0800 Received: from above.proper.com([208.184.76.39]) by 21cn.com(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 13 May 2005 03:20:21 +0800 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJL7jP010841; Thu, 12 May 2005 12:21:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CJL7DZ010840; Thu, 12 May 2005 12:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CJL6Gt010834 for ; Thu, 12 May 2005 12:21:06 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8024 invoked by uid 0); 12 May 2005 19:20:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.201) by woodstock.binhost.com with SMTP; 12 May 2005 19:20:59 -0000 Message-Id: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 15:21:02 -0400 To: ietf-pkix@vpnc.org From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Archive: List-ID: List-Unsubscribe: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: owner-ietf-pkix@mail.imc.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: housley@vigilsec.com Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G6tEjR059688; Sun, 15 May 2005 23:55:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4G6tEpS059687; Sun, 15 May 2005 23:55:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G6tC6N059668 for ; Sun, 15 May 2005 23:55:12 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 0AF6C3460A; Mon, 16 May 2005 18:55:11 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13795-16; Mon, 16 May 2005 18:55:10 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 9A5CE33F52; Mon, 16 May 2005 18:55:10 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 679C43774A; Mon, 16 May 2005 18:55:10 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXZVU-0005gZ-00; Mon, 16 May 2005 18:55:16 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, pgut001@cs.auckland.ac.nz, Simon_McMahon@health.qld.gov.au Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <6.2.1.2.2.20050515151459.05940600@mail.binhost.com> Message-Id: Date: Mon, 16 May 2005 18:55:16 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ Housley writes: >This would be quite a change from the current meaning of the bits, not a >clarification. Well, it would change the current text describing the bits, but not the way the bits are being used in practice. In other words the changed text would then match the way the bits are actually being used. It'd resolve the ambiguity and fix the current problem in a single step. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G0Rqhu095648; Sun, 15 May 2005 17:27:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4G0Rq57095647; Sun, 15 May 2005 17:27:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4G0RlTh095638 for ; Sun, 15 May 2005 17:27:48 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Mon, 16 May 2005 10:25:11 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Mon, 16 May 2005 10:25:11 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Mon, 16 May 2005 10:25:01 +1000 From: "Simon McMahon" To: "<\"Wen-Cheng Wang\"" Cc: "<" Subject: RE: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4G0RmTh095640 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wen-Cheng Wang's last post looks OK to me but I would drop "RSA" and "content-decryption" from the example. I still don't see how an RSA public key can directly encrypt a private key, unless its heaps smaller, so I dropped that from the example too. 'Private' keys are also 'secret' keys anyway. I didn't change 'dataEncipherment' from Wang's post. proposed text: The keyEncipherment bit is asserted when the subject public key is used for enciphering cryptographic keys or keying materials. For example, this bit shall be set when a RSA public key is to be used for key transport that involves encrypting a secret key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data, other than cryptographic keys or keying materials, without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish shared cryptographic keys. The 'note' at the end of dataEncipherment effectively deprecates this bit but I'm sure it will continue to see many more interoperability issues in the future. I think that Peter's observation: keyEncipherment = ephemeral session key establishment (e.g. SSL). dataEncipherment = content-encryption key establishment (e.g. S/MIME). Is what industry will continue to do regardless of the RFC text since a bit that is there with no obvious use may as well get used for something. The 'PIN' reference from another post was another good grey area that can justify the use of either bit however the RFC gets worded. The overloading of the bits to imply security policy for the private key's decryption op is the riskiest use of these bits but will obviously continue too. The bits, as defined by the RFC, obviously don't matter very much to PKI security which is why no-one could nail down what they actually mean and industry usage varies so widely. They are just an interoperability issue waiting to happen (again). Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4FJGJm4075191; Sun, 15 May 2005 12:16:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4FJGJGj075190; Sun, 15 May 2005 12:16:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4FJGHe0075181 for ; Sun, 15 May 2005 12:16:17 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8039 invoked by uid 0); 15 May 2005 19:16:09 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.92.68) by woodstock.binhost.com with SMTP; 15 May 2005 19:16:09 -0000 Message-Id: <6.2.1.2.2.20050515151459.05940600@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 15 May 2005 15:16:12 -0400 To: pgut001@cs.auckland.ac.nz (Peter Gutmann), Simon_McMahon@health.qld.gov.au From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter: This would be quite a change from the current meaning of the bits, not a clarification. I do not support such a change. Russ At 04:05 AM 5/15/2005, Peter Gutmann wrote: >"Simon McMahon" writes: > > >They were calling an 'encrypt' function to encrypt XML data and they gave it > >an RSA key (the cert actually) to do it. Of course it internally made an AES > >key but they never saw it until the interoperability issue made them look. > >From what they saw at the level they were looking the interpretation was > >reasonable. > >When I originally saw your posting I thought that what they were doing was a >typical clueless-user action, but on thinking about it a bit more it's >actually quite logical. Unless you're intimately familiar with the crypto >involved, it's quite sensible to use dataEncryption to mean, well, data >encryption (in the way you describe above). > > >In my opinion there are 3 cases presented as 2 in the RFC. > > > >1. RSA encrypts data - hardly ever used. > >2. RSA implicitly encrypts keys so it can really encrypt bulk data - common > > usage. > >3. RSA explicitly encrypts keys for explicit key management functions - > > common usage. > > > >The current bits separate 1 from 2/3 yet people make the interpretation that > >they split the more common 2 from 3 assuming 1 and 2 are the same thing. > >Yup. It's like the old digitalSignature vs. nonRepudiation bits, no-one could >actually clearly define what nonRepudiation did, which is why it was changed >to the current contentCommitment. So now we have: > > digitalSignature = ephemeral signatures (e.g. for authentication to an > online server). > > nonRepudiation = long-term signature (e.g. for document signatures). > >The logical corollary from this is to set: > > keyEncipherment = ephemeral session key establishment (e.g. SSL). > > dataEncipherment = content-encryption key establishment (e.g. S/MIME). > >Since everyone that's using dataEncipherment is using it for that anyway, it >clarifies the situation and requires no change in existing apps. > >(As for real raw data-encipherment, if anyone is actually using that, give > them a new flag contentEncapsulation or something with a name that can't be > confused with anything else). > > >In my opinion this problem will not entirely go away by clarifying the > >standard because most people dont read it before they implement something. > >The two bits are there and as long as they are both there then the mistake > >will be made by busy developers. Unenforceable key-usage policy, to "public" > >keys, will also continue to be implemented. People will come looking for > >clarification once they have an interoperability issue but by then it is > >often too late - the issue usually gets decided by who has the biggest > >corporate balls. In this case it wasn't too late so thanks for the > >assistance. > >Yup, that's a perfect summary of the current situation. I don't know if I'm >too happy with combining the bits, the crypto-purist in me wants to keep a >distinction between SSL vs. S/MIME-type keys for access control purposes, but >the practical part of me says this will never work, because there's no way for >a user (even if they do know the difference in key types, which very few do) >to be able to manage this in any way via a crypto API. > >The standard crypto API has some form of "gimme a key" function that returns a >key for a particular user. Some of the more sophisticated ones extend this to >"gimme a key usable for encryption" (although the best known, CryptoAPI, >allows you to use an encryption-only key for signatures because so many users >can't understand anything other than a one-size-fits-all key). None that I'm >aware of (and I've used quite a few) allow you to specify the usage of a key >for short-term but not long-term signatures, or session vs. data-encryption >key management. The only thing they understand is "sign" and "encrypt". So >even if you clarify keyEncipherment and dataEncipherment, there's no way to >manage the usage in any known CryptoAPI. > >The best the crypto software vendor can do at that point is to leave it to the >end user to check that when they call "encrypt" to encrypt an ephemeral key, >the associated cert isn't set up to only encrypt a content-encryption key. >I'll leave readers to decide what the chances are of that ever working. > >Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F8RopU058183; Sun, 15 May 2005 01:27:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4F8RonZ058182; Sun, 15 May 2005 01:27:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F8RnE0058171 for ; Sun, 15 May 2005 01:27:49 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 03CA234BA1; Sun, 15 May 2005 20:27:49 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17106-20; Sun, 15 May 2005 20:27:48 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id C690134000; Sun, 15 May 2005 20:27:47 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 63A3A37742; Sun, 15 May 2005 20:27:47 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXETZ-0003eY-00; Sun, 15 May 2005 20:27:53 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Denis.Pinkas@bull.net, kent@bbn.com Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <4284D424.7050509@bull.net> Message-Id: Date: Sun, 15 May 2005 20:27:53 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas writes: >Let us look what PKCS#11 states about the mapping of X.509 key usage flags to >cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP: Note that this usage is entirely dependent on the user. PKCS #11 sets no constraints based on the cert contents. Experience has shown that the PKCS #11 flags set by the user often bear no relation to the key flags in the cert, with keys with signature-only certs being usable for encryption and vice versa. It's not small-scale stuff either, this sort of thing goes all the way up to the European national-CA level (this isn't a purely European disease, but smart cards seem to be a lot more widely used over there, so it's more noticeable). >Key usage flags for public keys Corresponding cryptoki attributes in X.509 >public key certificates for private keys > >dataEncipherment CKA_DECRYPT >keyAgreement CKA_DERIVE >keyEncipherment CKA_UNWRAP Even that is merely theoretical guidance, since there's a lot of confusion between decryption and unwrapping keys - some apps mark keys as being for decryption and some for unwrapping. What you do is you try a decrypt first, and if that fails you try an unwrap with a CKO_SECRET_KEY of type CKK_GENERIC_SECRET, which returns the entire decrypted value, making the unwrap equivalent to a straight decrypt. So even here where you've got provision for key-wrap vs. data-encrypt, (a) it's frequently not mapped from the certificate to the PKCS #11 level and (b) even if it were, it's common practice to apply both operations in a manner that makes them equivalent, in order to handle with the way existing apps do things. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F86YYk051390; Sun, 15 May 2005 01:06:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4F86XAs051385; Sun, 15 May 2005 01:06:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F86Qd1051348 for ; Sun, 15 May 2005 01:06:27 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 1BDBB3565B; Sun, 15 May 2005 20:06:26 +1200 (NZST) Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08405-26; Sun, 15 May 2005 20:06:26 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 96C1635633; Sun, 15 May 2005 20:06:24 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 469F237742; Sun, 15 May 2005 20:06:24 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXE8s-0003c4-00; Sun, 15 May 2005 20:06:30 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: andrewsciberras@gmail.com, pgut001@cs.auckland.ac.nz, Simon_McMahon@health.qld.gov.au, wcwang@cht.com.tw Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <01a701c556b4$1987f650$4f85900a@wcwang> Message-Id: Date: Sun, 15 May 2005 20:06:30 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Wen-Cheng Wang" writes: >However, I worried that the statement "This (dataEncipherment) bit MUST NOT >be set when the intention is to encipher intermediate cryptographic keys >rather than raw user data" might mislead the reader to believe that the >keyEncipherment bit and the dataEncipherment bit are mutually exclusive. >Therefore, I suggest to revise the statement as "The dataEncipherment bit >should not be use to represent the intention of allowing enciphering >intermediate cryptographic keys. In that case, the keyEncipherment bit should >be set." Thanks, that change helps clarify the text. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F85MKb050946; Sun, 15 May 2005 01:05:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4F85M8H050938; Sun, 15 May 2005 01:05:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F85Gw7050906 for ; Sun, 15 May 2005 01:05:17 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 386D7355BB; Sun, 15 May 2005 20:05:15 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08989-29; Sun, 15 May 2005 20:05:15 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 5746D355B8; Sun, 15 May 2005 20:05:14 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 1EA1B37742; Sun, 15 May 2005 20:05:14 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXE7k-0003bt-00; Sun, 15 May 2005 20:05:20 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: housley@vigilsec.com, Simon_McMahon@health.qld.gov.au Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: Message-Id: Date: Sun, 15 May 2005 20:05:20 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Simon McMahon" writes: >They were calling an 'encrypt' function to encrypt XML data and they gave it >an RSA key (the cert actually) to do it. Of course it internally made an AES >key but they never saw it until the interoperability issue made them look. >From what they saw at the level they were looking the interpretation was >reasonable. When I originally saw your posting I thought that what they were doing was a typical clueless-user action, but on thinking about it a bit more it's actually quite logical. Unless you're intimately familiar with the crypto involved, it's quite sensible to use dataEncryption to mean, well, data encryption (in the way you describe above). >In my opinion there are 3 cases presented as 2 in the RFC. > >1. RSA encrypts data - hardly ever used. >2. RSA implicitly encrypts keys so it can really encrypt bulk data - common > usage. >3. RSA explicitly encrypts keys for explicit key management functions - > common usage. > >The current bits separate 1 from 2/3 yet people make the interpretation that >they split the more common 2 from 3 assuming 1 and 2 are the same thing. Yup. It's like the old digitalSignature vs. nonRepudiation bits, no-one could actually clearly define what nonRepudiation did, which is why it was changed to the current contentCommitment. So now we have: digitalSignature = ephemeral signatures (e.g. for authentication to an online server). nonRepudiation = long-term signature (e.g. for document signatures). The logical corollary from this is to set: keyEncipherment = ephemeral session key establishment (e.g. SSL). dataEncipherment = content-encryption key establishment (e.g. S/MIME). Since everyone that's using dataEncipherment is using it for that anyway, it clarifies the situation and requires no change in existing apps. (As for real raw data-encipherment, if anyone is actually using that, give them a new flag contentEncapsulation or something with a name that can't be confused with anything else). >In my opinion this problem will not entirely go away by clarifying the >standard because most people dont read it before they implement something. >The two bits are there and as long as they are both there then the mistake >will be made by busy developers. Unenforceable key-usage policy, to "public" >keys, will also continue to be implemented. People will come looking for >clarification once they have an interoperability issue but by then it is >often too late - the issue usually gets decided by who has the biggest >corporate balls. In this case it wasn't too late so thanks for the >assistance. Yup, that's a perfect summary of the current situation. I don't know if I'm too happy with combining the bits, the crypto-purist in me wants to keep a distinction between SSL vs. S/MIME-type keys for access control purposes, but the practical part of me says this will never work, because there's no way for a user (even if they do know the difference in key types, which very few do) to be able to manage this in any way via a crypto API. The standard crypto API has some form of "gimme a key" function that returns a key for a particular user. Some of the more sophisticated ones extend this to "gimme a key usable for encryption" (although the best known, CryptoAPI, allows you to use an encryption-only key for signatures because so many users can't understand anything other than a one-size-fits-all key). None that I'm aware of (and I've used quite a few) allow you to specify the usage of a key for short-term but not long-term signatures, or session vs. data-encryption key management. The only thing they understand is "sign" and "encrypt". So even if you clarify keyEncipherment and dataEncipherment, there's no way to manage the usage in any known CryptoAPI. The best the crypto software vendor can do at that point is to leave it to the end user to check that when they call "encrypt" to encrypt an ephemeral key, the associated cert isn't set up to only encrypt a content-encryption key. I'll leave readers to decide what the chances are of that ever working. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F5d77q090869; Sat, 14 May 2005 22:39:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4F5d7KV090868; Sat, 14 May 2005 22:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4F5d0wP090774 for ; Sat, 14 May 2005 22:39:07 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 6629A348BA; Sun, 15 May 2005 17:38:59 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10945-17; Sun, 15 May 2005 17:38:59 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 8AE1C34421; Sun, 15 May 2005 17:38:58 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3B1A237742; Sun, 15 May 2005 17:38:58 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DXBqB-0003Tr-00; Sun, 15 May 2005 17:39:03 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, mars@seguridata.com Subject: RE: key usage - key encipherment or data encipherment In-Reply-To: <000d01c5564d$c4a93060$d600a8c0@seguridata.com> Message-Id: Date: Sun, 15 May 2005 17:39:03 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Miguel A Rodriguez" writes: >Does anyone use dataEncipherment? That depends on which question you're asking. Lots of people use dataEncipherment, but I've never found anyone who uses dataEncipherment the way it's meant to be used (whenever I see it used I try and find out from the original user what they're doing with it. It's never for the X.509 definition of dataEncipherment). So the answer is both yes and no. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4E1qbkq005390; Fri, 13 May 2005 18:52:37 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4E1qb5G005389; Fri, 13 May 2005 18:52:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from hosting2.fastq.com (hosting2.fastq.com [65.39.66.251]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4E1qab9005383 for ; Fri, 13 May 2005 18:52:36 -0700 (PDT) (envelope-from mmyers@fastq.com) Received: (qmail 52788 invoked from network); 14 May 2005 01:52:35 -0000 Received: from dslstat-ppp-150.fastq.com (HELO MMyersLapTop) (65.39.92.150) by hosting2.fastq.com with SMTP; 14 May 2005 01:52:35 -0000 From: "Michael Myers" To: Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 18:49:17 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I concur with Steve's observation. The potential utility outweighs current deficiencies. Mike -----Original Message----- From: Stephen Kent Sent: Friday, May 13, 2005 6:33 AM > > . . . > > I am hesitant to have us remove this potentially > useful distinction merely because folks have not > been smart enough to make good use of it so far. > > Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DJZ4PX078112; Fri, 13 May 2005 12:35:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DJZ4Cv078111; Fri, 13 May 2005 12:35:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4DJZ0XB078103 for ; Fri, 13 May 2005 12:35:01 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 27613 invoked by uid 0); 13 May 2005 19:34:54 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.221.56) by woodstock.binhost.com with SMTP; 13 May 2005 19:34:54 -0000 Message-Id: <6.2.1.2.2.20050513152934.0610d910@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 13 May 2005 15:34:56 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: ietf-pkix@imc.org In-Reply-To: <42845E58.6010502@bull.net> References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> <42832509.5020001@bull.net> <6.2.1.2.2.20050512105428.060f0210@mail.binhost.com> <42845E58.6010502@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: >The distinction between "the CRL" and "a CRL" is pretty important. So we have identified another are where we disagree. The CRL AIA extension applies to a CRL that the certificate user has already selected. Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DHcJxR066981; Fri, 13 May 2005 10:38:19 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DHcJDR066980; Fri, 13 May 2005 10:38:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from host15.websitesource.com (host15.websitesource.com [209.239.32.38]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DHcIFk066973 for ; Fri, 13 May 2005 10:38:19 -0700 (PDT) (envelope-from chokhani@orionsec.com) Received: from wchokhani3 (PPP-219.65.51.98.mum2.dialup.vsnl.net.in [219.65.51.98] (may be forged)) by host15.websitesource.com (8.12.10/8.12.10) with ESMTP id j4DHcEAo018299 for ; Fri, 13 May 2005 13:38:16 -0400 From: "Santosh Chokhani" To: Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 13:38:08 -0400 Message-ID: <025601c557e2$8be1bea0$6e3341db@hq.orionsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To add to what Steve Kent has said in this e-mail, there is a separate bit for D-H type protocols. It is called keyAgreement. I also agree with Steve's other posting of maintaining the distinction between key encihperment and data encipherment. -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent Sent: Friday, May 13, 2005 10:15 AM To: Wen-Cheng Wang Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment At 5:48 PM +0800 5/13/05, Wen-Cheng Wang wrote: >I also hesitate to accept the term "key transport", which will result >in over-narrowing down the usage scope of the keyEncipherment bit. As >Arshad pointed out, sometimes the intention is not to transport the >encrypted symmetric key to anywhere. Besides, it is often that the >handshake protocol is not simply a "key transport" process; it is more >often be a more complex "key exchange" process. For example, >the SSL handshake protocol names it as "key exchange" >instead of "key transport". Would it be valid for a SSL server >cert to be asserted with that keyEncipherment bit? >To avoid the possible dispute on the definition of >similar terms, I would like to suggest to drop the term "key >transport" from the definition of the key usage bit. (However, >I think it is OK to use "key transport" as an example to >explain the the definition of the key usage bit. As commonly employed, a client uses an RSA public key associated with a server to encrypt and transport key bits that will later be used to create encryption and integrity keys for protecting the session. That is an example of key transport. If one used the Diffie-Hellman key agreement option for SSL, that would be accurately be described as a key exchange, but that is rarely the case, in practice. So I am puzzled by the characterization above. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DGLFiV058202; Fri, 13 May 2005 09:21:15 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DGLFDe058200; Fri, 13 May 2005 09:21:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DGLDOc058173 for ; Fri, 13 May 2005 09:21:14 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA12474; Fri, 13 May 2005 18:35:59 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051318210137:1730 ; Fri, 13 May 2005 18:21:01 +0200 Message-ID: <4284D424.7050509@bull.net> Date: Fri, 13 May 2005 18:21:56 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stephen Kent CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: <200505131442.AHZ76956@whoami.cisco.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 18:21:01, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 18:21:02, Serialize complete at 13/05/2005 18:21:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, I wished that what you say would be true, however it isn't. See below. > At 8:41 AM -0600 5/13/05, Bob Bell wrote: >> Stephen - >> Just a question for clarification. Since these bits are located in the >> certificate. How does that translate into knowing without knowledge >> based on >> the actual data structure itself that the data encrypted is keying >> material >> or data. It would seem to me that the contextual information based on the >> information exchange is more the determiner of what is intended. The >> bits in >> the certificate are to indicate if it is acceptable to use the public key >> for the stated purpose. At least that is my understanding. If I am wrong, >> please educate me. >> Bob Bell > Bob, > I can implement crypto software that never releases the bytes decrypted > with a private key that appears in a cert which has enabled the > "keyEncipherment" but not "dataEncipherment" key usage bits. The intent > is that a peer should never have used the public key to encrypt anything > but key (or key and associated control info) bits, given the marking. In > contrast, if the bytes I receive and decrypt were encrypted using a > public key from a cert that has enabled the "dataEncipherment" key usage > bit but not the "keyEncipherment" bit, then I would expect to hand these > bits to an app, and that would be bad if they were really key bits. At this time someone who uses a certificate that has the key usage keyEncipherment set cannot know whether the "keying material" can be released or not by the receiving application (that owns the private key). Let us look what PKCS#11 states about the mapping of X.509 key usage flags to cryptoki attributes for private keys for CKA_DECRYPT and CKA_UNWRAP: Table 35, Mapping of X.509 key usage flags to cryptoki attributes for private keys Key usage flags for public keys Corresponding cryptoki attributes in X.509 public key certificates for private keys dataEncipherment CKA_DECRYPT keyAgreement CKA_DERIVE keyEncipherment CKA_UNWRAP C_UnwrapKey unwraps (i.e. decrypts) a wrapped key, creating a new private key or secret key object. The CKA_UNWRAP attribute of the unwrapping key, which indicates whether the key supports unwrapping, must be TRUE. The new key will have the CKA_ALWAYS_SENSITIVE attribute set to FALSE, and the CKA_NEVER_EXTRACTABLE attribute set to FALSE. The CKA_EXTRACTABLE attribute is by default set to TRUE. It would be "nice" to be able to distinguish between C_UnwrapKey where the secret cannot be extractable and where it can be. We would then be able to distinguish between: keyEncipherment-no-extract : CKA_UNWRAP_CKA_EXTRACTABLE_FALSE keyEncipherment-extract-allowed : CKA_UNWRAP_CKA_EXTRACTABLE_TRUE I would thus propose to be able to support that distinction. Denis > Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DFhcpK054180; Fri, 13 May 2005 08:43:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DFhcdo054179; Fri, 13 May 2005 08:43:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DFhbjV054157 for ; Fri, 13 May 2005 08:43:37 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 16:43:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 16:43:27 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: key usage - key encipherment or data encipherment Thread-Index: AcVXxk6ZAwVRNk9OR6mrWR0vz+HjEwACx7qw From: "Stefan Santesson" To: "Stephen Kent" Cc: "Simon McMahon" , , , , X-OriginalArrivalTime: 13 May 2005 15:43:32.0051 (UTC) FILETIME=[8412F230:01C557D2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4DFhcjV054174 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, Even though I'm not really convinced about the benefits, maybe I should clarify that I don't want to change the bits either for legacy reasons and in order to stay in sync with X.509. I'm fine with the earlier provided wordings. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: den 13 maj 2005 15:33 > To: Stefan Santesson > Cc: Simon McMahon; Denis.Pinkas@bull.net; sharon.boeyen@entrust.com; > housley@vigilsec.com; ietf-pkix@vpnc.org > Subject: RE: key usage - key encipherment or data encipherment > > At 11:52 AM +0100 5/13/05, Stefan Santesson wrote: > >How about calling the bits "The encryption bit" and "The other > >encryption bit" :-) > > > >Jokes aside, can anyone recall the justification for having 2 different > >bits for key and data encryption? > > Despite the observation that many folks setting these bits, or > applications using these bits, don't really know the difference, > there is a difference. From a security perspective, it can be > important to know whether the bits being decrypted are data to be > handed to a user or app, or keys to be kept within the key management > subsystem. Hence there is a legitimate, security benefit that could > be obtained IF people set the bits properly. > > I am hesitant to have us remove this potentially useful distinction > merely because folks have not been smart enough to make good use of > it so far. > > Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DFLxfh052616; Fri, 13 May 2005 08:21:59 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DFLxSl052615; Fri, 13 May 2005 08:21:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DFLw5K052605 for ; Fri, 13 May 2005 08:21:58 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4DFL42o008303; Fri, 13 May 2005 11:21:06 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200505131442.AHZ76956@whoami.cisco.com> References: <200505131442.AHZ76956@whoami.cisco.com> Date: Fri, 13 May 2005 11:20:46 -0400 To: "Bob Bell" From: Stephen Kent Subject: RE: key usage - key encipherment or data encipherment Cc: "'Stefan Santesson'" , "'Simon McMahon'" , , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:41 AM -0600 5/13/05, Bob Bell wrote: >Stephen - > >Just a question for clarification. Since these bits are located in the >certificate. How does that translate into knowing without knowledge based on >the actual data structure itself that the data encrypted is keying material >or data. It would seem to me that the contextual information based on the >information exchange is more the determiner of what is intended. The bits in >the certificate are to indicate if it is acceptable to use the public key >for the stated purpose. At least that is my understanding. If I am wrong, >please educate me. > >Bob Bell > Bob, I can implement crypto software that never releases the bytes decrypted with a private key that appears in a cert which has enabled the "keyEncipherment" but not "dataEncipherment" key usage bits. The intent is that a peer should never have used the public key to encrypt anything but key (or key and associated control info) bits, given the marking. In contrast, if the bytes I receive and decrypt were encrypted using a public key from a cert that has enabled the "dataEncipherment" key usage bit but not the "keyEncipherment" bit, then I would expect to hand these bits to an app, and that would be bad if they were really key bits. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEgB1s049141; Fri, 13 May 2005 07:42:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DEgBLK049140; Fri, 13 May 2005 07:42:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEgAbK049130 for ; Fri, 13 May 2005 07:42:10 -0700 (PDT) (envelope-from rtbell@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 13 May 2005 07:42:05 -0700 X-IronPort-AV: i="3.93,107,1115017200"; d="scan'208"; a="264860157:sNHT30528536" Received: from whoami.cisco.com (IDENT:mirapoint@whoami.cisco.com [64.101.128.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4DEg1Po018198; Fri, 13 May 2005 07:42:02 -0700 (PDT) Received: from rtbellwxp (rcdn-rtbell-3002-2.cisco.com [10.89.25.211]) by whoami.cisco.com (MOS 3.4.5-GR) with ESMTP id AHZ76956; Fri, 13 May 2005 09:42:00 -0500 (CDT) Message-Id: <200505131442.AHZ76956@whoami.cisco.com> From: "Bob Bell" To: "'Stephen Kent'" , "'Stefan Santesson'" Cc: "'Simon McMahon'" , , , , Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 08:41:59 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcVXyQoiRToVpBCJR82tTt837yoH+wAAGRzw Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stephen - Just a question for clarification. Since these bits are located in the certificate. How does that translate into knowing without knowledge based on the actual data structure itself that the data encrypted is keying material or data. It would seem to me that the contextual information based on the information exchange is more the determiner of what is intended. The bits in the certificate are to indicate if it is acceptable to use the public key for the stated purpose. At least that is my understanding. If I am wrong, please educate me. Bob Bell > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Stephen Kent > Sent: Friday, May 13, 2005 07:33 > To: Stefan Santesson > Cc: Simon McMahon; Denis.Pinkas@bull.net; > sharon.boeyen@entrust.com; housley@vigilsec.com; ietf-pkix@vpnc.org > Subject: RE: key usage - key encipherment or data encipherment > > > At 11:52 AM +0100 5/13/05, Stefan Santesson wrote: > >How about calling the bits "The encryption bit" and "The other > >encryption bit" :-) > > > >Jokes aside, can anyone recall the justification for having > 2 different > >bits for key and data encryption? > > Despite the observation that many folks setting these bits, > or applications using these bits, don't really know the > difference, there is a difference. From a security > perspective, it can be important to know whether the bits > being decrypted are data to be handed to a user or app, or > keys to be kept within the key management subsystem. Hence > there is a legitimate, security benefit that could be > obtained IF people set the bits properly. > > I am hesitant to have us remove this potentially useful > distinction merely because folks have not been smart enough > to make good use of it so far. > > Steve > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEG18w046306; Fri, 13 May 2005 07:16:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DEG1AC046305; Fri, 13 May 2005 07:16:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEFxYi046293 for ; Fri, 13 May 2005 07:16:00 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4DEF52s004183; Fri, 13 May 2005 10:15:08 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 13 May 2005 09:33:16 -0400 To: "Stefan Santesson" From: Stephen Kent Subject: RE: key usage - key encipherment or data encipherment Cc: "Simon McMahon" , , , , Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:52 AM +0100 5/13/05, Stefan Santesson wrote: >How about calling the bits "The encryption bit" and "The other >encryption bit" :-) > >Jokes aside, can anyone recall the justification for having 2 different >bits for key and data encryption? Despite the observation that many folks setting these bits, or applications using these bits, don't really know the difference, there is a difference. From a security perspective, it can be important to know whether the bits being decrypted are data to be handed to a user or app, or keys to be kept within the key management subsystem. Hence there is a legitimate, security benefit that could be obtained IF people set the bits properly. I am hesitant to have us remove this potentially useful distinction merely because folks have not been smart enough to make good use of it so far. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEFP4w046194; Fri, 13 May 2005 07:15:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DEFPSN046193; Fri, 13 May 2005 07:15:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DEFMoZ046146 for ; Fri, 13 May 2005 07:15:22 -0700 (PDT) (envelope-from kent@bbn.com) Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4DEF52u004183; Fri, 13 May 2005 10:15:11 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <01bf01c557a0$ec060ad0$4f85900a@wcwang> References: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> <4284213C.8070000@strongauth.com> <01bf01c557a0$ec060ad0$4f85900a@wcwang> Date: Fri, 13 May 2005 10:15:07 -0400 To: "Wen-Cheng Wang" From: Stephen Kent Subject: Re: key usage - key encipherment or data encipherment Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:48 PM +0800 5/13/05, Wen-Cheng Wang wrote: >I also hesitate to accept the term "key transport", which will >result in over-narrowing down the usage scope of the >keyEncipherment bit. As Arshad pointed out, sometimes >the intention is not to transport the encrypted symmetric key >to anywhere. Besides, it is often that the handshake protocol >is not simply a "key transport" process; it is more often be >a more complex "key exchange" process. For example, >the SSL handshake protocol names it as "key exchange" >instead of "key transport". Would it be valid for a SSL server >cert to be asserted with that keyEncipherment bit? >To avoid the possible dispute on the definition of >similar terms, I would like to suggest to drop the term "key >transport" from the definition of the key usage bit. (However, >I think it is OK to use "key transport" as an example to >explain the the definition of the key usage bit. As commonly employed, a client uses an RSA public key associated with a server to encrypt and transport key bits that will later be used to create encryption and integrity keys for protecting the session. That is an example of key transport. If one used the Diffie-Hellman key agreement option for SSL, that would be accurately be described as a key exchange, but that is rarely the case, in practice. So I am puzzled by the characterization above. Steve Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DAqEeT091321; Fri, 13 May 2005 03:52:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DAqEZH091320; Fri, 13 May 2005 03:52:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DAqDVw091283 for ; Fri, 13 May 2005 03:52:13 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 11:52:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 11:52:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: key usage - key encipherment or data encipherment Thread-Index: AcVXYamK19IQ9UoOTv+YwThTUKtlWwARyOQg From: "Stefan Santesson" To: "Simon McMahon" , , , Cc: X-OriginalArrivalTime: 13 May 2005 10:52:07.0587 (UTC) FILETIME=[CE857730:01C557A9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4DAqEVw091314 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: How about calling the bits "The encryption bit" and "The other encryption bit" :-) Jokes aside, can anyone recall the justification for having 2 different bits for key and data encryption? Is there any realistic security threat involved with allowing both purposes for the same bit? Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Simon McMahon > Sent: den 13 maj 2005 03:19 > To: Denis.Pinkas@bull.net; sharon.boeyen@entrust.com; housley@vigilsec.com > Cc: ietf-pkix@vpnc.org > Subject: RE: key usage - key encipherment or data encipherment > > > Sorry but I think this new text is just more jargon and does not address > the problem. The problem is that there are 2 bits for encryption instead > of 1 so people can make a choice and need direction in that choice, but > will still get it wrong anyway, just because they can (Murphy). The > misunderstanding is that "keyEncipherment" is nearly always the correct > choice but sometimes people use "dataEncipherment" because the transport > keys are not explicit. > > Note that a new definition of a public key cipher RSA' that internally > used "RSA+AES" but didn't publish that fact could have RSA' public keys > (not RSA keys but internally identical to them) that directly encrypt > large amounts of data. The transport key just blends into the cipher text. > "dataEncipherment" is then the correct bit for the RSA' key but I'll bet > people who know its really RSA+AES will use "keyEncipherment" because that > is what is really happening. > > The bottom line is that this problem will never go away as long as you > have two bits whose meanings overlap like these ones do. The bits should > be merged because CA's that know about interoperability issues just set > both anyway. I would prefer a consolidation these flags and to deprecate > "dataEncipherment". That would leave "keyEncipherment" that could be > renamed to "encipherment". Then there is no confusion because there is no > choice anymore. > > Anyway, back to the text... > > Why did the "private" key creep into this description? "Private" keys are > also "secret". By the way, how does a public key encrypt a private key? It > is impossible, at least with RSA without a symmetric key in there, unless > the private key is a lot smaller. The latest proposed text example > specifies "content-decryption" now but symmetric keys exchanged this way > can also be for encryption too. Also, the symmetric key encrypted by the > public key was in fact an encryption key when the originator used it. > > Proposed rewording preserving both bits: > " > The keyEncipherment bit is asserted when the subject public key is used > for transport of a secret key or data encryption using an intermediate > secret key. For example, when a public key is to be used to encrypt a > secret cipher key that will encrypt some data or key, then this bit shall > asserted. > > The dataEncipherment bit is asserted when the subject public key is used > for directly enciphering user data other than cryptographic keys. > " > > Proposed rewording with only one bit: > " > The dataEncipherment bit is deprecated. If asserted then this bit now has > the same meaning as keyEncipherment. The keyEncipherment bit is renamed to > "encipherment" and is asserted when either of the previous bits were > asserted. Whenever a public key is used to encrypt data or keys then this > bit shall be asserted. > " > > Regards, > > Simon McMahon. > > > > Simon McMahon > > Work: (07) 31311420 > Mobile: (043) 2294180 > > > >>> Sharon Boeyen 05/13/05 05:44am >>> > I like the proposed text also. My only suggestion is could we add > "symmetric" in the sentence for dataEncipherment, so it would read "... > without the use of an intermediate symmetric key." I don't feel strongly > about this but do think it helps with the clarity. > > Cheers, > Sharon > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On > Behalf Of Russ Housley > Sent: Thursday, May 12, 2005 11:22 AM > To: Denis Pinkas > Cc: ietf-pkix@vpnc.org > Subject: Re: key usage - key encipherment or data encipherment > > > > Denis: > > Thanks. I think you suggestion improves the text. > > Russ > > At 10:44 AM 5/12/2005, Denis Pinkas wrote: > >Russ, > > > >>Since we are working on an update to RFC 3280, I propose the following > >>revisions to these descritions. > > > >> The keyEncipherment bit is asserted when the subject public key is > >> used for key transport. For example, when an RSA key is to be > >> used for key management by encrypting a symmetric content- > encryption > >> key, then this bit shall asserted. > >> The dataEncipherment bit is asserted when the subject public key > >> is used for directly enciphering raw user data without the use of > >> an intermediate symmetric cipher. > > > >Thank you for this strawman proposal. I would rather propose: > > > > The keyEncipherment bit is asserted when the subject public key is > > used for enciphering private or secret keys, i.e. for key > transport. > > For example, this bit shall be set when a public RSA key is to be > > used for encrypting a symmetric content-decryption key or an > > asymmetric private key. > > > > The dataEncipherment bit is asserted when the subject public key > > is used for directly enciphering raw user data without the use of > > an intermediate key. > > > >Reasons: > > > >a) "Key transport" is not explicit enough. The purpose is to encipher > >either a private key or a secret key. > > > >b) The example is not clear enough: "RSA key" can be a private key or a > >public key, hence why "public" has been added. > > > >c) The key that is communicated is a decryption key rather than an > >encryption key, hence why "content-encryption" has been changed into > >"content-decryption". > > > >d) The example has been extended to cover the case of an asymmetric > >cipher > >as well. > > > >e) In the last statement, the intermediate key would not necessarily be > >a > >symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" > >has been replaced by "key'. > > > >Note that the current text from X.509 is: > > > > c) keyEncipherment: for enciphering keys or other security > information, > > e.g. for key transport; > > > > d) dataEncipherment: for enciphering user data, but not keys or other > > security information as in c) above; > > > >Denis > > > ************************************************************************ ** > ********* > This email, including any attachments sent with it, is confidential and > for the sole use of the intended recipient(s). This confidentiality is > not waived or lost, if you receive it and you are not the intended > recipient(s), or if it is transmitted/received in error. > > Any unauthorised use, alteration, disclosure, distribution or review of > this email is prohibited. It may be subject to a statutory duty of > confidentiality if it relates to health service matters. > > If you are not the intended recipient(s), or if you have received this > email in error, you are asked to immediately notify the sender by > telephone or by return email. You should also delete this email and > destroy any hard copies produced. > ************************************************************************ ** > ********* > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DASulJ082324; Fri, 13 May 2005 03:28:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4DASu1e082323; Fri, 13 May 2005 03:28:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4DASsGk082278 for ; Fri, 13 May 2005 03:28:54 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 May 2005 11:28:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Structuring Denis issues RE: Comments on Date: Fri, 13 May 2005 11:28:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVXkGrXh4L68PMITiGhBZiWP1sEXwAE8o8A From: "Stefan Santesson" To: "Denis Pinkas" Cc: "pkix" X-OriginalArrivalTime: 13 May 2005 10:28:48.0933 (UTC) FILETIME=[8CDBCD50:01C557A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4DAStGk082314 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, Thanks for the clarification. Yes, we agree on issue number 1 (remove SHOULD and MUST) So the remaining issue is: Problem: The security considerations talk about "mitigation" of the name collision problem but gives inadequate advice. Your proposed resolution a) warn the user that the CRL where this extension was found may not be the right one. b) warn the user that the CRL issuer certificate he might obtain using this extension may not be the right one. c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed the one nominated by the CA that has issued the target certificate (i.e. when the CRL Issuer certification path and the target certificate certification path are identical). d) say that other possibilities exists, but need additional trust conditions (there are zillions of such possible trust conditions). To complete the picture it would now be very helpful if you, for each of these statements, could confirm or explain how these issues are a result of using the AIA extension in CRLs. Or in other words, which of these security considerations could you ignore (would go away) if you were NOT using the AIA extension in a CRL to locate the CRL Issuer certificate. Stefan Santesson Program Manager, Standards Liaison Windows Security Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D9mcs8067693; Fri, 13 May 2005 02:48:38 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D9mchC067691; Fri, 13 May 2005 02:48:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D9maMP067670 for ; Fri, 13 May 2005 02:48:36 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4D9mYAH024493 for ; Fri, 13 May 2005 17:48:34 +0800 Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4D9mXYu008220 for ; Fri, 13 May 2005 17:48:33 +0800 Message-ID: <01bf01c557a0$ec060ad0$4f85900a@wcwang> From: "Wen-Cheng Wang" To: References: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> <4284213C.8070000@strongauth.com> Subject: Re: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 17:48:30 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I also hesitate to accept the term "key transport", which will result in over-narrowing down the usage scope of the keyEncipherment bit. As Arshad pointed out, sometimes the intention is not to transport the encrypted symmetric key to anywhere. Besides, it is often that the handshake protocol is not simply a "key transport" process; it is more often be a more complex "key exchange" process. For example, the SSL handshake protocol names it as "key exchange" instead of "key transport". Would it be valid for a SSL server cert to be asserted with that keyEncipherment bit? To avoid the possible dispute on the definition of similar terms, I would like to suggest to drop the term "key transport" from the definition of the key usage bit. (However, I think it is OK to use "key transport" as an example to explain the the definition of the key usage bit. I also think it is strange to positively list "private keys" and "secret keys" as the only two possible types of keys that can be encrypted by the subject public key? What if someday another type of keys is invented and need to be encrypted by the subject public key? Why not simply use the term "cryptographic keys"? I believe the term "cryptographic keys" is general enough to cover any types of keys. My other concern is that the current definition of the key usage bit seems to only allow the subject public key be used for enciphering "keys". However, we must note that it is more often that modern handshake protocols actually use the subject public key for enciphering "keying materials" instead of the "real keys". For example, the pre-master-secret in the SSL hadnshake protocol is not yet a "real key"; it is actually be a "keying material" that can be used to derive "real shared secret keys" between the client and the server. Therefore, I suggest that we should take the possibility of enciphering "keying materials" instead of the "real keys" into account. Here I propose to revise the definitions of this two key usage bits as follows: The keyEncipherment bit is asserted when the subject public key is used for enciphering cryptographic keys or keying materials. For example, this bit shall be set when a RSA public key is to be used for key transport that involves encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data, other than cryptographic keys or keying materials, without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish shared cryptographic keys. Wen-Cheng Wang Arshad Noor wrote: > > I am afraid, this still does not provide sufficient clarity. > > Some questions that I cannot answer, based on reading the text > below (although I know the answers from practice) are: > > 1) Whose private key am I encrypting with the public key? Mine? > Hopefully not, because if this were the only copy of my private > key, what am I going to use to decrypt the cipher-text with? > While this may appear as a ridiculous notion, the point is that > the text does not clarify this question. > > 2) What if I'm not using the certificate for key transport? I may > have issued a certificate to a database that generates symmetric > keys to encrypt database content, and then stores the encrypted > symmetric key within the same database with the cipher-text. I'm > not transporting the symmetric key anywhere, so should I be using > the keyEncipherment bit or the dataEncirpherment bit? > > In my opinion, the confusion arises because the two bits perform > the same function: encipherment (as Simon McMahon pointed out in > an earlier posting), but for different purposes. > > There is a certain simplicity to having just one encipherment bit, > letting applications decide what they want to encrypt with the > certificate's public-key and letting them codify it in *their* > protocols - as S/MIME does - or through EKU's. > > Arshad Noor > StrongAuth, Inc. > > > Russ Housley wrote: >> >> There has been a whole lot of discussion about these paragraphs. Since >> some of the discussion has not been CCed to the PKIX mail list, I am >> posting the resulting words. >> >> The keyEncipherment bit is asserted when the subject public key is >> used for enciphering private or secret keys, i.e., for key transport. >> For example, this bit shall be set when a RSA public key is to be >> used for encrypting a symmetric content-decryption key or an >> asymmetric private key. >> >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate symmetric cipher. Note that the use of this >> bit is extremely uncommon; almost all applications use >> key transport or key agreement to establish a symmetric key. >> >> I hope we a re close to closure on this one.... >> >> Russ >> > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D9A1HF053570; Fri, 13 May 2005 02:10:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D9A11O053569; Fri, 13 May 2005 02:10:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp11.eresmas.com (smtp11.eresmas.com [62.81.235.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D9A0Ih053525 for ; Fri, 13 May 2005 02:10:00 -0700 (PDT) (envelope-from diegofv@eresmas.com) Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 1DWWB3-0003jJ-00; Fri, 13 May 2005 11:09:49 +0200 From: To: housley@vigilsec.com Cc: ietf-pkix@vpnc.org Message-ID: Date: Fri, 13 May 2005 09:09:50 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: es Subject: RE: Re: key usage - key encipherment or data encipherment X-Accept-Language: es Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: IMO password or PIN is also considered as a secret key, then which applications or protocols are demanding the dataEncipherment bit? Thanks Diego ----- Mensaje Original ----- Remitente: Russ Housley housley@vigilsec.com Destinatario: ietf-pkix@vpnc.org Fecha: Jueves, Mayo 12, 2005 9:21pm Asunto: Re: key usage - key encipherment or data encipherment > > The keyEncipherment bit is asserted when the subject public >key is > used for enciphering private or secret keys, i.e., for key >transport. For example, this bit shall be set when a RSA public >key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate symmetric cipher. Note that the use of this > bit is extremely uncommon; almost all applications use > key transport or key agreement to establish a symmetric key. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D8d2tg042716; Fri, 13 May 2005 01:39:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D8d2mh042714; Fri, 13 May 2005 01:39:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D8d0IB042693 for ; Fri, 13 May 2005 01:39:01 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from [10.0.0.81] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft5.fr.colt.net with ESMTP id j4D8cx523356 for ; Fri, 13 May 2005 10:38:59 +0200 Message-ID: <428467A3.6030109@free.fr> Date: Fri, 13 May 2005 10:38:59 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050512 MIME-Version: 1.0 To: ietf-pkix@imc.org Subject: Re: Comments on References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> <42832153.8000802@bull.net> <6.2.1.2.2.20050512104257.0608b450@mail.binhost.com> <42845DF4.8020405@bull.net> In-Reply-To: <42845DF4.8020405@bull.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis Pinkas wrote: > > When policies, procedures, and practices are followed, I do not believe > > that two different CRL issuers that are subordinate to the same trust > > anchor can legitimately have the same name. > > You have certainly heard of the name "Eurostar". That name was originally > used by a French truck company, and the French-British railways anyway > made accidentally a name collision with it. Isn't the source of this problem the fact that as long as nothing cryptographically binds to it, it's very hard to be completely sure we got the right certificate ? So why not solve that and expand the way we link to the CRL issuer to allow the use a ESSCertID ? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7wY6e028320; Fri, 13 May 2005 00:58:34 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D7wYTp028319; Fri, 13 May 2005 00:58:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7wVaZ028276 for ; Fri, 13 May 2005 00:58:32 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA60702; Fri, 13 May 2005 10:13:21 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051309582197:1318 ; Fri, 13 May 2005 09:58:21 +0200 Message-ID: <42845E58.6010502@bull.net> Date: Fri, 13 May 2005 09:59:20 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org Subject: Re: Comments on References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> <42832509.5020001@bull.net> <6.2.1.2.2.20050512105428.060f0210@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:58:22, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:58:24, Serialize complete at 13/05/2005 09:58:24 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, > Denis: >> >>> You say that it is not clear what validation policy needs to be used, >> >>> but this is completely irrelevant to the discussion of the CRL AIA >> >>> extension. This extension aid in certification path construction, >> >>> not the validation of the path once it is constructed. >> >> Not exactly, it could "help" finding a wrong path ! >> > Not likely. The signer of the CRL is providing a pointer to their own >> > certificate. Path construction to locate a parent of that certificate >> > through a complex PKI might include paths that are acceptable and paths >> > that are unacceptable, but the certificate that contains the public key >> > needed to validate the signature on the CRL is clearly needed. >> The problem is to know if a CRL that has been fetched "somewhere" is >> adequate for the target certificate. It is not to validate a CRL that >> has been fetched "somewhere". > You continue to miss the whole point of this document. I do not think so. > The certificate user has already obtained the CRL, but needs the ^^^^ it is not "the" CRL since it is only "a" CRL. If you got a network attack when fetching the CRL from the CRL DP you may get something wrong. So at this time you still do not know what is *the* right CRL. > certificate of the CRL issuer in order to validate the signature on the > CRL. That is the scope of this document. Not exacly. You are not sure to get "the" CA certificate of the CRL issuer, but only "a" certificate that bears the appropriate DN in the subject DN. but collisions in subject DNs may happen accidently or deliberately. > You keep trying to make it something else. The distinction between "the" and "a" is pretty important. Denis > Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7up02027721; Fri, 13 May 2005 00:56:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D7updX027720; Fri, 13 May 2005 00:56:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7uonU027676 for ; Fri, 13 May 2005 00:56:50 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA28398; Fri, 13 May 2005 10:11:40 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051309564137:1317 ; Fri, 13 May 2005 09:56:41 +0200 Message-ID: <42845DF4.8020405@bull.net> Date: Fri, 13 May 2005 09:57:40 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: pkix Subject: Re: Comments on References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> <42832153.8000802@bull.net> <6.2.1.2.2.20050512104257.0608b450@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:56:41, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:56:43, Serialize complete at 13/05/2005 09:56:43 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, > Denis: > > Finally! We now uncover the actual point of disagreement. I would hope, but I am still unsure. > You say: >> The same trust anchor is not a *sufficient* condition. The same node >> in the certification tree is the necessary condition. This implies, of >> course, the same trust anchor, but since two CRL issuers located at >> different nodes (i.e. certified by different CAS) might have the >> same CRL issuer name, this condition is insufficient to solve the >> issue. > When policies, procedures, and practices are followed, I do not believe > that two different CRL issuers that are subordinate to the same trust > anchor can legitimately have the same name. You have certainly heard of the name "Eurostar". That name was originally used by a French truck company, and the French-British railways anyway made accidentally a name collision with it. We can hope that this does not happen again, but we cannot make sure it already happened. We need to build a secure PKI, not a "nearly secure" PKI and there ARE solutions to make it fully secure. I also know there are current solutions which are NOT fully secure. The goal of our group is to say how to make it secure. > As I said yesterday, I am > willing to add text to the Security Considerations section to state > this. As mentioned above, this is untrue in general. > I am even willing to state that certificate users should not > include trust anchors that do not have policies, procedures, and > practices that would prevent such name collisions. This is impossible to state since the certification tree may be growing and thus you cannot make sure that you have explored all the tree. See my detailed response to Stefan from a few minutes ago on what needs to be covered in the security considerations section. Denis > Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7qqhq026306; Fri, 13 May 2005 00:52:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D7qqiA026305; Fri, 13 May 2005 00:52:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7qoIS026258 for ; Fri, 13 May 2005 00:52:51 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA45772; Fri, 13 May 2005 10:07:38 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051309523802:1314 ; Fri, 13 May 2005 09:52:38 +0200 Message-ID: <42845D00.6050909@bull.net> Date: Fri, 13 May 2005 09:53:36 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:52:38, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:52:40, Serialize complete at 13/05/2005 09:52:40 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, > Denis, > > My main comment to this is that there is no exact definition of what is > "sufficient" in this case. > > What is sufficient to you may not be sufficient to me or vice versa. > This issue is as many times when security is the issue a tradeoff. In IT > security you always have the 3 goals: > > - Cheep > - Easy to use > - Secure No. There is not such a trade-off in security. Either it is secure or not. > The sad truth is that we often discover that we can have any 2 of those > but never all 3. I do know some implementations that have this problem, and I won't nominate any. I will simply quote some recent good words from Peter Gutmann: " 1. Vendor does something silly. 2. Vendor uses ambiguous wording of spec to justify their silliness because they don't want to fix their code. 3. User has the option of breaking their code to match the vendor silliness, or going somewhere else (learning to flip burgers, for example)". I do not want cases 1 and 2 to happen, and this is exactly what is going to happen in the present case. Denis > The fact about name uniqueness you provide in the referenced text is a > true facts but it still does not tell me what is sufficient or not in my > environment or how I can achieve reasonable security when the trust > paths differ (in case they have to). > > My basic assessment is that there is neither a single truth nor a single > solution to the problem. The chaining to a common root was the > reasonable recommendation agreed at the San Diego PKIX meeting. This is > in my mind not intended to be advertised as a "sufficient" solution, > just good practice to reduce the risk of problems. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 12 maj 2005 11:27 >>To: Russ Housley >>Cc: pkix >>Subject: Re: Comments on >> >> >>Russ, >> >>Since Tim has now made the call at the WG level, please consider this >>message as an answer to the call: the current security considerations >>section is not acceptable. >> >> > The document already says that the CA and the CRL issuer need to >> > terminate at the same trust anchor. This is the important point. >> > I disagree that there is anything else that ought to be said in > > the > >> > security considerations. >> >>This statement still does not answer to the point I raised, but >>I will nevertheless answer to your statement. >> >>The same trust anchor is not a *sufficient* condition. The same node > > in > >>the >>certification tree is the necessary condition. This implies, of > > course, > >>the >>same trust anchor, but since two CRL issuers located at different > > nodes > >>(i.e. certified by different CAS) might have the same CRL issuer name, >>this >>condition is insufficient to solve the issue. >> >>May I recall an extract from the security considerations section of an >>approved draft that will be published soon as RFC 4043 ? (this is the >>permanent-identifier document): >> >> Subject names in certificates are chosen by the issuing CA and > > are > >> mandated to be unique for each CA; so there can be no name > > collision > >> between subject names from the same CA. Such a name may be an > > end- > >> entity name when the certificate is a leaf certificate, or a CA >>name, >> when it is a CA certificate. >> >> Since a name is only unique towards its superior CA, unless some >> naming constraints are being used, a name would only be > > guaranteed > >>to >> be globally unique when considered to include a sequence of all > > the > >> names of the superior CAs. (...) >> >> Additional checks need to be done, e.g., to check if the public > > key > >> values of the two CAs which have issued the certificates to be >> compared are identical or if the sequence of CA names in the >> certification path from the trust anchor to the CA are > > identical. > >> (...) >> >> The certification of different CAs with the same DN by different > > CAs > >> has other negative consequences in various parts of the PKI, > > notably > >> rendering the IssuerAndSerialNumber structure in [RFC3852] > > section > >> 10.2.4 ambiguous. >> >>It speaks for itself, as it applies to CRL Issuers as well. Some parts > > of > >>it should indeed be copied and pasted in the security considerations >>section >>of the current proposed draft. >> >>When the certification path used to validate the target certificate is >>also used to validate the CRL Issuer certificate, then there is no >>security >>issue: this should be said in the security considerations section. >> >>What about the other cases ? The other cases belong to the category of >>indirect CRLs. Depending on the local validation policy checks done or > > not > >>done there may be security issues. >> >>Denis >> >> > Russ >> > >> > At 02:59 AM 5/10/2005, Denis Pinkas wrote: >> > >> >> Russ, >> >> >> >> Your statement below is correct, but does not answer to any of my >> >> questions/issues. In particular, the last one. I am still > > awaiting > >> >> your responses. >> >> >> >> Denis >> >> >> >>> Denis: >> >>> RFC 3280 does not tell an implementor how for locate > > certificates > >>for >> >>> any certification path construction. There are several > > extensions > >> >>> that provide pointers that may help an implementation, but other >> >>> approaches to obtaining the same certificates are always > > permitted. > >> >>> I would fully expect an implementation to check any local cache >> >>> before accessing a repository. >> >>> The CRL AIA extension fits this pattern. A method for locating > > a > >> >>> certificate is provided, but any other mechanism for locating > > the > >> >>> same certificate is acceptable. >> >>> Russ >> >>> >> >>>> Stefan, >> >>>> >> >>>> I made the e-mail shorter. Your main arguments are the > > following: > >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> [Stefan] But it has to provide a warning to something that is >> >>>> introduced >> >>>> by the standard. This standard does not introduce the concept > > of > >>CRL >> >>>> signature checking or CRL issuer certificate validation, so > > that is > >> >>>> clearly out of scope. More about that below; >> >>>> >> >>>> [Denis] See below the last answer and also my arguments in the >> >>>> soon-to-be-posted answer to Russ. >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> >> >>>> > > RFC 3280 [PKIX1] specifies the validation of certification >>paths. >> >>>> > > One aspect involves the determination that a certificate > > has > >>not >> >>>> been >> >>>> > > revoked, and one revocation checking mechanism is the >>Certificate >> >>>> > > Revocation List (CRL). CRL validation is also specified in > > RFC > >> >>>> 3280, >> >>>> >> >>>> > I would love this last sentence to be true but the reality is >>that: >> >>>> > "CRL validation is NOT specified in RFC 3280". :-( >> >>>> >> >>>> [Stefan] In fact it is. >> >>>> >> >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: >> >>>> >> >>>> (f) Obtain and validate the certification path for the > > complete > >>CRL >> >>>> issuer. If a key usage extension is present in the CRL > > issuer's > >> >>>> certificate, verify that the cRLSign bit is set. >> >>>> >> >>>> (g) Validate the signature on the complete CRL using the > > public > >>key >> >>>> validated in step (f). >> >>>> >> >>>> [Denis] The text does not say how to obtain and validate the >> >>>> certification path for the complete (???) CRL issuer. The text > > is > >> >>>> not clear enough so that two implementors only looking at this >> >>>> sentence will provide interoperable implementations. >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> [Stefan] It is my hope that the provided responses here can > > help > >> >>>> convince you to change your mind about that. If it doesn't I > > still > >> >>>> argue >> >>>> that the place to specify requirements and security > > considerations > >>for >> >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL >>draft. >> >>>> >> >>>> [Denis] I can agree with your last sentence, ... which means > > that > >>it >> >>>> should not be in the main body of the document. In the security >> >>>> considerations section, text is free and we shall at the very >> >>>> minimum warn implementers and we should provide some guidance. > > When > >> >>>> the same certification path (i.e. the path used to validate the >> >>>> target certificate) is used, then there is no security issue: > > this > >> >>>> should be said. For all other cases, there MAY be problems: > > this > >> >>>> should also be said. It is as simple as that. >> >>>> >> >>>> Denis >> >>> >> >> >> >> >> > >> > >> >> >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7oV4W025475; Fri, 13 May 2005 00:50:31 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D7oV5u025474; Fri, 13 May 2005 00:50:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D7oD8e025334 for ; Fri, 13 May 2005 00:50:30 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA60650; Fri, 13 May 2005 10:05:03 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051309500478:1313 ; Fri, 13 May 2005 09:50:04 +0200 Message-ID: <42845C67.4020501@bull.net> Date: Fri, 13 May 2005 09:51:03 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: Structuring Denis issues RE: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:50:04, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 13/05/2005 09:50:05, Serialize complete at 13/05/2005 09:50:05 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, > Denis, > > The core of your comments are spread over many emails and opinions may > have changed on details so I'm not sure I have got the latest picture of > your recorded problems and what you propose as resolution. > > I'm thus trying to summarize the current complete picture of the last > call comments below. Please correct me if something is wrong or missing. > Note that I'm not arguing here, just trying to structure the issues (I > will argue in separate mails). Also note that agreed typos are omitted > from the list: > 1) > Problem: There are SHOULD and MUST requirements in the security > considerations section. > Proposed resolution: Reword to make sure we don't use SHOULD or MUST in > this section. I believe they we all agree on this. > ----- > 2) > Problem: The security considerations talk about "mitigation" of the name > collision problem but gives inadequate advice. > Proposed resolution: Either delete all text talking about how to > mitigate this problem or provide full guidance on what it takes to > guarantee that a CRL Issuer with a matching name actually is the > intended CRL Issuer. Also explain that this is not an issue when the CRL > Issuer certification path and the target certificate certification path > are identical. Not exactly. I would say : a) warn the user that the CRL where this extension was found may not be the right one. b) warn the user that the CRL issuer certificate he might obtain using this extension may not be the right one. c) provide guidance on how to GUARANTEE that the CRL Issuer is indeed the one nominated by the CA that has issued the target certificate (i.e. when the CRL Issuer certification path and the target certificate certification path are identical). d) say that other possibilities exists, but need additional trust conditions (there are zillions of such possible trust conditions). Denis > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > >>-----Original Message----- >>From: owner-ietf-pkix@mail.imc.org > > [mailto:owner-ietf-pkix@mail.imc.org] > >>On Behalf Of Denis Pinkas >>Sent: den 12 maj 2005 11:27 >>To: Russ Housley >>Cc: pkix >>Subject: Re: Comments on >> >> >>Russ, >> >>Since Tim has now made the call at the WG level, please consider this >>message as an answer to the call: the current security considerations >>section is not acceptable. >> >> > The document already says that the CA and the CRL issuer need to >> > terminate at the same trust anchor. This is the important point. >> > I disagree that there is anything else that ought to be said in > > the > >> > security considerations. >> >>This statement still does not answer to the point I raised, but >>I will nevertheless answer to your statement. >> >>The same trust anchor is not a *sufficient* condition. The same node > > in > >>the >>certification tree is the necessary condition. This implies, of > > course, > >>the >>same trust anchor, but since two CRL issuers located at different > > nodes > >>(i.e. certified by different CAS) might have the same CRL issuer name, >>this >>condition is insufficient to solve the issue. >> >>May I recall an extract from the security considerations section of an >>approved draft that will be published soon as RFC 4043 ? (this is the >>permanent-identifier document): >> >> Subject names in certificates are chosen by the issuing CA and > > are > >> mandated to be unique for each CA; so there can be no name > > collision > >> between subject names from the same CA. Such a name may be an > > end- > >> entity name when the certificate is a leaf certificate, or a CA >>name, >> when it is a CA certificate. >> >> Since a name is only unique towards its superior CA, unless some >> naming constraints are being used, a name would only be > > guaranteed > >>to >> be globally unique when considered to include a sequence of all > > the > >> names of the superior CAs. (...) >> >> Additional checks need to be done, e.g., to check if the public > > key > >> values of the two CAs which have issued the certificates to be >> compared are identical or if the sequence of CA names in the >> certification path from the trust anchor to the CA are > > identical. > >> (...) >> >> The certification of different CAs with the same DN by different > > CAs > >> has other negative consequences in various parts of the PKI, > > notably > >> rendering the IssuerAndSerialNumber structure in [RFC3852] > > section > >> 10.2.4 ambiguous. >> >>It speaks for itself, as it applies to CRL Issuers as well. Some parts > > of > >>it should indeed be copied and pasted in the security considerations >>section >>of the current proposed draft. >> >>When the certification path used to validate the target certificate is >>also used to validate the CRL Issuer certificate, then there is no >>security >>issue: this should be said in the security considerations section. >> >>What about the other cases ? The other cases belong to the category of >>indirect CRLs. Depending on the local validation policy checks done or > > not > >>done there may be security issues. >> >>Denis >> >> > Russ >> > >> > At 02:59 AM 5/10/2005, Denis Pinkas wrote: >> > >> >> Russ, >> >> >> >> Your statement below is correct, but does not answer to any of my >> >> questions/issues. In particular, the last one. I am still > > awaiting > >> >> your responses. >> >> >> >> Denis >> >> >> >>> Denis: >> >>> RFC 3280 does not tell an implementor how for locate > > certificates > >>for >> >>> any certification path construction. There are several > > extensions > >> >>> that provide pointers that may help an implementation, but other >> >>> approaches to obtaining the same certificates are always > > permitted. > >> >>> I would fully expect an implementation to check any local cache >> >>> before accessing a repository. >> >>> The CRL AIA extension fits this pattern. A method for locating > > a > >> >>> certificate is provided, but any other mechanism for locating > > the > >> >>> same certificate is acceptable. >> >>> Russ >> >>> >> >>>> Stefan, >> >>>> >> >>>> I made the e-mail shorter. Your main arguments are the > > following: > >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> [Stefan] But it has to provide a warning to something that is >> >>>> introduced >> >>>> by the standard. This standard does not introduce the concept > > of > >>CRL >> >>>> signature checking or CRL issuer certificate validation, so > > that is > >> >>>> clearly out of scope. More about that below; >> >>>> >> >>>> [Denis] See below the last answer and also my arguments in the >> >>>> soon-to-be-posted answer to Russ. >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> >> >>>> > > RFC 3280 [PKIX1] specifies the validation of certification >>paths. >> >>>> > > One aspect involves the determination that a certificate > > has > >>not >> >>>> been >> >>>> > > revoked, and one revocation checking mechanism is the >>Certificate >> >>>> > > Revocation List (CRL). CRL validation is also specified in > > RFC > >> >>>> 3280, >> >>>> >> >>>> > I would love this last sentence to be true but the reality is >>that: >> >>>> > "CRL validation is NOT specified in RFC 3280". :-( >> >>>> >> >>>> [Stefan] In fact it is. >> >>>> >> >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: >> >>>> >> >>>> (f) Obtain and validate the certification path for the > > complete > >>CRL >> >>>> issuer. If a key usage extension is present in the CRL > > issuer's > >> >>>> certificate, verify that the cRLSign bit is set. >> >>>> >> >>>> (g) Validate the signature on the complete CRL using the > > public > >>key >> >>>> validated in step (f). >> >>>> >> >>>> [Denis] The text does not say how to obtain and validate the >> >>>> certification path for the complete (???) CRL issuer. The text > > is > >> >>>> not clear enough so that two implementors only looking at this >> >>>> sentence will provide interoperable implementations. >> >>>> >> >>>> >> > ======================================================================== > == > >> >>>> >> >>>> >> >>>> [Stefan] It is my hope that the provided responses here can > > help > >> >>>> convince you to change your mind about that. If it doesn't I > > still > >> >>>> argue >> >>>> that the place to specify requirements and security > > considerations > >>for >> >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL >>draft. >> >>>> >> >>>> [Denis] I can agree with your last sentence, ... which means > > that > >>it >> >>>> should not be in the main body of the document. In the security >> >>>> considerations section, text is free and we shall at the very >> >>>> minimum warn implementers and we should provide some guidance. > > When > >> >>>> the same certification path (i.e. the path used to validate the >> >>>> target certificate) is used, then there is no security issue: > > this > >> >>>> should be said. For all other cases, there MAY be problems: > > this > >> >>>> should also be said. It is as simple as that. >> >>>> >> >>>> Denis >> >>> >> >> >> >> >> > >> > >> >> >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D6hAjG099345; Thu, 12 May 2005 23:43:10 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D6hAd6099344; Thu, 12 May 2005 23:43:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from siamail.sia.it (mail.sia.it [193.203.230.133] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D6h85H099290 for ; Thu, 12 May 2005 23:43:09 -0700 (PDT) (envelope-from adriano.santoni@actalis.it) Received: from ntexch06.office.corp.sia.it ([10.2.101.30]) by siamail.sia.it (8.12.11/8.12.11) with SMTP id j4D6gt0c006752; Fri, 13 May 2005 08:42:55 +0200 (METDST) Received: from NTEXCH00.office.corp.sia.it ([10.2.101.129]) by ntexch06.office.corp.sia.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 13 May 2005 08:42:54 +0200 Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: R: key usage - key encipherment or data encipherment Date: Fri, 13 May 2005 08:42:54 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: key usage - key encipherment or data encipherment thread-index: AcVXKMKrk6a7r8bvTYiBPx796SM65gAXUjKQ From: "Santoni Adriano" To: "Russ Housley" Cc: X-OriginalArrivalTime: 13 May 2005 06:42:54.0834 (UTC) FILETIME=[FDFC6D20:01C55786] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4D6h95H099337 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd suggest to modify the first part like follows (or equivalently): The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key (e.g. as it occurs in the TLS protocol with the server's public key). This would add another bit of clarity to the prescription. My 2 cents (of Euro :-) Adriano -----Messaggio originale----- Da: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] Per conto di Russ Housley Inviato: giovedì 12 maggio 2005 21.21 A: ietf-pkix@vpnc.org Oggetto: Re: key usage - key encipherment or data encipherment There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ *******************Internet Email Confidentiality Footer******************* Qualsiasi utilizzo non autorizzato del presente messaggio nonché dei suoi allegati è vietato e potrebbe costituire reato. Se ha ricevuto per errore il presente messaggio, Le saremmo grati se ci inviasse, via e-mail, una comunicazione al riguardo e provvedesse nel contempo alla distruzione del messaggio stesso e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente messaggio nonche' nei suoi eventuali allegati devono essere attribuite esclusivamente al mittente e non possono essere considerate come trasmesse o autorizzate da ACTALIS S.p.A.; le medesime dichiarazioni non impegnano ACTALIS S.p.A. nei confronti del destinatario o di terzi. ACTALIS S.p.A. non si assume alcuna responsabilita' per eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. Any unauthorized use of this e-mail or any of its attachments is prohibited and could constitute an offence. If you are not the intended addressee please advise immediately the sender by using the reply facility in your e-mail software and destroy the message and its attachments. The statements and opinions expressed in this e-mail message are those of the author of the message and do not necessarily represent those of ACTALIS S.p.A. Besides, The contents of this message shall be understood as neither given nor endorsed by ACTALIS S.p.A.. ACTALIS S.p.A. does not accept liability for corruption, interception or amendment, if any, or the consequences thereof. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D3cnq8045961; Thu, 12 May 2005 20:38:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D3cn7M045959; Thu, 12 May 2005 20:38:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from igw (adsl-63-194-79-229.dsl.snfc21.pacbell.net [63.194.79.229]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D3cnpa045938 for ; Thu, 12 May 2005 20:38:49 -0700 (PDT) (envelope-from arshad.noor@strongauth.com) Received: from [192.168.0.7] (hera.noorhome.net [192.168.0.7]) by igw.noorhome.net (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPS id <0IGE0084JRJ1UC@igw.noorhome.net> for ietf-pkix@vpnc.org; Thu, 12 May 2005 20:11:25 -0700 (PDT) Date: Thu, 12 May 2005 20:38:36 -0700 From: Arshad Noor Subject: Re: key usage - key encipherment or data encipherment In-reply-to: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> To: ietf-pkix@vpnc.org Message-id: <4284213C.8070000@strongauth.com> Organization: StrongAuth, Inc. MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) References: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am afraid, this still does not provide sufficient clarity. Some questions that I cannot answer, based on reading the text below (although I know the answers from practice) are: 1) Whose private key am I encrypting with the public key? Mine? Hopefully not, because if this were the only copy of my private key, what am I going to use to decrypt the cipher-text with? While this may appear as a ridiculous notion, the point is that the text does not clarify this question. 2) What if I'm not using the certificate for key transport? I may have issued a certificate to a database that generates symmetric keys to encrypt database content, and then stores the encrypted symmetric key within the same database with the cipher-text. I'm not transporting the symmetric key anywhere, so should I be using the keyEncipherment bit or the dataEncirpherment bit? In my opinion, the confusion arises because the two bits perform the same function: encipherment (as Simon McMahon pointed out in an earlier posting), but for different purposes. There is a certain simplicity to having just one encipherment bit, letting applications decide what they want to encrypt with the certificate's public-key and letting them codify it in *their* protocols - as S/MIME does - or through EKU's. Arshad Noor StrongAuth, Inc. Russ Housley wrote: > > There has been a whole lot of discussion about these paragraphs. Since > some of the discussion has not been CCed to the PKIX mail list, I am > posting the resulting words. > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e., for key transport. > For example, this bit shall be set when a RSA public key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate symmetric cipher. Note that the use of this > bit is extremely uncommon; almost all applications use > key transport or key agreement to establish a symmetric key. > > I hope we a re close to closure on this one.... > > Russ > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D3QvTC044593; Thu, 12 May 2005 20:26:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D3Qvfh044592; Thu, 12 May 2005 20:26:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D3QuP5044585 for ; Thu, 12 May 2005 20:26:57 -0700 (PDT) (envelope-from eldub@pobox.com) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 1C6E67A2; Thu, 12 May 2005 23:26:52 -0400 (EDT) Received: from distopia (c-24-22-214-246.hsd1.wa.comcast.net [24.22.214.246]) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id 6F08A8B; Thu, 12 May 2005 23:26:50 -0400 (EDT) From: "Laudon Williams" To: "'Russ Housley'" , Subject: RE: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 20:26:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVXMU5iLY8+5IXuQai+x1jw20eNrwAOY50g In-Reply-To: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20050513032650.6F08A8B@orb.sasl.smtp.pobox.com> Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simply an observation, not a disagreement. Unfortunately, the keyEncipherment bit has grown to be used for both key encipherment and data encipherment. I see this a lot, especially with field-level encryption in databases, and encryption of small data files. I guess what I'm getting at is that I never see certificates with the dataEncipherment bit set in it in actual use, but I come across lots of places when data is encrypted with the private key. With that said, I like the text below. -Laudon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 12:21 PM To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D1KsbQ033550; Thu, 12 May 2005 18:20:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4D1KsgH033549; Thu, 12 May 2005 18:20:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4D1Kqg8033542 for ; Thu, 12 May 2005 18:20:52 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Fri, 13 May 2005 11:19:36 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Fri, 13 May 2005 11:19:36 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Fri, 13 May 2005 11:19:20 +1000 From: "Simon McMahon" To: , , Cc: Subject: RE: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4D1Krg8033544 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry but I think this new text is just more jargon and does not address the problem. The problem is that there are 2 bits for encryption instead of 1 so people can make a choice and need direction in that choice, but will still get it wrong anyway, just because they can (Murphy). The misunderstanding is that "keyEncipherment" is nearly always the correct choice but sometimes people use "dataEncipherment" because the transport keys are not explicit. Note that a new definition of a public key cipher RSA' that internally used "RSA+AES" but didn't publish that fact could have RSA' public keys (not RSA keys but internally identical to them) that directly encrypt large amounts of data. The transport key just blends into the cipher text. "dataEncipherment" is then the correct bit for the RSA' key but I'll bet people who know its really RSA+AES will use "keyEncipherment" because that is what is really happening. The bottom line is that this problem will never go away as long as you have two bits whose meanings overlap like these ones do. The bits should be merged because CA's that know about interoperability issues just set both anyway. I would prefer a consolidation these flags and to deprecate "dataEncipherment". That would leave "keyEncipherment" that could be renamed to "encipherment". Then there is no confusion because there is no choice anymore. Anyway, back to the text... Why did the "private" key creep into this description? "Private" keys are also "secret". By the way, how does a public key encrypt a private key? It is impossible, at least with RSA without a symmetric key in there, unless the private key is a lot smaller. The latest proposed text example specifies "content-decryption" now but symmetric keys exchanged this way can also be for encryption too. Also, the symmetric key encrypted by the public key was in fact an encryption key when the originator used it. Proposed rewording preserving both bits: " The keyEncipherment bit is asserted when the subject public key is used for transport of a secret key or data encryption using an intermediate secret key. For example, when a public key is to be used to encrypt a secret cipher key that will encrypt some data or key, then this bit shall asserted. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering user data other than cryptographic keys. " Proposed rewording with only one bit: " The dataEncipherment bit is deprecated. If asserted then this bit now has the same meaning as keyEncipherment. The keyEncipherment bit is renamed to "encipherment" and is asserted when either of the previous bits were asserted. Whenever a public key is used to encrypt data or keys then this bit shall be asserted. " Regards, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Sharon Boeyen 05/13/05 05:44am >>> I like the proposed text also. My only suggestion is could we add "symmetric" in the sentence for dataEncipherment, so it would read "... without the use of an intermediate symmetric key." I don't feel strongly about this but do think it helps with the clarity. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 11:22 AM To: Denis Pinkas Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Denis: Thanks. I think you suggestion improves the text. Russ At 10:44 AM 5/12/2005, Denis Pinkas wrote: >Russ, > >>Since we are working on an update to RFC 3280, I propose the following >>revisions to these descritions. > >> The keyEncipherment bit is asserted when the subject public key is >> used for key transport. For example, when an RSA key is to be >> used for key management by encrypting a symmetric content-encryption >> key, then this bit shall asserted. >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate symmetric cipher. > >Thank you for this strawman proposal. I would rather propose: > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e. for key transport. > For example, this bit shall be set when a public RSA key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate key. > >Reasons: > >a) "Key transport" is not explicit enough. The purpose is to encipher >either a private key or a secret key. > >b) The example is not clear enough: "RSA key" can be a private key or a >public key, hence why "public" has been added. > >c) The key that is communicated is a decryption key rather than an >encryption key, hence why "content-encryption" has been changed into >"content-decryption". > >d) The example has been extended to cover the case of an asymmetric >cipher >as well. > >e) In the last statement, the intermediate key would not necessarily be >a >symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" >has been replaced by "key'. > >Note that the current text from X.509 is: > > c) keyEncipherment: for enciphering keys or other security information, > e.g. for key transport; > > d) dataEncipherment: for enciphering user data, but not keys or other > security information as in c) above; > >Denis *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJj8uD011958; Thu, 12 May 2005 12:45:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CJj8ac011957; Thu, 12 May 2005 12:45:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from sottmxsecs3.entrust.com (sottmxsecs3.entrust.com [216.191.252.14]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CJj70H011929 for ; Thu, 12 May 2005 12:45:07 -0700 (PDT) (envelope-from sharon.boeyen@entrust.com) Received: (qmail 18939 invoked from network); 12 May 2005 19:41:14 -0000 Received: from sharon.boeyen@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.3.0;12 May 2005 19:41:14 -0000 Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 12 May 2005 19:41:14 -0000 Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id ; Thu, 12 May 2005 15:45:01 -0400 Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F03A03339@sottmxs05.entrust.com> From: Sharon Boeyen To: "'Russ Housley'" , Denis Pinkas Cc: ietf-pkix@vpnc.org Subject: RE: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 15:44:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5572A.CD40DDF9" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5572A.CD40DDF9 Content-Type: text/plain I like the proposed text also. My only suggestion is could we add "symmetric" in the sentence for dataEncipherment, so it would read "... without the use of an intermediate symmetric key." I don't feel strongly about this but do think it helps with the clarity. Cheers, Sharon -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Russ Housley Sent: Thursday, May 12, 2005 11:22 AM To: Denis Pinkas Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Denis: Thanks. I think you suggestion improves the text. Russ At 10:44 AM 5/12/2005, Denis Pinkas wrote: >Russ, > >>Since we are working on an update to RFC 3280, I propose the following >>revisions to these descritions. > >> The keyEncipherment bit is asserted when the subject public key is >> used for key transport. For example, when an RSA key is to be >> used for key management by encrypting a symmetric content-encryption >> key, then this bit shall asserted. >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate symmetric cipher. > >Thank you for this strawman proposal. I would rather propose: > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e. for key transport. > For example, this bit shall be set when a public RSA key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate key. > >Reasons: > >a) "Key transport" is not explicit enough. The purpose is to encipher >either a private key or a secret key. > >b) The example is not clear enough: "RSA key" can be a private key or a >public key, hence why "public" has been added. > >c) The key that is communicated is a decryption key rather than an >encryption key, hence why "content-encryption" has been changed into >"content-decryption". > >d) The example has been extended to cover the case of an asymmetric >cipher >as well. > >e) In the last statement, the intermediate key would not necessarily be >a >symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" >has been replaced by "key'. > >Note that the current text from X.509 is: > > c) keyEncipherment: for enciphering keys or other security information, > e.g. for key transport; > > d) dataEncipherment: for enciphering user data, but not keys or other > security information as in c) above; > >Denis ------_=_NextPart_001_01C5572A.CD40DDF9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: key usage - key encipherment or data encipherment

I like the proposed text also. My only suggestion is = could we add "symmetric" in the sentence for = dataEncipherment, so it would read "... without the use of an = intermediate symmetric key." I don't feel strongly about this but = do think it helps with the clarity.

Cheers,
Sharon

-----Original Message-----
From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail= .imc.org] On Behalf Of Russ Housley
Sent: Thursday, May 12, 2005 11:22 AM
To: Denis Pinkas
Cc: ietf-pkix@vpnc.org
Subject: Re: key usage - key encipherment or data = encipherment



Denis:

Thanks.  I think you suggestion improves the = text.

Russ

At 10:44 AM 5/12/2005, Denis Pinkas wrote:
>Russ,
>
>>Since we are working on an update to RFC = 3280, I propose the following
>>revisions to these descritions.
>
>>      The = keyEncipherment bit is asserted when the subject public key is
>>      used for key = transport.  For example, when an RSA key is to be
>>      used for key = management by encrypting a symmetric content-encryption
>>      key, then = this bit shall asserted.
>>      The = dataEncipherment bit is asserted when the subject public key
>>      is used for = directly enciphering raw user data without the use of
>>      an = intermediate symmetric cipher.
>
>Thank you for this strawman proposal. I would = rather propose:
>
>       The = keyEncipherment bit is asserted when the subject public key is
>       used for = enciphering private or secret keys, i.e. for key transport.
>       For = example, this bit shall be set when a public RSA key is to be
>       used for = encrypting a symmetric content-decryption key or an
>       asymmetric = private key.
>
>       The = dataEncipherment bit is asserted when the subject public key
>       is used for = directly enciphering raw user data without the use of
>       an = intermediate key.
>
>Reasons:
>
>a) "Key transport" is not explicit = enough. The purpose is to encipher
>either a private key or a secret key.
>
>b) The example is not clear enough: "RSA = key" can be a private key or a
>public key, hence why "public" has = been added.
>
>c) The key that is communicated is a decryption = key rather than an
>encryption key, hence why = "content-encryption" has been changed into
>"content-decryption".
>
>d) The example has been extended to cover the = case of an asymmetric
>cipher
>as well.
>
>e) In the last statement, the intermediate key = would not necessarily be
>a
>symmetric cipher, hence why = "symmetric" has been deleted. Also "cipher"
>has been replaced by "key'.
>
>Note that the current text from X.509 is:
>
>   c) keyEncipherment: for enciphering = keys or other security information,
>      e.g. for key = transport;
>
>   d) dataEncipherment: for = enciphering user data, but not keys or other
>      security = information as in c) above;
>
>Denis

------_=_NextPart_001_01C5572A.CD40DDF9-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CJL7jP010841; Thu, 12 May 2005 12:21:07 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CJL7DZ010840; Thu, 12 May 2005 12:21:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CJL6Gt010834 for ; Thu, 12 May 2005 12:21:06 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8024 invoked by uid 0); 12 May 2005 19:20:59 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.34.201) by woodstock.binhost.com with SMTP; 12 May 2005 19:20:59 -0000 Message-Id: <6.2.1.2.2.20050512151640.04f943c0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 15:21:02 -0400 To: ietf-pkix@vpnc.org From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words. The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e., for key transport. For example, this bit shall be set when a RSA public key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Note that the use of this bit is extremely uncommon; almost all applications use key transport or key agreement to establish a symmetric key. I hope we a re close to closure on this one.... Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CI4r4j005439; Thu, 12 May 2005 11:04:53 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CI4rAq005438; Thu, 12 May 2005 11:04:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CI4pRe005424 for ; Thu, 12 May 2005 11:04:52 -0700 (PDT) (envelope-from todd.glassey@worldnet.att.net) Received: from gw (124.san-jose-09-10rs.ca.dial-access.att.net[12.72.195.124]) by worldnet.att.net (mtiwmhc13) with SMTP id <2005051218052311300pd3hse>; Thu, 12 May 2005 18:05:33 +0000 Message-ID: <00ae01c5571d$1b512ce0$010aff0a@gw> Reply-To: "todd glassey" From: "todd glassey" To: References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> <20050512151755.GA7289@certicom.com> <42838382.8060504@infocamere.it> Subject: Re: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 11:04:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hmmm - The person you are writing for is an IT Auditor because there is NO PKI system that is ever going to be deployed commercially from say 9/11 onward and especially after SOX that is going not have an Auditor's Approval. That means something I tried to get this WG to think about several years ago and that was Practice or Use Models for the IP's themselves. Todd Glassey, CISM, CIFI ----- Original Message ----- From: "Dino Esposito" To: "Sam Roberts" Cc: Sent: Thursday, May 12, 2005 9:25 AM Subject: Re: key usage - key encipherment or data encipherment > > IMO, the typical reader of a RFC is a technician. Especially for a RFC > full of PKI jargon. > If we wanted to write for a layman reader, we should write an encyclopedia > I think the Pinkas' proposal is quite clear. > > Dino Esposito > > Sam Roberts wrote: > > >Wrote Denis Pinkas , on Thu, May 12, 2005 at 04:44:28PM +0200: > > > > > >>Russ, > >> > >> > >> > >>>Since we are working on an update to RFC 3280, I propose the following > >>>revisions to these descritions. > >>> > >>> > >>> The keyEncipherment bit is asserted when the subject public key is > >>> used for key transport. For example, when an RSA key is to be > >>> used for key management by encrypting a symmetric content-encryption > >>> key, then this bit shall asserted. > >>> > >>> The dataEncipherment bit is asserted when the subject public key > >>> is used for directly enciphering raw user data without the use of > >>> an intermediate symmetric cipher. > >>> > >>> > >>Thank you for this strawman proposal. I would rather propose: > >> > >> The keyEncipherment bit is asserted when the subject public key is > >> used for enciphering private or secret keys, i.e. for key transport. > >> For example, this bit shall be set when a public RSA key is to be > >> used for encrypting a symmetric content-decryption key or an > >> asymmetric private key. > >> > >> > > > >Hi Denis, > > > >I think this text has the same problem as the current. In other words, > >somebody might read it and think "I'm not encrypting a key, I'm > >encrypting email, and I'm "transporting" a word document, not a key, so > >this isn't the bit I should look for". This is what happens now. > > > >I can't think of appropriate wording, but if the goal is to make it > >clear to non-security experts so the bit is used consistently, a little > >bit more explanation is needed. > > > > > > > >> The dataEncipherment bit is asserted when the subject public key > >> is used for directly enciphering raw user data without the use of > >> an intermediate key. > >> > >> > > > >This is clear, I think. > > > >Cheers, > >Sam > > > > > > > >>Reasons: > >> > >>a) "Key transport" is not explicit enough. The purpose is to encipher > >>either a private key or a secret key. > >> > >>b) The example is not clear enough: "RSA key" can be a private key or a > >>public key, hence why "public" has been added. > >> > >>c) The key that is communicated is a decryption key rather than an > >>encryption key, hence why "content-encryption" has been changed into > >>"content-decryption". > >> > >>d) The example has been extended to cover the case of an asymmetric cipher > >>as well. > >> > >>e) In the last statement, the intermediate key would not necessarily be a > >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has > >>been replaced by "key'. > >> > >>Note that the current text from X.509 is: > >> > >> c) keyEncipherment: for enciphering keys or other security information, > >> e.g. for key transport; > >> > >> d) dataEncipherment: for enciphering user data, but not keys or other > >> security information as in c) above; > >> > >>Denis > >> > >> > >> > >>>Russ > >>> > >>>At 10:14 PM 5/11/2005, Simon McMahon wrote: > >>> > >>> > >>> > >>>>Russ, > >>>> > >>>>They were calling an 'encrypt' function to encrypt XML data and they > >>>>gave it an RSA key (the cert actually) to do it. Of course it > >>>>internally made an AES key but they never saw it until the > >>>>interoperability issue made them look. From what they saw at the level > >>>>they were looking the interpretation was reasonable. When the > >>>>transport key is well hidden and simply part of the protocol then it > >>>>looks just like RSA is encrypting big slabs of data. If you know that > >>>>RSA is bound by the modulus size then you know what is really > >>>>happening but not all users of PKI know RSA so well. Why should they? > >>>> > >>>>Couple this interpretation of key-usage with a dubious decision to > >>>>reject encryption requests with certs that dont have key-usage='data > >>>>encipherment' and you have an interoperability problem. I say > >>>>"dubious" because it is a public key so you cannot enforce usage > >>>>policy anyway. The CA could set both flags to fix it, which by the way > >>>>was the vendors preferred solution, but its not my CA or their CA and > >>>>the CA doesn't do that. Why should they? > >>>> > >>>>This reference, in my opinion, allows the ambiguous interpretation: > >>>> > >>>> > >>>>> The keyEncipherment bit is asserted when the subject public key is > >>>>> used for key transport. For example, when an RSA key is to be > >>>>> used for key management, then this bit shall asserted. > >>>>> > >>>>> The dataEncipherment bit is asserted when the subject public key > >>>>> is used for enciphering user data, other than cryptographic keys. > >>>>> > >>>>> > >>>>In this case the public key is clearly "intended" to be used to > >>>>encrypt the XML data but it just doesn't do it directly because it > >>>>cant. The term "key management" also has associations with more basic > >>>>and explicit key management operations like installing trusted root > >>>>certs or secure installation of shared secret keys etc. In this case > >>>>it is much less obvious that key management is happening because the > >>>>key is bundled with the data. It looks just like the public key is > >>>>encrypting the data. > >>>> > >>>>In my opinion there are 3 cases presented as 2 in the RFC. > >>>>1. RSA encrypts data - hardly ever used. > >>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data - > >>>>common usage. > >>>>3. RSA explicitly encrypts keys for explicit key management functions > >>>>- common usage. > >>>>The current bits separate 1 from 2/3 yet people make the > >>>>interpretation that they split the more common 2 from 3 assuming 1 and > >>>>2 are the same thing. Knowledge of RSA is required to know that 1 and > >>>>2 are different. > >>>> > >>>>Peter's comment "This bit MUST NOT be set when the intention is to > >>>>encipher intermediate cryptographic keys rather than raw user data" is > >>>>most relevant in my case. Does PKIX support this clarification? > >>>> > >>>>In my opinion this problem will not entirely go away by clarifying the > >>>>standard because most people dont read it before they implement > >>>>something. The two bits are there and as long as they are both there > >>>>then the mistake will be made by busy developers. Unenforceable > >>>>key-usage policy, to "public" keys, will also continue to be > >>>>implemented. People will come looking for clarification once they have > >>>>an interoperability issue but by then it is often too late - the issue > >>>>usually gets decided by who has the biggest corporate balls. In this > >>>>case it wasn't too late so thanks for the assistance. > >>>> > >>>>If I could recommend a change to the standard then I would suggest > >>>>dropping one of the encryption bits and just have a single key-usage = > >>>>"encryption". Give it the value the same as "key-encryption" since > >>>>this is the common usage. > >>>> > >>>>Thanks, > >>>> > >>>>Simon McMahon. > >>>> > >>>> > >>>>Simon McMahon > >>>> > >>>>Work: (07) 31311420 > >>>>Mobile: (043) 2294180 > >>>> > >>>> > >>>> > >>>> > >>>>>>>Russ Housley 05/12/05 01:06am >>> > >>>>>>> > >>>>>>> > >>>>Simon: > >>>> > >>>>If they are encrypting the XML data directly with the RSA key (which is > >>>>very unlikely), then they are correct. > >>>> > >>>>The traditional way to handle this is to generate a random > >>>>content-encryption key (CEK) and then encrypt the XML data with a > >>>>symmetric algorithm using the CEK. The CEK is encrypted with the RSA > >>>>key from the certificate. Thus, the RSA key is really being used to > >>>>encrypt only > >>>>symmetric keys. > >>>> > >>>>Russ > >>>> > >>>> At 08:33 PM 5/10/2005, Simon McMahon wrote: > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>I have had a recent interoperability issue with a application vendor > >>>>> > >>>>> > >>>>that >didn't like the key-usage attributes in a cert from a CA vendor's > >>>> > >>>> > >>>>>certificate. Signing certs work fine, it was an encryption cert that > >>>>> > >>>>> > >>>>failed. > >>>> > >>>> > >>>>>CA sets key-usage = "key encipherment". > >>>>>Application wants to encrypt some XML data so looks for key-usage = > >>>>> > >>>>> > >>>>"data > >>>> > >>>> > >>>>>encipherment". Reason - because XML is data, not a key. > >>>>> > >>>>>I believe the application vendor is wrong and I explained that the > >>>>> > >>>>> > >>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt > >>>>the data but >they want an official "pkix" ruling based on the > >>>>standard so can someone >please refer me to a statement in the > >>>>standard that clears this up. > >>>> > >>>> > >>>>>Thanks, > >>>>> > >>>>>Simon McMahon. > >>>>> > >>>>> > >>>>> > >>>>>Simon McMahon > >>>>> > >>>>>Work: (07) 31311420 > >>>>>Mobile: (043) 2294180 > >>>>> > >>>>> > >>>>> > >>>>>Simon McMahon > >>>>> > >>>>>Work: (07) 31311420 > >>>>>Mobile: (043) 2294180 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>*********************************************************************** ** > >>>>> > >>>>> > >>>>********** > >>>> > >>>> > >>>>>This email, including any attachments sent with it, is confidential and > >>>>>for the sole use of the intended recipient(s). This confidentiality is > >>>>>not waived or lost, if you receive it and you are not the intended > >>>>>recipient(s), or if it is transmitted/received in error. > >>>>> > >>>>>Any unauthorised use, alteration, disclosure, distribution or review of > >>>>>this email is prohibited. It may be subject to a statutory duty of > >>>>>confidentiality if it relates to health service matters. > >>>>> > >>>>>If you are not the intended recipient(s), or if you have received this > >>>>>email in error, you are asked to immediately notify the sender by > >>>>>telephone or by return email. You should also delete this email and > >>>>>destroy any hard copies produced. > >>>>>*********************************************************************** ** > >>>>> > >>>>> > >>>>********** > >>>> > >>>> > >>>> > >>>>************************************************************************ *********** > >>>> > >>>>This email, including any attachments sent with it, is confidential > >>>>and for the sole use of the intended recipient(s). This > >>>>confidentiality is not waived or lost, if you receive it and you are > >>>>not the intended recipient(s), or if it is transmitted/received in error. > >>>> > >>>>Any unauthorised use, alteration, disclosure, distribution or review > >>>>of this email is prohibited. It may be subject to a statutory duty of > >>>>confidentiality if it relates to health service matters. > >>>> > >>>>If you are not the intended recipient(s), or if you have received this > >>>>email in error, you are asked to immediately notify the sender by > >>>>telephone or by return email. You should also delete this email and > >>>>destroy any hard copies produced. > >>>>************************************************************************ *********** > >>>> > >>>> > >>>> > >>> > >>> > >>> > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHl1dO004100; Thu, 12 May 2005 10:47:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CHl1j1004099; Thu, 12 May 2005 10:47:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CHl00c004092 for ; Thu, 12 May 2005 10:47:00 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id A63FD100B2 for ; Thu, 12 May 2005 13:46:59 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08071-20 for ; Thu, 12 May 2005 13:46:43 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 7103A10090 for ; Thu, 12 May 2005 13:46:43 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005051213462073-15485 ; Thu, 12 May 2005 13:46:20 -0400 Date: Thu, 12 May 2005 13:46:41 -0400 From: Sam Roberts To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Message-ID: <20050512174641.GA11305@certicom.com> References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> <20050512151755.GA7289@certicom.com> <42838382.8060504@infocamere.it> Mime-Version: 1.0 In-Reply-To: <42838382.8060504@infocamere.it> User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/12/2005 01:46:20 PM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/12/2005 01:46:22 PM, Serialize complete at 05/12/2005 01:46:22 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Dino Esposito , on Thu, May 12, 2005 at 06:25:38PM +0200: > IMO, the typical reader of a RFC is a technician. Especially for a RFC > full of PKI jargon. Many of the PKI flags are sufficiently succinctly subscribed that they have been interpreted differently by "technicians". Didn't an earlier poster recount an experience with a *certificate authority* that had been using the wrong flag? If an issuer of certs doesn't get it, then its not clear enough, IMHO. Making it clear enough that this conversation doesn't have to happen again would be useful. It helps none of us if people who (arguably) don't know enough about pki/crypto deploy systems wrongly, because we get asked to interop with them. My 2 cents. > If we wanted to write for a layman reader, we should write an encyclopedia Its always a balance, but when interop has failed to occur, perhaps we need to be more encyclopedic. > I think the Pinkas' proposal is quite clear. You probably understood the original text, too. Cheers, Sam > Dino Esposito > > Sam Roberts wrote: > > >Wrote Denis Pinkas , on Thu, May 12, 2005 at > >04:44:28PM +0200: > > > > > >>Russ, > >> > >> > >> > >>>Since we are working on an update to RFC 3280, I propose the following > >>>revisions to these descritions. > >>> > >>> > >>> The keyEncipherment bit is asserted when the subject public key is > >>> used for key transport. For example, when an RSA key is to be > >>> used for key management by encrypting a symmetric content-encryption > >>> key, then this bit shall asserted. > >>> > >>> The dataEncipherment bit is asserted when the subject public key > >>> is used for directly enciphering raw user data without the use of > >>> an intermediate symmetric cipher. > >>> > >>> > >>Thank you for this strawman proposal. I would rather propose: > >> > >> The keyEncipherment bit is asserted when the subject public key is > >> used for enciphering private or secret keys, i.e. for key transport. > >> For example, this bit shall be set when a public RSA key is to be > >> used for encrypting a symmetric content-decryption key or an > >> asymmetric private key. > >> > >> > > > >Hi Denis, > > > >I think this text has the same problem as the current. In other words, > >somebody might read it and think "I'm not encrypting a key, I'm > >encrypting email, and I'm "transporting" a word document, not a key, so > >this isn't the bit I should look for". This is what happens now. > > > >I can't think of appropriate wording, but if the goal is to make it > >clear to non-security experts so the bit is used consistently, a little > >bit more explanation is needed. > > > > > > > >> The dataEncipherment bit is asserted when the subject public key > >> is used for directly enciphering raw user data without the use of > >> an intermediate key. > >> > >> > > > >This is clear, I think. > > > >Cheers, > >Sam > > > > > > > >>Reasons: > >> > >>a) "Key transport" is not explicit enough. The purpose is to encipher > >>either a private key or a secret key. > >> > >>b) The example is not clear enough: "RSA key" can be a private key or a > >>public key, hence why "public" has been added. > >> > >>c) The key that is communicated is a decryption key rather than an > >>encryption key, hence why "content-encryption" has been changed into > >>"content-decryption". > >> > >>d) The example has been extended to cover the case of an asymmetric > >>cipher as well. > >> > >>e) In the last statement, the intermediate key would not necessarily be a > >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" > >>has been replaced by "key'. > >> > >>Note that the current text from X.509 is: > >> > >> c) keyEncipherment: for enciphering keys or other security information, > >> e.g. for key transport; > >> > >> d) dataEncipherment: for enciphering user data, but not keys or other > >> security information as in c) above; > >> > >>Denis > >> > >> > >> > >>>Russ > >>> > >>>At 10:14 PM 5/11/2005, Simon McMahon wrote: > >>> > >>> > >>> > >>>>Russ, > >>>> > >>>>They were calling an 'encrypt' function to encrypt XML data and they > >>>>gave it an RSA key (the cert actually) to do it. Of course it > >>>>internally made an AES key but they never saw it until the > >>>>interoperability issue made them look. From what they saw at the level > >>>>they were looking the interpretation was reasonable. When the > >>>>transport key is well hidden and simply part of the protocol then it > >>>>looks just like RSA is encrypting big slabs of data. If you know that > >>>>RSA is bound by the modulus size then you know what is really > >>>>happening but not all users of PKI know RSA so well. Why should they? > >>>> > >>>>Couple this interpretation of key-usage with a dubious decision to > >>>>reject encryption requests with certs that dont have key-usage='data > >>>>encipherment' and you have an interoperability problem. I say > >>>>"dubious" because it is a public key so you cannot enforce usage > >>>>policy anyway. The CA could set both flags to fix it, which by the way > >>>>was the vendors preferred solution, but its not my CA or their CA and > >>>>the CA doesn't do that. Why should they? > >>>> > >>>>This reference, in my opinion, allows the ambiguous interpretation: > >>>> > >>>> > >>>>> The keyEncipherment bit is asserted when the subject public key is > >>>>> used for key transport. For example, when an RSA key is to be > >>>>> used for key management, then this bit shall asserted. > >>>>> > >>>>> The dataEncipherment bit is asserted when the subject public key > >>>>> is used for enciphering user data, other than cryptographic keys. > >>>>> > >>>>> > >>>>In this case the public key is clearly "intended" to be used to > >>>>encrypt the XML data but it just doesn't do it directly because it > >>>>cant. The term "key management" also has associations with more basic > >>>>and explicit key management operations like installing trusted root > >>>>certs or secure installation of shared secret keys etc. In this case > >>>>it is much less obvious that key management is happening because the > >>>>key is bundled with the data. It looks just like the public key is > >>>>encrypting the data. > >>>> > >>>>In my opinion there are 3 cases presented as 2 in the RFC. > >>>>1. RSA encrypts data - hardly ever used. > >>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data - > >>>>common usage. > >>>>3. RSA explicitly encrypts keys for explicit key management functions > >>>>- common usage. > >>>>The current bits separate 1 from 2/3 yet people make the > >>>>interpretation that they split the more common 2 from 3 assuming 1 and > >>>>2 are the same thing. Knowledge of RSA is required to know that 1 and > >>>>2 are different. > >>>> > >>>>Peter's comment "This bit MUST NOT be set when the intention is to > >>>>encipher intermediate cryptographic keys rather than raw user data" is > >>>>most relevant in my case. Does PKIX support this clarification? > >>>> > >>>>In my opinion this problem will not entirely go away by clarifying the > >>>>standard because most people dont read it before they implement > >>>>something. The two bits are there and as long as they are both there > >>>>then the mistake will be made by busy developers. Unenforceable > >>>>key-usage policy, to "public" keys, will also continue to be > >>>>implemented. People will come looking for clarification once they have > >>>>an interoperability issue but by then it is often too late - the issue > >>>>usually gets decided by who has the biggest corporate balls. In this > >>>>case it wasn't too late so thanks for the assistance. > >>>> > >>>>If I could recommend a change to the standard then I would suggest > >>>>dropping one of the encryption bits and just have a single key-usage = > >>>>"encryption". Give it the value the same as "key-encryption" since > >>>>this is the common usage. > >>>> > >>>>Thanks, > >>>> > >>>>Simon McMahon. > >>>> > >>>> > >>>>Simon McMahon > >>>> > >>>>Work: (07) 31311420 > >>>>Mobile: (043) 2294180 > >>>> > >>>> > >>>> > >>>> > >>>>>>>Russ Housley 05/12/05 01:06am >>> > >>>>>>> > >>>>>>> > >>>>Simon: > >>>> > >>>>If they are encrypting the XML data directly with the RSA key (which is > >>>>very unlikely), then they are correct. > >>>> > >>>>The traditional way to handle this is to generate a random > >>>>content-encryption key (CEK) and then encrypt the XML data with a > >>>>symmetric algorithm using the CEK. The CEK is encrypted with the RSA > >>>>key from the certificate. Thus, the RSA key is really being used to > >>>>encrypt only > >>>>symmetric keys. > >>>> > >>>>Russ > >>>> > >>>>At 08:33 PM 5/10/2005, Simon McMahon wrote: > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>I have had a recent interoperability issue with a application vendor > >>>>> > >>>>> > >>>>that >didn't like the key-usage attributes in a cert from a CA vendor's > >>>> > >>>> > >>>>>certificate. Signing certs work fine, it was an encryption cert that > >>>>> > >>>>> > >>>>failed. > >>>> > >>>> > >>>>>CA sets key-usage = "key encipherment". > >>>>>Application wants to encrypt some XML data so looks for key-usage = > >>>>> > >>>>> > >>>>"data > >>>> > >>>> > >>>>>encipherment". Reason - because XML is data, not a key. > >>>>> > >>>>>I believe the application vendor is wrong and I explained that the > >>>>> > >>>>> > >>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt > >>>>the data but >they want an official "pkix" ruling based on the > >>>>standard so can someone >please refer me to a statement in the > >>>>standard that clears this up. > >>>> > >>>> > >>>>>Thanks, > >>>>> > >>>>>Simon McMahon. > >>>>> > >>>>> > >>>>> > >>>>>Simon McMahon > >>>>> > >>>>>Work: (07) 31311420 > >>>>>Mobile: (043) 2294180 > >>>>> > >>>>> > >>>>> > >>>>>Simon McMahon > >>>>> > >>>>>Work: (07) 31311420 > >>>>>Mobile: (043) 2294180 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>************************************************************************* > >>>>> > >>>>> > >>>>********** > >>>> > >>>> > >>>>>This email, including any attachments sent with it, is confidential and > >>>>>for the sole use of the intended recipient(s). This confidentiality is > >>>>>not waived or lost, if you receive it and you are not the intended > >>>>>recipient(s), or if it is transmitted/received in error. > >>>>> > >>>>>Any unauthorised use, alteration, disclosure, distribution or review of > >>>>>this email is prohibited. It may be subject to a statutory duty of > >>>>>confidentiality if it relates to health service matters. > >>>>> > >>>>>If you are not the intended recipient(s), or if you have received this > >>>>>email in error, you are asked to immediately notify the sender by > >>>>>telephone or by return email. You should also delete this email and > >>>>>destroy any hard copies produced. > >>>>>************************************************************************* > >>>>> > >>>>> > >>>>********** > >>>> > >>>> > >>>> > >>>>*********************************************************************************** > >>>> > >>>>This email, including any attachments sent with it, is confidential > >>>>and for the sole use of the intended recipient(s). This > >>>>confidentiality is not waived or lost, if you receive it and you are > >>>>not the intended recipient(s), or if it is transmitted/received in > >>>>error. > >>>> > >>>>Any unauthorised use, alteration, disclosure, distribution or review > >>>>of this email is prohibited. It may be subject to a statutory duty of > >>>>confidentiality if it relates to health service matters. > >>>> > >>>>If you are not the intended recipient(s), or if you have received this > >>>>email in error, you are asked to immediately notify the sender by > >>>>telephone or by return email. You should also delete this email and > >>>>destroy any hard copies produced. > >>>>*********************************************************************************** > >>>> > >>>> > >>>> > >>> > >>> > >>> > > > > > > -- http://www.certicom.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHRnvY002987; Thu, 12 May 2005 10:27:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CHRnj2002986; Thu, 12 May 2005 10:27:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth09.mail.atl.earthlink.net (smtpauth09.mail.atl.earthlink.net [209.86.89.69]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CHRm2Q002979 for ; Thu, 12 May 2005 10:27:48 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.3]) by smtpauth09.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DWHTP-0002Mf-LX; Thu, 12 May 2005 13:27:48 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:In-Reply-To:References:Date:To:From:Subject:Cc:Content-Type; b=RUcbwiKjPzcffmlKAsRTMD4OMqnP43KUlNfjswPsQtBajYU2SlOftPGhBDNmJmLz; Mime-Version: 1.0 Message-Id: In-Reply-To: <42834ED0.9090306@free.fr> References: <42834ED0.9090306@free.fr> Date: Thu, 12 May 2005 10:27:27 -0700 To: Jean-Marc Desperrier From: Hoyt L Kesterson II Subject: Re: Technical Corrigenda 3 to the 4th edition of X.509 Cc: pkix Content-Type: text/plain; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47874241ab66785ff6d830ffa856bbc35b2e28ca8a23ac5204d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: i apologize for the name problem This is approved text with no posibility of change except by subsequent defect report or amendment. Denis Pinkas was very active in the several ballots held on this document over the last few years as well as several other PKIX participants. Your comments would have been appreciated and considered during that period but cannot now be applied to the document that has had approval within ISO and ITU. hoyt At 14:40 +0200 5/12/05, Jean-Marc Desperrier wrote: >Hoyt L Kesterson II wrote: > >>Some you worked with the X.509 standards committee over the last few years revising the text on key usage. >> >>You can find the text of that Technical Corrigenda at: >>ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf > >You should avoid using characters in the filename that are not compatible with the Microsoft OS, it makes it harder to download that file. > >From the text : >"Bits in the KeyUsage type are as follows: >[...] >c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport; >d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above; >e) keyAgreement: for use as a public key agreement key;" > >It's not yet very precise. The contentCommitment bit text got very clear, so it shows how much we can improve on those bits. > >The text by Peter is quite good, how about : > >c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport, and also data encryption that uses an intermediate symmetric cipher; >d) dataEncipherment: for directly enciphering raw user data, without the use of an intermediate symmetric cipher >e) keyAgreement: for use as a public key agreement key, for example a Diffie-Hellman protocol key; > >Shouldn't we best find a way to say that an SSL client requires at a minimum only digitalSignature, but the SSL server must have keyEncipherment ? > >Maybe we should precise : >In practice when someone wishes to send enciphered key or security information, he must check that the recipient has the keyEncipherment bit set before using his public key to encipher. For example in an SSL handshake, the client must check that the server has the keyEncipherment bit set before sending him an enciphered secret, but never needs to have that bit set in his own certificate, because the server will use his certificate only for authentification, not to send enciphered data. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CGPwoW097750; Thu, 12 May 2005 09:25:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CGPwns097749; Thu, 12 May 2005 09:25:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from lxme02.infocamere.it (lxme02.infocamere.it [80.82.0.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CGPv2C097736 for ; Thu, 12 May 2005 09:25:58 -0700 (PDT) (envelope-from alfredo.esposito@infocamere.it) Received: from lxm02.icnet (lxm02.icnet [1.5.0.11]) by lxme02.infocamere.it (8.12.11/8.12.11) with ESMTP id j4CGPfE6019340; Thu, 12 May 2005 18:25:42 +0200 Received: from lxm02.icnet (localhost.localdomain [127.0.0.1]) by lxm02.icnet (8.12.8/8.12.8) with ESMTP id j4CGPe1v004055; Thu, 12 May 2005 18:25:41 +0200 Received: from [1.71.4.82] (IC2300323.ic.intra.infocamere.it [1.71.4.82]) (authenticated bits=0) by lxm02.icnet (8.12.8/8.12.8) with ESMTP id j4CGPaa9003962; Thu, 12 May 2005 18:25:40 +0200 Message-ID: <42838382.8060504@infocamere.it> Date: Thu, 12 May 2005 18:25:38 +0200 From: Dino Esposito User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Roberts CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> <20050512151755.GA7289@certicom.com> In-Reply-To: <20050512151755.GA7289@certicom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (lxme02.infocamere.it [80.82.0.240]); Thu, 12 May 2005 18:25:42 +0200 (CEST) Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: IMO, the typical reader of a RFC is a technician. Especially for a RFC full of PKI jargon. If we wanted to write for a layman reader, we should write an encyclopedia I think the Pinkas' proposal is quite clear. Dino Esposito Sam Roberts wrote: >Wrote Denis Pinkas , on Thu, May 12, 2005 at 04:44:28PM +0200: > > >>Russ, >> >> >> >>>Since we are working on an update to RFC 3280, I propose the following >>>revisions to these descritions. >>> >>> >>> The keyEncipherment bit is asserted when the subject public key is >>> used for key transport. For example, when an RSA key is to be >>> used for key management by encrypting a symmetric content-encryption >>> key, then this bit shall asserted. >>> >>> The dataEncipherment bit is asserted when the subject public key >>> is used for directly enciphering raw user data without the use of >>> an intermediate symmetric cipher. >>> >>> >>Thank you for this strawman proposal. I would rather propose: >> >> The keyEncipherment bit is asserted when the subject public key is >> used for enciphering private or secret keys, i.e. for key transport. >> For example, this bit shall be set when a public RSA key is to be >> used for encrypting a symmetric content-decryption key or an >> asymmetric private key. >> >> > >Hi Denis, > >I think this text has the same problem as the current. In other words, >somebody might read it and think "I'm not encrypting a key, I'm >encrypting email, and I'm "transporting" a word document, not a key, so >this isn't the bit I should look for". This is what happens now. > >I can't think of appropriate wording, but if the goal is to make it >clear to non-security experts so the bit is used consistently, a little >bit more explanation is needed. > > > >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate key. >> >> > >This is clear, I think. > >Cheers, >Sam > > > >>Reasons: >> >>a) "Key transport" is not explicit enough. The purpose is to encipher >>either a private key or a secret key. >> >>b) The example is not clear enough: "RSA key" can be a private key or a >>public key, hence why "public" has been added. >> >>c) The key that is communicated is a decryption key rather than an >>encryption key, hence why "content-encryption" has been changed into >>"content-decryption". >> >>d) The example has been extended to cover the case of an asymmetric cipher >>as well. >> >>e) In the last statement, the intermediate key would not necessarily be a >>symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has >>been replaced by "key'. >> >>Note that the current text from X.509 is: >> >> c) keyEncipherment: for enciphering keys or other security information, >> e.g. for key transport; >> >> d) dataEncipherment: for enciphering user data, but not keys or other >> security information as in c) above; >> >>Denis >> >> >> >>>Russ >>> >>>At 10:14 PM 5/11/2005, Simon McMahon wrote: >>> >>> >>> >>>>Russ, >>>> >>>>They were calling an 'encrypt' function to encrypt XML data and they >>>>gave it an RSA key (the cert actually) to do it. Of course it >>>>internally made an AES key but they never saw it until the >>>>interoperability issue made them look. From what they saw at the level >>>>they were looking the interpretation was reasonable. When the >>>>transport key is well hidden and simply part of the protocol then it >>>>looks just like RSA is encrypting big slabs of data. If you know that >>>>RSA is bound by the modulus size then you know what is really >>>>happening but not all users of PKI know RSA so well. Why should they? >>>> >>>>Couple this interpretation of key-usage with a dubious decision to >>>>reject encryption requests with certs that dont have key-usage='data >>>>encipherment' and you have an interoperability problem. I say >>>>"dubious" because it is a public key so you cannot enforce usage >>>>policy anyway. The CA could set both flags to fix it, which by the way >>>>was the vendors preferred solution, but its not my CA or their CA and >>>>the CA doesn't do that. Why should they? >>>> >>>>This reference, in my opinion, allows the ambiguous interpretation: >>>> >>>> >>>>> The keyEncipherment bit is asserted when the subject public key is >>>>> used for key transport. For example, when an RSA key is to be >>>>> used for key management, then this bit shall asserted. >>>>> >>>>> The dataEncipherment bit is asserted when the subject public key >>>>> is used for enciphering user data, other than cryptographic keys. >>>>> >>>>> >>>>In this case the public key is clearly "intended" to be used to >>>>encrypt the XML data but it just doesn't do it directly because it >>>>cant. The term "key management" also has associations with more basic >>>>and explicit key management operations like installing trusted root >>>>certs or secure installation of shared secret keys etc. In this case >>>>it is much less obvious that key management is happening because the >>>>key is bundled with the data. It looks just like the public key is >>>>encrypting the data. >>>> >>>>In my opinion there are 3 cases presented as 2 in the RFC. >>>>1. RSA encrypts data - hardly ever used. >>>>2. RSA implicitly encrypts keys so it can really encrypt bulk data - >>>>common usage. >>>>3. RSA explicitly encrypts keys for explicit key management functions >>>>- common usage. >>>>The current bits separate 1 from 2/3 yet people make the >>>>interpretation that they split the more common 2 from 3 assuming 1 and >>>>2 are the same thing. Knowledge of RSA is required to know that 1 and >>>>2 are different. >>>> >>>>Peter's comment "This bit MUST NOT be set when the intention is to >>>>encipher intermediate cryptographic keys rather than raw user data" is >>>>most relevant in my case. Does PKIX support this clarification? >>>> >>>>In my opinion this problem will not entirely go away by clarifying the >>>>standard because most people dont read it before they implement >>>>something. The two bits are there and as long as they are both there >>>>then the mistake will be made by busy developers. Unenforceable >>>>key-usage policy, to "public" keys, will also continue to be >>>>implemented. People will come looking for clarification once they have >>>>an interoperability issue but by then it is often too late - the issue >>>>usually gets decided by who has the biggest corporate balls. In this >>>>case it wasn't too late so thanks for the assistance. >>>> >>>>If I could recommend a change to the standard then I would suggest >>>>dropping one of the encryption bits and just have a single key-usage = >>>>"encryption". Give it the value the same as "key-encryption" since >>>>this is the common usage. >>>> >>>>Thanks, >>>> >>>>Simon McMahon. >>>> >>>> >>>>Simon McMahon >>>> >>>>Work: (07) 31311420 >>>>Mobile: (043) 2294180 >>>> >>>> >>>> >>>> >>>>>>>Russ Housley 05/12/05 01:06am >>> >>>>>>> >>>>>>> >>>>Simon: >>>> >>>>If they are encrypting the XML data directly with the RSA key (which is >>>>very unlikely), then they are correct. >>>> >>>>The traditional way to handle this is to generate a random >>>>content-encryption key (CEK) and then encrypt the XML data with a >>>>symmetric algorithm using the CEK. The CEK is encrypted with the RSA >>>>key from the certificate. Thus, the RSA key is really being used to >>>>encrypt only >>>>symmetric keys. >>>> >>>>Russ >>>> >>>> At 08:33 PM 5/10/2005, Simon McMahon wrote: >>>> >>>> >>>> >>>>>Hi, >>>>> >>>>>I have had a recent interoperability issue with a application vendor >>>>> >>>>> >>>>that >didn't like the key-usage attributes in a cert from a CA vendor's >>>> >>>> >>>>>certificate. Signing certs work fine, it was an encryption cert that >>>>> >>>>> >>>>failed. >>>> >>>> >>>>>CA sets key-usage = "key encipherment". >>>>>Application wants to encrypt some XML data so looks for key-usage = >>>>> >>>>> >>>>"data >>>> >>>> >>>>>encipherment". Reason - because XML is data, not a key. >>>>> >>>>>I believe the application vendor is wrong and I explained that the >>>>> >>>>> >>>>RSA key >actually encrypts an AES key so it doesn't directly encrypt >>>>the data but >they want an official "pkix" ruling based on the >>>>standard so can someone >please refer me to a statement in the >>>>standard that clears this up. >>>> >>>> >>>>>Thanks, >>>>> >>>>>Simon McMahon. >>>>> >>>>> >>>>> >>>>>Simon McMahon >>>>> >>>>>Work: (07) 31311420 >>>>>Mobile: (043) 2294180 >>>>> >>>>> >>>>> >>>>>Simon McMahon >>>>> >>>>>Work: (07) 31311420 >>>>>Mobile: (043) 2294180 >>>>> >>>>> >>>>> >>>>> >>>>>************************************************************************* >>>>> >>>>> >>>>********** >>>> >>>> >>>>>This email, including any attachments sent with it, is confidential and >>>>>for the sole use of the intended recipient(s). This confidentiality is >>>>>not waived or lost, if you receive it and you are not the intended >>>>>recipient(s), or if it is transmitted/received in error. >>>>> >>>>>Any unauthorised use, alteration, disclosure, distribution or review of >>>>>this email is prohibited. It may be subject to a statutory duty of >>>>>confidentiality if it relates to health service matters. >>>>> >>>>>If you are not the intended recipient(s), or if you have received this >>>>>email in error, you are asked to immediately notify the sender by >>>>>telephone or by return email. You should also delete this email and >>>>>destroy any hard copies produced. >>>>>************************************************************************* >>>>> >>>>> >>>>********** >>>> >>>> >>>> >>>>*********************************************************************************** >>>> >>>>This email, including any attachments sent with it, is confidential >>>>and for the sole use of the intended recipient(s). This >>>>confidentiality is not waived or lost, if you receive it and you are >>>>not the intended recipient(s), or if it is transmitted/received in error. >>>> >>>>Any unauthorised use, alteration, disclosure, distribution or review >>>>of this email is prohibited. It may be subject to a statutory duty of >>>>confidentiality if it relates to health service matters. >>>> >>>>If you are not the intended recipient(s), or if you have received this >>>>email in error, you are asked to immediately notify the sender by >>>>telephone or by return email. You should also delete this email and >>>>destroy any hard copies produced. >>>>*********************************************************************************** >>>> >>>> >>>> >>> >>> >>> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CFZaal093343; Thu, 12 May 2005 08:35:36 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CFZaXL093342; Thu, 12 May 2005 08:35:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CFZaCM093335 for ; Thu, 12 May 2005 08:35:36 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 20476 invoked by uid 0); 12 May 2005 15:35:32 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.148.50) by woodstock.binhost.com with SMTP; 12 May 2005 15:35:32 -0000 Message-Id: <6.2.1.2.2.20050512112059.0613bc20@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 11:22:04 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <42836BCC.5000804@bull.net> References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: Thanks. I think you suggestion improves the text. Russ At 10:44 AM 5/12/2005, Denis Pinkas wrote: >Russ, > >>Since we are working on an update to RFC 3280, I propose the following >>revisions to these descritions. > >> The keyEncipherment bit is asserted when the subject public key is >> used for key transport. For example, when an RSA key is to be >> used for key management by encrypting a symmetric content-encryption >> key, then this bit shall asserted. >> The dataEncipherment bit is asserted when the subject public key >> is used for directly enciphering raw user data without the use of >> an intermediate symmetric cipher. > >Thank you for this strawman proposal. I would rather propose: > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e. for key transport. > For example, this bit shall be set when a public RSA key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate key. > >Reasons: > >a) "Key transport" is not explicit enough. The purpose is to encipher >either a private key or a secret key. > >b) The example is not clear enough: "RSA key" can be a private key or a >public key, hence why "public" has been added. > >c) The key that is communicated is a decryption key rather than an >encryption key, hence why "content-encryption" has been changed into >"content-decryption". > >d) The example has been extended to cover the case of an asymmetric cipher >as well. > >e) In the last statement, the intermediate key would not necessarily be a >symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" >has been replaced by "key'. > >Note that the current text from X.509 is: > > c) keyEncipherment: for enciphering keys or other security information, > e.g. for key transport; > > d) dataEncipherment: for enciphering user data, but not keys or other > security information as in c) above; > >Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CFIHuT091797; Thu, 12 May 2005 08:18:17 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CFIH1t091796; Thu, 12 May 2005 08:18:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail.ca.certicom.com (ns.ca.certicom.com [66.48.18.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CFIG7L091774 for ; Thu, 12 May 2005 08:18:16 -0700 (PDT) (envelope-from sroberts@certicom.com) Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 4947E100B9 for ; Thu, 12 May 2005 11:18:10 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06890-67 for ; Thu, 12 May 2005 11:17:55 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 7A2BB10084 for ; Thu, 12 May 2005 11:17:55 -0400 (EDT) Received: from sroberts ([10.0.2.195]) by certicom1.certicom.com (Lotus Domino Release 6.5.1) with ESMTP id 2005051211173420-15101 ; Thu, 12 May 2005 11:17:34 -0400 Date: Thu, 12 May 2005 11:17:55 -0400 From: Sam Roberts To: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Message-ID: <20050512151755.GA7289@certicom.com> References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> <42836BCC.5000804@bull.net> Mime-Version: 1.0 In-Reply-To: <42836BCC.5000804@bull.net> User-Agent: Mutt/1.5.0i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/12/2005 11:17:34 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/12/2005 11:17:34 AM, Serialize complete at 05/12/2005 11:17:34 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Wrote Denis Pinkas , on Thu, May 12, 2005 at 04:44:28PM +0200: > > Russ, > > >Since we are working on an update to RFC 3280, I propose the following > >revisions to these descritions. > > > The keyEncipherment bit is asserted when the subject public key is > > used for key transport. For example, when an RSA key is to be > > used for key management by encrypting a symmetric content-encryption > > key, then this bit shall asserted. > > > > The dataEncipherment bit is asserted when the subject public key > > is used for directly enciphering raw user data without the use of > > an intermediate symmetric cipher. > > Thank you for this strawman proposal. I would rather propose: > > The keyEncipherment bit is asserted when the subject public key is > used for enciphering private or secret keys, i.e. for key transport. > For example, this bit shall be set when a public RSA key is to be > used for encrypting a symmetric content-decryption key or an > asymmetric private key. Hi Denis, I think this text has the same problem as the current. In other words, somebody might read it and think "I'm not encrypting a key, I'm encrypting email, and I'm "transporting" a word document, not a key, so this isn't the bit I should look for". This is what happens now. I can't think of appropriate wording, but if the goal is to make it clear to non-security experts so the bit is used consistently, a little bit more explanation is needed. > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate key. This is clear, I think. Cheers, Sam > Reasons: > > a) "Key transport" is not explicit enough. The purpose is to encipher > either a private key or a secret key. > > b) The example is not clear enough: "RSA key" can be a private key or a > public key, hence why "public" has been added. > > c) The key that is communicated is a decryption key rather than an > encryption key, hence why "content-encryption" has been changed into > "content-decryption". > > d) The example has been extended to cover the case of an asymmetric cipher > as well. > > e) In the last statement, the intermediate key would not necessarily be a > symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has > been replaced by "key'. > > Note that the current text from X.509 is: > > c) keyEncipherment: for enciphering keys or other security information, > e.g. for key transport; > > d) dataEncipherment: for enciphering user data, but not keys or other > security information as in c) above; > > Denis > > >Russ > > > >At 10:14 PM 5/11/2005, Simon McMahon wrote: > > > >>Russ, > >> > >>They were calling an 'encrypt' function to encrypt XML data and they > >>gave it an RSA key (the cert actually) to do it. Of course it > >>internally made an AES key but they never saw it until the > >>interoperability issue made them look. From what they saw at the level > >>they were looking the interpretation was reasonable. When the > >>transport key is well hidden and simply part of the protocol then it > >>looks just like RSA is encrypting big slabs of data. If you know that > >>RSA is bound by the modulus size then you know what is really > >>happening but not all users of PKI know RSA so well. Why should they? > >> > >>Couple this interpretation of key-usage with a dubious decision to > >>reject encryption requests with certs that dont have key-usage='data > >>encipherment' and you have an interoperability problem. I say > >>"dubious" because it is a public key so you cannot enforce usage > >>policy anyway. The CA could set both flags to fix it, which by the way > >>was the vendors preferred solution, but its not my CA or their CA and > >>the CA doesn't do that. Why should they? > >> > >>This reference, in my opinion, allows the ambiguous interpretation: > >>> The keyEncipherment bit is asserted when the subject public key is > >>> used for key transport. For example, when an RSA key is to be > >>> used for key management, then this bit shall asserted. > >>> > >>> The dataEncipherment bit is asserted when the subject public key > >>> is used for enciphering user data, other than cryptographic keys. > >> > >>In this case the public key is clearly "intended" to be used to > >>encrypt the XML data but it just doesn't do it directly because it > >>cant. The term "key management" also has associations with more basic > >>and explicit key management operations like installing trusted root > >>certs or secure installation of shared secret keys etc. In this case > >>it is much less obvious that key management is happening because the > >>key is bundled with the data. It looks just like the public key is > >>encrypting the data. > >> > >>In my opinion there are 3 cases presented as 2 in the RFC. > >>1. RSA encrypts data - hardly ever used. > >>2. RSA implicitly encrypts keys so it can really encrypt bulk data - > >>common usage. > >>3. RSA explicitly encrypts keys for explicit key management functions > >>- common usage. > >>The current bits separate 1 from 2/3 yet people make the > >>interpretation that they split the more common 2 from 3 assuming 1 and > >>2 are the same thing. Knowledge of RSA is required to know that 1 and > >>2 are different. > >> > >>Peter's comment "This bit MUST NOT be set when the intention is to > >>encipher intermediate cryptographic keys rather than raw user data" is > >>most relevant in my case. Does PKIX support this clarification? > >> > >>In my opinion this problem will not entirely go away by clarifying the > >>standard because most people dont read it before they implement > >>something. The two bits are there and as long as they are both there > >>then the mistake will be made by busy developers. Unenforceable > >>key-usage policy, to "public" keys, will also continue to be > >>implemented. People will come looking for clarification once they have > >>an interoperability issue but by then it is often too late - the issue > >>usually gets decided by who has the biggest corporate balls. In this > >>case it wasn't too late so thanks for the assistance. > >> > >>If I could recommend a change to the standard then I would suggest > >>dropping one of the encryption bits and just have a single key-usage = > >>"encryption". Give it the value the same as "key-encryption" since > >>this is the common usage. > >> > >>Thanks, > >> > >>Simon McMahon. > >> > >> > >>Simon McMahon > >> > >>Work: (07) 31311420 > >>Mobile: (043) 2294180 > >> > >> > >>>>> Russ Housley 05/12/05 01:06am >>> > >>Simon: > >> > >>If they are encrypting the XML data directly with the RSA key (which is > >>very unlikely), then they are correct. > >> > >>The traditional way to handle this is to generate a random > >>content-encryption key (CEK) and then encrypt the XML data with a > >>symmetric algorithm using the CEK. The CEK is encrypted with the RSA > >>key from the certificate. Thus, the RSA key is really being used to > >>encrypt only > >>symmetric keys. > >> > >>Russ > >> > >> At 08:33 PM 5/10/2005, Simon McMahon wrote: > >> > >>>Hi, > >>> > >>>I have had a recent interoperability issue with a application vendor > >>that >didn't like the key-usage attributes in a cert from a CA vendor's > >>>certificate. Signing certs work fine, it was an encryption cert that > >>failed. > >>> > >>>CA sets key-usage = "key encipherment". > >>>Application wants to encrypt some XML data so looks for key-usage = > >>"data > >>>encipherment". Reason - because XML is data, not a key. > >>> > >>>I believe the application vendor is wrong and I explained that the > >>RSA key >actually encrypts an AES key so it doesn't directly encrypt > >>the data but >they want an official "pkix" ruling based on the > >>standard so can someone >please refer me to a statement in the > >>standard that clears this up. > >>> > >>>Thanks, > >>> > >>>Simon McMahon. > >>> > >>> > >>> > >>>Simon McMahon > >>> > >>>Work: (07) 31311420 > >>>Mobile: (043) 2294180 > >>> > >>> > >>> > >>>Simon McMahon > >>> > >>>Work: (07) 31311420 > >>>Mobile: (043) 2294180 > >>> > >>> > >>> > >>> > >>>************************************************************************* > >>********** > >>>This email, including any attachments sent with it, is confidential and > >>>for the sole use of the intended recipient(s). This confidentiality is > >>>not waived or lost, if you receive it and you are not the intended > >>>recipient(s), or if it is transmitted/received in error. > >>> > >>>Any unauthorised use, alteration, disclosure, distribution or review of > >>>this email is prohibited. It may be subject to a statutory duty of > >>>confidentiality if it relates to health service matters. > >>> > >>>If you are not the intended recipient(s), or if you have received this > >>>email in error, you are asked to immediately notify the sender by > >>>telephone or by return email. You should also delete this email and > >>>destroy any hard copies produced. > >>>************************************************************************* > >>********** > >> > >> > >> > >>*********************************************************************************** > >> > >>This email, including any attachments sent with it, is confidential > >>and for the sole use of the intended recipient(s). This > >>confidentiality is not waived or lost, if you receive it and you are > >>not the intended recipient(s), or if it is transmitted/received in error. > >> > >>Any unauthorised use, alteration, disclosure, distribution or review > >>of this email is prohibited. It may be subject to a statutory duty of > >>confidentiality if it relates to health service matters. > >> > >>If you are not the intended recipient(s), or if you have received this > >>email in error, you are asked to immediately notify the sender by > >>telephone or by return email. You should also delete this email and > >>destroy any hard copies produced. > >>*********************************************************************************** > >> > > > > > > > -- http://www.certicom.com Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CF1P17089711; Thu, 12 May 2005 08:01:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CF1PsU089710; Thu, 12 May 2005 08:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CF1NrA089704 for ; Thu, 12 May 2005 08:01:24 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 20127 invoked by uid 0); 12 May 2005 15:01:19 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.148.50) by woodstock.binhost.com with SMTP; 12 May 2005 15:01:19 -0000 Message-Id: <6.2.1.2.2.20050512105428.060f0210@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 10:56:46 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: ietf-pkix@imc.org In-Reply-To: <42832509.5020001@bull.net> References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> <42832509.5020001@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: > >>> You say that it is not clear what validation policy needs to be used, > >>> but this is completely irrelevant to the discussion of the CRL AIA > >>> extension. This extension aid in certification path construction, > >>> not the validation of the path once it is constructed. > > >> Not exactly, it could "help" finding a wrong path ! > > > Not likely. The signer of the CRL is providing a pointer to their own > > certificate. Path construction to locate a parent of that certificate > > through a complex PKI might include paths that are acceptable and paths > > that are unacceptable, but the certificate that contains the public key > > needed to validate the signature on the CRL is clearly needed. > >The problem is to know if a CRL that has been fetched "somewhere" is >adequate for the target certificate. It is not to validate a CRL that has >been fetched "somewhere". You continue to miss the whole point of this document. The certificate user has already obtained the CRL, but needs the certificate of the CRL issuer in order to validate the signature on the CRL. That is the scope of this document. You keep trying to make it something else. Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CErMlN089201; Thu, 12 May 2005 07:53:22 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CErMKV089200; Thu, 12 May 2005 07:53:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CErLIp089194 for ; Thu, 12 May 2005 07:53:21 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 8868 invoked by uid 0); 12 May 2005 14:53:18 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.148.50) by woodstock.binhost.com with SMTP; 12 May 2005 14:53:18 -0000 Message-Id: <6.2.1.2.2.20050512104257.0608b450@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 10:53:06 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: pkix In-Reply-To: <42832153.8000802@bull.net> References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> <42832153.8000802@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: Finally! We now uncover the actual point of disagreement. You say: The same trust anchor is not a *sufficient* condition. The same node in the certification tree is the necessary condition. This implies, of course, the same trust anchor, but since two CRL issuers located at different nodes (i.e. certified by different CAS) might have the same CRL issuer name, this condition is insufficient to solve the issue. When policies, procedures, and practices are followed, I do not believe that two different CRL issuers that are subordinate to the same trust anchor can legitimately have the same name. As I said yesterday, I am willing to add text to the Security Considerations section to state this. I am even willing to state that certificate users should not include trust anchors that do not have policies, procedures, and practices that would prevent such name collisions. Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CEhiOJ088531; Thu, 12 May 2005 07:43:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CEhiqh088530; Thu, 12 May 2005 07:43:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CEhh4Y088498 for ; Thu, 12 May 2005 07:43:43 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA46150; Thu, 12 May 2005 16:58:29 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051216433132:1144 ; Thu, 12 May 2005 16:43:31 +0200 Message-ID: <42836BCC.5000804@bull.net> Date: Thu, 12 May 2005 16:44:28 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 16:43:31, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 16:43:33, Serialize complete at 12/05/2005 16:43:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, > Since we are working on an update to RFC 3280, I propose the following > revisions to these descritions. > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management by encrypting a symmetric content-encryption > key, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for directly enciphering raw user data without the use of > an intermediate symmetric cipher. Thank you for this strawman proposal. I would rather propose: The keyEncipherment bit is asserted when the subject public key is used for enciphering private or secret keys, i.e. for key transport. For example, this bit shall be set when a public RSA key is to be used for encrypting a symmetric content-decryption key or an asymmetric private key. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate key. Reasons: a) "Key transport" is not explicit enough. The purpose is to encipher either a private key or a secret key. b) The example is not clear enough: "RSA key" can be a private key or a public key, hence why "public" has been added. c) The key that is communicated is a decryption key rather than an encryption key, hence why "content-encryption" has been changed into "content-decryption". d) The example has been extended to cover the case of an asymmetric cipher as well. e) In the last statement, the intermediate key would not necessarily be a symmetric cipher, hence why "symmetric" has been deleted. Also "cipher" has been replaced by "key'. Note that the current text from X.509 is: c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport; d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above; Denis > Russ > > At 10:14 PM 5/11/2005, Simon McMahon wrote: > >> Russ, >> >> They were calling an 'encrypt' function to encrypt XML data and they >> gave it an RSA key (the cert actually) to do it. Of course it >> internally made an AES key but they never saw it until the >> interoperability issue made them look. From what they saw at the level >> they were looking the interpretation was reasonable. When the >> transport key is well hidden and simply part of the protocol then it >> looks just like RSA is encrypting big slabs of data. If you know that >> RSA is bound by the modulus size then you know what is really >> happening but not all users of PKI know RSA so well. Why should they? >> >> Couple this interpretation of key-usage with a dubious decision to >> reject encryption requests with certs that dont have key-usage='data >> encipherment' and you have an interoperability problem. I say >> "dubious" because it is a public key so you cannot enforce usage >> policy anyway. The CA could set both flags to fix it, which by the way >> was the vendors preferred solution, but its not my CA or their CA and >> the CA doesn't do that. Why should they? >> >> This reference, in my opinion, allows the ambiguous interpretation: >> > The keyEncipherment bit is asserted when the subject public key is >> > used for key transport. For example, when an RSA key is to be >> > used for key management, then this bit shall asserted. >> > >> > The dataEncipherment bit is asserted when the subject public key >> > is used for enciphering user data, other than cryptographic keys. >> >> In this case the public key is clearly "intended" to be used to >> encrypt the XML data but it just doesn't do it directly because it >> cant. The term "key management" also has associations with more basic >> and explicit key management operations like installing trusted root >> certs or secure installation of shared secret keys etc. In this case >> it is much less obvious that key management is happening because the >> key is bundled with the data. It looks just like the public key is >> encrypting the data. >> >> In my opinion there are 3 cases presented as 2 in the RFC. >> 1. RSA encrypts data - hardly ever used. >> 2. RSA implicitly encrypts keys so it can really encrypt bulk data - >> common usage. >> 3. RSA explicitly encrypts keys for explicit key management functions >> - common usage. >> The current bits separate 1 from 2/3 yet people make the >> interpretation that they split the more common 2 from 3 assuming 1 and >> 2 are the same thing. Knowledge of RSA is required to know that 1 and >> 2 are different. >> >> Peter's comment "This bit MUST NOT be set when the intention is to >> encipher intermediate cryptographic keys rather than raw user data" is >> most relevant in my case. Does PKIX support this clarification? >> >> In my opinion this problem will not entirely go away by clarifying the >> standard because most people dont read it before they implement >> something. The two bits are there and as long as they are both there >> then the mistake will be made by busy developers. Unenforceable >> key-usage policy, to "public" keys, will also continue to be >> implemented. People will come looking for clarification once they have >> an interoperability issue but by then it is often too late - the issue >> usually gets decided by who has the biggest corporate balls. In this >> case it wasn't too late so thanks for the assistance. >> >> If I could recommend a change to the standard then I would suggest >> dropping one of the encryption bits and just have a single key-usage = >> "encryption". Give it the value the same as "key-encryption" since >> this is the common usage. >> >> Thanks, >> >> Simon McMahon. >> >> >> Simon McMahon >> >> Work: (07) 31311420 >> Mobile: (043) 2294180 >> >> >> >>> Russ Housley 05/12/05 01:06am >>> >> Simon: >> >> If they are encrypting the XML data directly with the RSA key (which is >> very unlikely), then they are correct. >> >> The traditional way to handle this is to generate a random >> content-encryption key (CEK) and then encrypt the XML data with a >> symmetric algorithm using the CEK. The CEK is encrypted with the RSA >> key from the certificate. Thus, the RSA key is really being used to >> encrypt only >> symmetric keys. >> >> Russ >> >> At 08:33 PM 5/10/2005, Simon McMahon wrote: >> >> >Hi, >> > >> >I have had a recent interoperability issue with a application vendor >> that >didn't like the key-usage attributes in a cert from a CA vendor's >> >certificate. Signing certs work fine, it was an encryption cert that >> failed. >> > >> >CA sets key-usage = "key encipherment". >> >Application wants to encrypt some XML data so looks for key-usage = >> "data >> >encipherment". Reason - because XML is data, not a key. >> > >> >I believe the application vendor is wrong and I explained that the >> RSA key >actually encrypts an AES key so it doesn't directly encrypt >> the data but >they want an official "pkix" ruling based on the >> standard so can someone >please refer me to a statement in the >> standard that clears this up. >> > >> >Thanks, >> > >> >Simon McMahon. >> > >> > >> > >> >Simon McMahon >> > >> >Work: (07) 31311420 >> >Mobile: (043) 2294180 >> > >> > >> > >> >Simon McMahon >> > >> >Work: (07) 31311420 >> >Mobile: (043) 2294180 >> > >> > >> > >> > >> >************************************************************************* >> ********** >> >This email, including any attachments sent with it, is confidential and >> >for the sole use of the intended recipient(s). This confidentiality is >> >not waived or lost, if you receive it and you are not the intended >> >recipient(s), or if it is transmitted/received in error. >> > >> >Any unauthorised use, alteration, disclosure, distribution or review of >> >this email is prohibited. It may be subject to a statutory duty of >> >confidentiality if it relates to health service matters. >> > >> >If you are not the intended recipient(s), or if you have received this >> >email in error, you are asked to immediately notify the sender by >> >telephone or by return email. You should also delete this email and >> >destroy any hard copies produced. >> >************************************************************************* >> ********** >> >> >> >> *********************************************************************************** >> >> This email, including any attachments sent with it, is confidential >> and for the sole use of the intended recipient(s). This >> confidentiality is not waived or lost, if you receive it and you are >> not the intended recipient(s), or if it is transmitted/received in error. >> >> Any unauthorised use, alteration, disclosure, distribution or review >> of this email is prohibited. It may be subject to a statutory duty of >> confidentiality if it relates to health service matters. >> >> If you are not the intended recipient(s), or if you have received this >> email in error, you are asked to immediately notify the sender by >> telephone or by return email. You should also delete this email and >> destroy any hard copies produced. >> *********************************************************************************** >> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CE6QOr085122; Thu, 12 May 2005 07:06:26 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CE6QPc085121; Thu, 12 May 2005 07:06:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4CE6OOM085113 for ; Thu, 12 May 2005 07:06:24 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 27496 invoked by uid 0); 12 May 2005 14:05:10 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.98.205) by woodstock.binhost.com with SMTP; 12 May 2005 14:05:10 -0000 Message-Id: <6.2.1.2.2.20050512100348.064cfae0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 12 May 2005 10:05:10 -0400 To: "Simon McMahon" From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Since we are working on an update to RFC 3280, I propose the following revisions to these descritions. The keyEncipherment bit is asserted when the subject public key is used for key transport. For example, when an RSA key is to be used for key management by encrypting a symmetric content-encryption key, then this bit shall asserted. The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. Russ At 10:14 PM 5/11/2005, Simon McMahon wrote: >Russ, > >They were calling an 'encrypt' function to encrypt XML data and they gave >it an RSA key (the cert actually) to do it. Of course it internally made >an AES key but they never saw it until the interoperability issue made >them look. From what they saw at the level they were looking the >interpretation was reasonable. When the transport key is well hidden and >simply part of the protocol then it looks just like RSA is encrypting big >slabs of data. If you know that RSA is bound by the modulus size then you >know what is really happening but not all users of PKI know RSA so well. >Why should they? > >Couple this interpretation of key-usage with a dubious decision to reject >encryption requests with certs that dont have key-usage='data >encipherment' and you have an interoperability problem. I say "dubious" >because it is a public key so you cannot enforce usage policy anyway. The >CA could set both flags to fix it, which by the way was the vendors >preferred solution, but its not my CA or their CA and the CA doesn't do >that. Why should they? > >This reference, in my opinion, allows the ambiguous interpretation: > > The keyEncipherment bit is asserted when the subject public key is > > used for key transport. For example, when an RSA key is to be > > used for key management, then this bit shall asserted. > > > > The dataEncipherment bit is asserted when the subject public key > > is used for enciphering user data, other than cryptographic keys. > >In this case the public key is clearly "intended" to be used to encrypt >the XML data but it just doesn't do it directly because it cant. The term >"key management" also has associations with more basic and explicit key >management operations like installing trusted root certs or secure >installation of shared secret keys etc. In this case it is much less >obvious that key management is happening because the key is bundled with >the data. It looks just like the public key is encrypting the data. > >In my opinion there are 3 cases presented as 2 in the RFC. >1. RSA encrypts data - hardly ever used. >2. RSA implicitly encrypts keys so it can really encrypt bulk data - >common usage. >3. RSA explicitly encrypts keys for explicit key management functions - >common usage. >The current bits separate 1 from 2/3 yet people make the interpretation >that they split the more common 2 from 3 assuming 1 and 2 are the same >thing. Knowledge of RSA is required to know that 1 and 2 are different. > >Peter's comment "This bit MUST NOT be set when the intention is to >encipher intermediate cryptographic keys rather than raw user data" is >most relevant in my case. Does PKIX support this clarification? > >In my opinion this problem will not entirely go away by clarifying the >standard because most people dont read it before they implement something. >The two bits are there and as long as they are both there then the mistake >will be made by busy developers. Unenforceable key-usage policy, to >"public" keys, will also continue to be implemented. People will come >looking for clarification once they have an interoperability issue but by >then it is often too late - the issue usually gets decided by who has the >biggest corporate balls. In this case it wasn't too late so thanks for the >assistance. > >If I could recommend a change to the standard then I would suggest >dropping one of the encryption bits and just have a single key-usage = >"encryption". Give it the value the same as "key-encryption" since this is >the common usage. > >Thanks, > >Simon McMahon. > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > >>> Russ Housley 05/12/05 01:06am >>> >Simon: > >If they are encrypting the XML data directly with the RSA key (which is >very unlikely), then they are correct. > >The traditional way to handle this is to generate a random >content-encryption key (CEK) and then encrypt the XML data with a >symmetric algorithm using the CEK. The CEK is encrypted with the RSA key >from the certificate. Thus, the RSA key is really being used to encrypt only >symmetric keys. > >Russ > > At 08:33 PM 5/10/2005, Simon McMahon wrote: > > >Hi, > > > >I have had a recent interoperability issue with a application vendor > that >didn't like the key-usage attributes in a cert from a CA vendor's > >certificate. Signing certs work fine, it was an encryption cert that failed. > > > >CA sets key-usage = "key encipherment". > >Application wants to encrypt some XML data so looks for key-usage = "data > >encipherment". Reason - because XML is data, not a key. > > > >I believe the application vendor is wrong and I explained that the RSA > key >actually encrypts an AES key so it doesn't directly encrypt the data > but >they want an official "pkix" ruling based on the standard so can > someone >please refer me to a statement in the standard that clears this up. > > > >Thanks, > > > >Simon McMahon. > > > > > > > >Simon McMahon > > > >Work: (07) 31311420 > >Mobile: (043) 2294180 > > > > > > > >Simon McMahon > > > >Work: (07) 31311420 > >Mobile: (043) 2294180 > > > > > > > > > >************************************************************************* > ********** > >This email, including any attachments sent with it, is confidential and > >for the sole use of the intended recipient(s). This confidentiality is > >not waived or lost, if you receive it and you are not the intended > >recipient(s), or if it is transmitted/received in error. > > > >Any unauthorised use, alteration, disclosure, distribution or review of > >this email is prohibited. It may be subject to a statutory duty of > >confidentiality if it relates to health service matters. > > > >If you are not the intended recipient(s), or if you have received this > >email in error, you are asked to immediately notify the sender by > >telephone or by return email. You should also delete this email and > >destroy any hard copies produced. > >************************************************************************* > ********** > > > >*********************************************************************************** >This email, including any attachments sent with it, is confidential and >for the sole use of the intended recipient(s). This confidentiality is >not waived or lost, if you receive it and you are not the intended >recipient(s), or if it is transmitted/received in error. > >Any unauthorised use, alteration, disclosure, distribution or review of >this email is prohibited. It may be subject to a statutory duty of >confidentiality if it relates to health service matters. > >If you are not the intended recipient(s), or if you have received this >email in error, you are asked to immediately notify the sender by >telephone or by return email. You should also delete this email and >destroy any hard copies produced. >*********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCuksv076754; Thu, 12 May 2005 05:56:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CCukP9076753; Thu, 12 May 2005 05:56:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCui43076701 for ; Thu, 12 May 2005 05:56:45 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 13:56:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Structuring Denis issues RE: Comments on Date: Thu, 12 May 2005 13:56:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVW20qkEAyEpBkhR1uSL+f+s8bQ/AAB8tDwAAOjX8A= From: "Stefan Santesson" To: "Stefan Santesson" , "Denis Pinkas" , "Russ Housley" Cc: "pkix" X-OriginalArrivalTime: 12 May 2005 12:56:38.0773 (UTC) FILETIME=[09483A50:01C556F2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CCuj43076746 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, Reading my own e-mail I think I was not 100% clear on one point. "Proposed resolution" should read "Denis proposed resolution". Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Stefan Santesson > Sent: den 12 maj 2005 13:24 > To: Denis Pinkas; Russ Housley > Cc: pkix > Subject: Structuring Denis issues RE: Comments on 00.txt> > > > Denis, > > The core of your comments are spread over many emails and opinions may > have changed on details so I'm not sure I have got the latest picture of > your recorded problems and what you propose as resolution. > > I'm thus trying to summarize the current complete picture of the last > call comments below. Please correct me if something is wrong or missing. > Note that I'm not arguing here, just trying to structure the issues (I > will argue in separate mails). Also note that agreed typos are omitted > from the list: > > 1) > Problem: There are SHOULD and MUST requirements in the security > considerations section. > > Proposed resolution: Reword to make sure we don't use SHOULD or MUST in > this section. > > ----- > 2) > Problem: The security considerations talk about "mitigation" of the name > collision problem but gives inadequate advice. > > Proposed resolution: Either delete all text talking about how to > mitigate this problem or provide full guidance on what it takes to > guarantee that a CRL Issuer with a matching name actually is the > intended CRL Issuer. Also explain that this is not an issue when the CRL > Issuer certification path and the target certificate certification path > are identical. > > > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > > -----Original Message----- > > From: owner-ietf-pkix@mail.imc.org > [mailto:owner-ietf-pkix@mail.imc.org] > > On Behalf Of Denis Pinkas > > Sent: den 12 maj 2005 11:27 > > To: Russ Housley > > Cc: pkix > > Subject: Re: Comments on > > > > > > Russ, > > > > Since Tim has now made the call at the WG level, please consider this > > message as an answer to the call: the current security considerations > > section is not acceptable. > > > > > The document already says that the CA and the CRL issuer need to > > > terminate at the same trust anchor. This is the important point. > > > I disagree that there is anything else that ought to be said in > the > > > security considerations. > > > > This statement still does not answer to the point I raised, but > > I will nevertheless answer to your statement. > > > > The same trust anchor is not a *sufficient* condition. The same node > in > > the > > certification tree is the necessary condition. This implies, of > course, > > the > > same trust anchor, but since two CRL issuers located at different > nodes > > (i.e. certified by different CAS) might have the same CRL issuer name, > > this > > condition is insufficient to solve the issue. > > > > May I recall an extract from the security considerations section of an > > approved draft that will be published soon as RFC 4043 ? (this is the > > permanent-identifier document): > > > > Subject names in certificates are chosen by the issuing CA and > are > > mandated to be unique for each CA; so there can be no name > collision > > between subject names from the same CA. Such a name may be an > end- > > entity name when the certificate is a leaf certificate, or a CA > > name, > > when it is a CA certificate. > > > > Since a name is only unique towards its superior CA, unless some > > naming constraints are being used, a name would only be > guaranteed > > to > > be globally unique when considered to include a sequence of all > the > > names of the superior CAs. (...) > > > > Additional checks need to be done, e.g., to check if the public > key > > values of the two CAs which have issued the certificates to be > > compared are identical or if the sequence of CA names in the > > certification path from the trust anchor to the CA are > identical. > > > > (...) > > > > The certification of different CAs with the same DN by different > CAs > > has other negative consequences in various parts of the PKI, > notably > > rendering the IssuerAndSerialNumber structure in [RFC3852] > section > > 10.2.4 ambiguous. > > > > It speaks for itself, as it applies to CRL Issuers as well. Some parts > of > > it should indeed be copied and pasted in the security considerations > > section > > of the current proposed draft. > > > > When the certification path used to validate the target certificate is > > also used to validate the CRL Issuer certificate, then there is no > > security > > issue: this should be said in the security considerations section. > > > > What about the other cases ? The other cases belong to the category of > > indirect CRLs. Depending on the local validation policy checks done or > not > > done there may be security issues. > > > > Denis > > > > > Russ > > > > > > At 02:59 AM 5/10/2005, Denis Pinkas wrote: > > > > > >> Russ, > > >> > > >> Your statement below is correct, but does not answer to any of my > > >> questions/issues. In particular, the last one. I am still > awaiting > > >> your responses. > > >> > > >> Denis > > >> > > >>> Denis: > > >>> RFC 3280 does not tell an implementor how for locate > certificates > > for > > >>> any certification path construction. There are several > extensions > > >>> that provide pointers that may help an implementation, but other > > >>> approaches to obtaining the same certificates are always > permitted. > > >>> I would fully expect an implementation to check any local cache > > >>> before accessing a repository. > > >>> The CRL AIA extension fits this pattern. A method for locating > a > > >>> certificate is provided, but any other mechanism for locating > the > > >>> same certificate is acceptable. > > >>> Russ > > >>> > > >>>> Stefan, > > >>>> > > >>>> I made the e-mail shorter. Your main arguments are the > following: > > >>>> > > >>>> > > > ======================================================================== > == > > >>>> > > >>>> > > >>>> [Stefan] But it has to provide a warning to something that is > > >>>> introduced > > >>>> by the standard. This standard does not introduce the concept > of > > CRL > > >>>> signature checking or CRL issuer certificate validation, so > that is > > >>>> clearly out of scope. More about that below; > > >>>> > > >>>> [Denis] See below the last answer and also my arguments in the > > >>>> soon-to-be-posted answer to Russ. > > >>>> > > >>>> > > > ======================================================================== > == > > >>>> > > >>>> > > >>>> > > >>>> > > RFC 3280 [PKIX1] specifies the validation of certification > > paths. > > >>>> > > One aspect involves the determination that a certificate > has > > not > > >>>> been > > >>>> > > revoked, and one revocation checking mechanism is the > > Certificate > > >>>> > > Revocation List (CRL). CRL validation is also specified in > RFC > > >>>> 3280, > > >>>> > > >>>> > I would love this last sentence to be true but the reality is > > that: > > >>>> > "CRL validation is NOT specified in RFC 3280". :-( > > >>>> > > >>>> [Stefan] In fact it is. > > >>>> > > >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: > > >>>> > > >>>> (f) Obtain and validate the certification path for the > complete > > CRL > > >>>> issuer. If a key usage extension is present in the CRL > issuer's > > >>>> certificate, verify that the cRLSign bit is set. > > >>>> > > >>>> (g) Validate the signature on the complete CRL using the > public > > key > > >>>> validated in step (f). > > >>>> > > >>>> [Denis] The text does not say how to obtain and validate the > > >>>> certification path for the complete (???) CRL issuer. The text > is > > >>>> not clear enough so that two implementors only looking at this > > >>>> sentence will provide interoperable implementations. > > >>>> > > >>>> > > > ======================================================================== > == > > >>>> > > >>>> > > >>>> [Stefan] It is my hope that the provided responses here can > help > > >>>> convince you to change your mind about that. If it doesn't I > still > > >>>> argue > > >>>> that the place to specify requirements and security > considerations > > for > > >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL > > draft. > > >>>> > > >>>> [Denis] I can agree with your last sentence, ... which means > that > > it > > >>>> should not be in the main body of the document. In the security > > >>>> considerations section, text is free and we shall at the very > > >>>> minimum warn implementers and we should provide some guidance. > When > > >>>> the same certification path (i.e. the path used to validate the > > >>>> target certificate) is used, then there is no security issue: > this > > >>>> should be said. For all other cases, there MAY be problems: > this > > >>>> should also be said. It is as simple as that. > > >>>> > > >>>> Denis > > >>> > > >> > > >> > > > > > > > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCeuwd070936; Thu, 12 May 2005 05:40:56 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CCeunm070935; Thu, 12 May 2005 05:40:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CCetv4070919 for ; Thu, 12 May 2005 05:40:55 -0700 (PDT) (envelope-from jmdesp@free.fr) Received: from [10.0.0.81] (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft6.fr.colt.net with ESMTP id j4CCenp19895; Thu, 12 May 2005 14:40:50 +0200 Message-ID: <42834ED0.9090306@free.fr> Date: Thu, 12 May 2005 14:40:48 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8b2) Gecko/20050501 MIME-Version: 1.0 To: Hoyt L Kesterson II CC: pkix Subject: Re: Technical Corrigenda 3 to the 4th edition of X.509 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hoyt L Kesterson II wrote: > Some you worked with the X.509 standards committee over the last few > years revising the text on key usage. > > You can find the text of that Technical Corrigenda at: > ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf You should avoid using characters in the filename that are not compatible with the Microsoft OS, it makes it harder to download that file. From the text : "Bits in the KeyUsage type are as follows: [...] c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport; d) dataEncipherment: for enciphering user data, but not keys or other security information as in c) above; e) keyAgreement: for use as a public key agreement key;" It's not yet very precise. The contentCommitment bit text got very clear, so it shows how much we can improve on those bits. The text by Peter is quite good, how about : c) keyEncipherment: for enciphering keys or other security information, e.g. for key transport, and also data encryption that uses an intermediate symmetric cipher; d) dataEncipherment: for directly enciphering raw user data, without the use of an intermediate symmetric cipher e) keyAgreement: for use as a public key agreement key, for example a Diffie-Hellman protocol key; Shouldn't we best find a way to say that an SSL client requires at a minimum only digitalSignature, but the SSL server must have keyEncipherment ? Maybe we should precise : In practice when someone wishes to send enciphered key or security information, he must check that the recipient has the keyEncipherment bit set before using his public key to encipher. For example in an SSL handshake, the client must check that the server has the keyEncipherment bit set before sending him an enciphered secret, but never needs to have that bit set in his own certificate, because the server will use his certificate only for authentification, not to send enciphered data. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CBdO5c050018; Thu, 12 May 2005 04:39:24 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CBdOE2050017; Thu, 12 May 2005 04:39:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CBdNw8049980 for ; Thu, 12 May 2005 04:39:23 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 12:39:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on Date: Thu, 12 May 2005 12:39:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Thread-Index: AcVW20qkEAyEpBkhR1uSL+f+s8bQ/AACcm3A From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: "pkix" X-OriginalArrivalTime: 12 May 2005 11:39:17.0645 (UTC) FILETIME=[3AF44BD0:01C556E7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CBdOw8050011 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, My main comment to this is that there is no exact definition of what is "sufficient" in this case. What is sufficient to you may not be sufficient to me or vice versa. This issue is as many times when security is the issue a tradeoff. In IT security you always have the 3 goals: - Cheep - Easy to use - Secure The sad truth is that we often discover that we can have any 2 of those but never all 3. The fact about name uniqueness you provide in the referenced text is a true facts but it still does not tell me what is sufficient or not in my environment or how I can achieve reasonable security when the trust paths differ (in case they have to). My basic assessment is that there is neither a single truth nor a single solution to the problem. The chaining to a common root was the reasonable recommendation agreed at the San Diego PKIX meeting. This is in my mind not intended to be advertised as a "sufficient" solution, just good practice to reduce the risk of problems. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 12 maj 2005 11:27 > To: Russ Housley > Cc: pkix > Subject: Re: Comments on > > > Russ, > > Since Tim has now made the call at the WG level, please consider this > message as an answer to the call: the current security considerations > section is not acceptable. > > > The document already says that the CA and the CRL issuer need to > > terminate at the same trust anchor. This is the important point. > > I disagree that there is anything else that ought to be said in the > > security considerations. > > This statement still does not answer to the point I raised, but > I will nevertheless answer to your statement. > > The same trust anchor is not a *sufficient* condition. The same node in > the > certification tree is the necessary condition. This implies, of course, > the > same trust anchor, but since two CRL issuers located at different nodes > (i.e. certified by different CAS) might have the same CRL issuer name, > this > condition is insufficient to solve the issue. > > May I recall an extract from the security considerations section of an > approved draft that will be published soon as RFC 4043 ? (this is the > permanent-identifier document): > > Subject names in certificates are chosen by the issuing CA and are > mandated to be unique for each CA; so there can be no name collision > between subject names from the same CA. Such a name may be an end- > entity name when the certificate is a leaf certificate, or a CA > name, > when it is a CA certificate. > > Since a name is only unique towards its superior CA, unless some > naming constraints are being used, a name would only be guaranteed > to > be globally unique when considered to include a sequence of all the > names of the superior CAs. (...) > > Additional checks need to be done, e.g., to check if the public key > values of the two CAs which have issued the certificates to be > compared are identical or if the sequence of CA names in the > certification path from the trust anchor to the CA are identical. > > (...) > > The certification of different CAs with the same DN by different CAs > has other negative consequences in various parts of the PKI, notably > rendering the IssuerAndSerialNumber structure in [RFC3852] section > 10.2.4 ambiguous. > > It speaks for itself, as it applies to CRL Issuers as well. Some parts of > it should indeed be copied and pasted in the security considerations > section > of the current proposed draft. > > When the certification path used to validate the target certificate is > also used to validate the CRL Issuer certificate, then there is no > security > issue: this should be said in the security considerations section. > > What about the other cases ? The other cases belong to the category of > indirect CRLs. Depending on the local validation policy checks done or not > done there may be security issues. > > Denis > > > Russ > > > > At 02:59 AM 5/10/2005, Denis Pinkas wrote: > > > >> Russ, > >> > >> Your statement below is correct, but does not answer to any of my > >> questions/issues. In particular, the last one. I am still awaiting > >> your responses. > >> > >> Denis > >> > >>> Denis: > >>> RFC 3280 does not tell an implementor how for locate certificates > for > >>> any certification path construction. There are several extensions > >>> that provide pointers that may help an implementation, but other > >>> approaches to obtaining the same certificates are always permitted. > >>> I would fully expect an implementation to check any local cache > >>> before accessing a repository. > >>> The CRL AIA extension fits this pattern. A method for locating a > >>> certificate is provided, but any other mechanism for locating the > >>> same certificate is acceptable. > >>> Russ > >>> > >>>> Stefan, > >>>> > >>>> I made the e-mail shorter. Your main arguments are the following: > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> [Stefan] But it has to provide a warning to something that is > >>>> introduced > >>>> by the standard. This standard does not introduce the concept of > CRL > >>>> signature checking or CRL issuer certificate validation, so that is > >>>> clearly out of scope. More about that below; > >>>> > >>>> [Denis] See below the last answer and also my arguments in the > >>>> soon-to-be-posted answer to Russ. > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> > >>>> > > RFC 3280 [PKIX1] specifies the validation of certification > paths. > >>>> > > One aspect involves the determination that a certificate has > not > >>>> been > >>>> > > revoked, and one revocation checking mechanism is the > Certificate > >>>> > > Revocation List (CRL). CRL validation is also specified in RFC > >>>> 3280, > >>>> > >>>> > I would love this last sentence to be true but the reality is > that: > >>>> > "CRL validation is NOT specified in RFC 3280". :-( > >>>> > >>>> [Stefan] In fact it is. > >>>> > >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: > >>>> > >>>> (f) Obtain and validate the certification path for the complete > CRL > >>>> issuer. If a key usage extension is present in the CRL issuer's > >>>> certificate, verify that the cRLSign bit is set. > >>>> > >>>> (g) Validate the signature on the complete CRL using the public > key > >>>> validated in step (f). > >>>> > >>>> [Denis] The text does not say how to obtain and validate the > >>>> certification path for the complete (???) CRL issuer. The text is > >>>> not clear enough so that two implementors only looking at this > >>>> sentence will provide interoperable implementations. > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> [Stefan] It is my hope that the provided responses here can help > >>>> convince you to change your mind about that. If it doesn't I still > >>>> argue > >>>> that the place to specify requirements and security considerations > for > >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL > draft. > >>>> > >>>> [Denis] I can agree with your last sentence, ... which means that > it > >>>> should not be in the main body of the document. In the security > >>>> considerations section, text is free and we shall at the very > >>>> minimum warn implementers and we should provide some guidance. When > >>>> the same certification path (i.e. the path used to validate the > >>>> target certificate) is used, then there is no security issue: this > >>>> should be said. For all other cases, there MAY be problems: this > >>>> should also be said. It is as simple as that. > >>>> > >>>> Denis > >>> > >> > >> > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CBNveA043725; Thu, 12 May 2005 04:23:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4CBNvFT043724; Thu, 12 May 2005 04:23:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4CBNt7X043673 for ; Thu, 12 May 2005 04:23:55 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 12:23:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Structuring Denis issues RE: Comments on Date: Thu, 12 May 2005 12:23:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Structuring Denis issues RE: Comments on Thread-Index: AcVW20qkEAyEpBkhR1uSL+f+s8bQ/AAB8tDw From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: "pkix" X-OriginalArrivalTime: 12 May 2005 11:23:49.0672 (UTC) FILETIME=[11D6DA80:01C556E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4CBNu7X043716 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, The core of your comments are spread over many emails and opinions may have changed on details so I'm not sure I have got the latest picture of your recorded problems and what you propose as resolution. I'm thus trying to summarize the current complete picture of the last call comments below. Please correct me if something is wrong or missing. Note that I'm not arguing here, just trying to structure the issues (I will argue in separate mails). Also note that agreed typos are omitted from the list: 1) Problem: There are SHOULD and MUST requirements in the security considerations section. Proposed resolution: Reword to make sure we don't use SHOULD or MUST in this section. ----- 2) Problem: The security considerations talk about "mitigation" of the name collision problem but gives inadequate advice. Proposed resolution: Either delete all text talking about how to mitigate this problem or provide full guidance on what it takes to guarantee that a CRL Issuer with a matching name actually is the intended CRL Issuer. Also explain that this is not an issue when the CRL Issuer certification path and the target certificate certification path are identical. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: den 12 maj 2005 11:27 > To: Russ Housley > Cc: pkix > Subject: Re: Comments on > > > Russ, > > Since Tim has now made the call at the WG level, please consider this > message as an answer to the call: the current security considerations > section is not acceptable. > > > The document already says that the CA and the CRL issuer need to > > terminate at the same trust anchor. This is the important point. > > I disagree that there is anything else that ought to be said in the > > security considerations. > > This statement still does not answer to the point I raised, but > I will nevertheless answer to your statement. > > The same trust anchor is not a *sufficient* condition. The same node in > the > certification tree is the necessary condition. This implies, of course, > the > same trust anchor, but since two CRL issuers located at different nodes > (i.e. certified by different CAS) might have the same CRL issuer name, > this > condition is insufficient to solve the issue. > > May I recall an extract from the security considerations section of an > approved draft that will be published soon as RFC 4043 ? (this is the > permanent-identifier document): > > Subject names in certificates are chosen by the issuing CA and are > mandated to be unique for each CA; so there can be no name collision > between subject names from the same CA. Such a name may be an end- > entity name when the certificate is a leaf certificate, or a CA > name, > when it is a CA certificate. > > Since a name is only unique towards its superior CA, unless some > naming constraints are being used, a name would only be guaranteed > to > be globally unique when considered to include a sequence of all the > names of the superior CAs. (...) > > Additional checks need to be done, e.g., to check if the public key > values of the two CAs which have issued the certificates to be > compared are identical or if the sequence of CA names in the > certification path from the trust anchor to the CA are identical. > > (...) > > The certification of different CAs with the same DN by different CAs > has other negative consequences in various parts of the PKI, notably > rendering the IssuerAndSerialNumber structure in [RFC3852] section > 10.2.4 ambiguous. > > It speaks for itself, as it applies to CRL Issuers as well. Some parts of > it should indeed be copied and pasted in the security considerations > section > of the current proposed draft. > > When the certification path used to validate the target certificate is > also used to validate the CRL Issuer certificate, then there is no > security > issue: this should be said in the security considerations section. > > What about the other cases ? The other cases belong to the category of > indirect CRLs. Depending on the local validation policy checks done or not > done there may be security issues. > > Denis > > > Russ > > > > At 02:59 AM 5/10/2005, Denis Pinkas wrote: > > > >> Russ, > >> > >> Your statement below is correct, but does not answer to any of my > >> questions/issues. In particular, the last one. I am still awaiting > >> your responses. > >> > >> Denis > >> > >>> Denis: > >>> RFC 3280 does not tell an implementor how for locate certificates > for > >>> any certification path construction. There are several extensions > >>> that provide pointers that may help an implementation, but other > >>> approaches to obtaining the same certificates are always permitted. > >>> I would fully expect an implementation to check any local cache > >>> before accessing a repository. > >>> The CRL AIA extension fits this pattern. A method for locating a > >>> certificate is provided, but any other mechanism for locating the > >>> same certificate is acceptable. > >>> Russ > >>> > >>>> Stefan, > >>>> > >>>> I made the e-mail shorter. Your main arguments are the following: > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> [Stefan] But it has to provide a warning to something that is > >>>> introduced > >>>> by the standard. This standard does not introduce the concept of > CRL > >>>> signature checking or CRL issuer certificate validation, so that is > >>>> clearly out of scope. More about that below; > >>>> > >>>> [Denis] See below the last answer and also my arguments in the > >>>> soon-to-be-posted answer to Russ. > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> > >>>> > > RFC 3280 [PKIX1] specifies the validation of certification > paths. > >>>> > > One aspect involves the determination that a certificate has > not > >>>> been > >>>> > > revoked, and one revocation checking mechanism is the > Certificate > >>>> > > Revocation List (CRL). CRL validation is also specified in RFC > >>>> 3280, > >>>> > >>>> > I would love this last sentence to be true but the reality is > that: > >>>> > "CRL validation is NOT specified in RFC 3280". :-( > >>>> > >>>> [Stefan] In fact it is. > >>>> > >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: > >>>> > >>>> (f) Obtain and validate the certification path for the complete > CRL > >>>> issuer. If a key usage extension is present in the CRL issuer's > >>>> certificate, verify that the cRLSign bit is set. > >>>> > >>>> (g) Validate the signature on the complete CRL using the public > key > >>>> validated in step (f). > >>>> > >>>> [Denis] The text does not say how to obtain and validate the > >>>> certification path for the complete (???) CRL issuer. The text is > >>>> not clear enough so that two implementors only looking at this > >>>> sentence will provide interoperable implementations. > >>>> > >>>> > ======================================================================== == > >>>> > >>>> > >>>> [Stefan] It is my hope that the provided responses here can help > >>>> convince you to change your mind about that. If it doesn't I still > >>>> argue > >>>> that the place to specify requirements and security considerations > for > >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL > draft. > >>>> > >>>> [Denis] I can agree with your last sentence, ... which means that > it > >>>> should not be in the main body of the document. In the security > >>>> considerations section, text is free and we shall at the very > >>>> minimum warn implementers and we should provide some guidance. When > >>>> the same certification path (i.e. the path used to validate the > >>>> target certificate) is used, then there is no security issue: this > >>>> should be said. For all other cases, there MAY be problems: this > >>>> should also be said. It is as simple as that. > >>>> > >>>> Denis > >>> > >> > >> > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9qvQ6006874; Thu, 12 May 2005 02:52:57 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9qvCk006873; Thu, 12 May 2005 02:52:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9qtYe006831 for ; Thu, 12 May 2005 02:52:56 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 10:52:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Typo in Date: Thu, 12 May 2005 10:52:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Typo in Thread-Index: AcVW1zet5QWtTlXUQOKcWj4FUUU00QAAQuGQ From: "Stefan Santesson" To: "Denis Pinkas" , "Russ Housley" Cc: X-OriginalArrivalTime: 12 May 2005 09:52:50.0270 (UTC) FILETIME=[5BC837E0:01C556D8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C9quYe006865 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks Denis, Typo noted and will be corrected Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 12 maj 2005 11:45 > To: Russ Housley; Stefan Santesson > Cc: ietf-pkix@imc.org > Subject: Typo in > > Please correct this typo: > > AccessDescription specifying id-ad-caIssuers as the acessMethod > ^^ > > > Denis > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9iUN5003789; Thu, 12 May 2005 02:44:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9iUOf003787; Thu, 12 May 2005 02:44:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9iSlT003743 for ; Thu, 12 May 2005 02:44:29 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA42990; Thu, 12 May 2005 11:59:16 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051211441863:976 ; Thu, 12 May 2005 11:44:18 +0200 Message-ID: <428325AC.40803@bull.net> Date: Thu, 12 May 2005 11:45:16 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley , Stefan Santesson CC: ietf-pkix@imc.org Subject: Typo in References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:44:18, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:44:19, Serialize complete at 12/05/2005 11:44:19 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Please correct this typo: AccessDescription specifying id-ad-caIssuers as the acessMethod ^^ Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9fk8c002777; Thu, 12 May 2005 02:41:46 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9fkOo002776; Thu, 12 May 2005 02:41:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9fii8002735 for ; Thu, 12 May 2005 02:41:45 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA30866; Thu, 12 May 2005 11:56:34 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051211413567:975 ; Thu, 12 May 2005 11:41:35 +0200 Message-ID: <42832509.5020001@bull.net> Date: Thu, 12 May 2005 11:42:33 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org Subject: Re: Comments on References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:41:35, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:41:37, Serialize complete at 12/05/2005 11:41:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, > Denis: >>> Yes, it is OBVIOUS that the CRL issuer certificate needs to be >>> validated. >>> You say that it is not clear what validation policy needs to be used, >>> but this is completely irrelevant to the discussion of the CRL AIA >>> extension. This extension aid in certification path construction, >>> not the validation of the path once it is constructed. >> Not exactly, it could "help" finding a wrong path ! > Not likely. The signer of the CRL is providing a pointer to their own > certificate. Path construction to locate a parent of that certificate > through a complex PKI might include paths that are acceptable and paths > that are unacceptable, but the certificate that contains the public key > needed to validate the signature on the CRL is clearly needed. The problem is to know if a CRL that has been fetched "somewhere" is adequate for the target certificate. It is not to validate a CRL that has been fetched "somewhere". >>> There are many factors which need to be considered in the validation >>> of the CRL issue certificate. The values of the key usage extension >>> and the certificate policies extension are two that jump to mind. >>> There are probably more if I spend the time to consider each possible >>> scenario. >> One simple rule would allow no security problem at all and I wonder >> why you have so much resistance to mention it. > We have that rule: The CA certificate and the CRL Issuer certificate > must validate back to the same trust anchor. As explained in a just posted e-mail this rule is insufficient and thus insecure. >>> In my opinion, this document is ready for WG Last Call. >> >> >> As an editor of the draft, I may understand your position; but it is >> up the the PKIX chairs to decide whether or not the document is ready >> for WG last call. > Correct. I included this sentence for the WG chairs. I hope they will > agree with me, and that they will issue WG Last Call for this document. >> Once again the current Security Considerations section is not acceptable. > To you... No one else is advocating this change. I continue to believe > that requiring the CA certificate and the CRL Issuer certificate to > validate back to the same trust anchor resolves your concern. It does not. > I am > willing to add a few words to the security considerations about name > collisions (my co-author may disagree), but I am not willing to use > "MUST" or "SHOULD" in those words. We agree that "MUST" or "SHOULD" should not be used in the security considerations section. > There is absolutely nothing that a > client can do to determine deal with name collisions that are > subordinate to the same trust anchor. This last statement is wrong. Please look again at the security considerations section of "Permanent Identifier". As an example: "Since a name is only unique towards its superior CA, unless some naming constraints are being used, a name would only be guaranteed to be globally unique when considered to include a sequence of all the names of the superior CAs". Denis > Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9Q35C096521; Thu, 12 May 2005 02:26:03 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9Q3l3096520; Thu, 12 May 2005 02:26:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9Q0AL096442 for ; Thu, 12 May 2005 02:26:01 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA27662; Thu, 12 May 2005 11:40:43 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051211254571:969 ; Thu, 12 May 2005 11:25:45 +0200 Message-ID: <42832153.8000802@bull.net> Date: Thu, 12 May 2005 11:26:43 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: pkix Subject: Re: Comments on References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:25:45, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:25:47, Serialize complete at 12/05/2005 11:25:47 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Since Tim has now made the call at the WG level, please consider this message as an answer to the call: the current security considerations section is not acceptable. > The document already says that the CA and the CRL issuer need to > terminate at the same trust anchor. This is the important point. > I disagree that there is anything else that ought to be said in the > security considerations. This statement still does not answer to the point I raised, but I will nevertheless answer to your statement. The same trust anchor is not a *sufficient* condition. The same node in the certification tree is the necessary condition. This implies, of course, the same trust anchor, but since two CRL issuers located at different nodes (i.e. certified by different CAS) might have the same CRL issuer name, this condition is insufficient to solve the issue. May I recall an extract from the security considerations section of an approved draft that will be published soon as RFC 4043 ? (this is the permanent-identifier document): Subject names in certificates are chosen by the issuing CA and are mandated to be unique for each CA; so there can be no name collision between subject names from the same CA. Such a name may be an end- entity name when the certificate is a leaf certificate, or a CA name, when it is a CA certificate. Since a name is only unique towards its superior CA, unless some naming constraints are being used, a name would only be guaranteed to be globally unique when considered to include a sequence of all the names of the superior CAs. (...) Additional checks need to be done, e.g., to check if the public key values of the two CAs which have issued the certificates to be compared are identical or if the sequence of CA names in the certification path from the trust anchor to the CA are identical. (...) The certification of different CAs with the same DN by different CAs has other negative consequences in various parts of the PKI, notably rendering the IssuerAndSerialNumber structure in [RFC3852] section 10.2.4 ambiguous. It speaks for itself, as it applies to CRL Issuers as well. Some parts of it should indeed be copied and pasted in the security considerations section of the current proposed draft. When the certification path used to validate the target certificate is also used to validate the CRL Issuer certificate, then there is no security issue: this should be said in the security considerations section. What about the other cases ? The other cases belong to the category of indirect CRLs. Depending on the local validation policy checks done or not done there may be security issues. Denis > Russ > > At 02:59 AM 5/10/2005, Denis Pinkas wrote: > >> Russ, >> >> Your statement below is correct, but does not answer to any of my >> questions/issues. In particular, the last one. I am still awaiting >> your responses. >> >> Denis >> >>> Denis: >>> RFC 3280 does not tell an implementor how for locate certificates for >>> any certification path construction. There are several extensions >>> that provide pointers that may help an implementation, but other >>> approaches to obtaining the same certificates are always permitted. >>> I would fully expect an implementation to check any local cache >>> before accessing a repository. >>> The CRL AIA extension fits this pattern. A method for locating a >>> certificate is provided, but any other mechanism for locating the >>> same certificate is acceptable. >>> Russ >>> >>>> Stefan, >>>> >>>> I made the e-mail shorter. Your main arguments are the following: >>>> >>>> ========================================================================== >>>> >>>> >>>> [Stefan] But it has to provide a warning to something that is >>>> introduced >>>> by the standard. This standard does not introduce the concept of CRL >>>> signature checking or CRL issuer certificate validation, so that is >>>> clearly out of scope. More about that below; >>>> >>>> [Denis] See below the last answer and also my arguments in the >>>> soon-to-be-posted answer to Russ. >>>> >>>> ========================================================================== >>>> >>>> >>>> >>>> > > RFC 3280 [PKIX1] specifies the validation of certification paths. >>>> > > One aspect involves the determination that a certificate has not >>>> been >>>> > > revoked, and one revocation checking mechanism is the Certificate >>>> > > Revocation List (CRL). CRL validation is also specified in RFC >>>> 3280, >>>> >>>> > I would love this last sentence to be true but the reality is that: >>>> > "CRL validation is NOT specified in RFC 3280". :-( >>>> >>>> [Stefan] In fact it is. >>>> >>>> RFC 3280, Section 6.3.3 CRL processing - on page 85: >>>> >>>> (f) Obtain and validate the certification path for the complete CRL >>>> issuer. If a key usage extension is present in the CRL issuer's >>>> certificate, verify that the cRLSign bit is set. >>>> >>>> (g) Validate the signature on the complete CRL using the public key >>>> validated in step (f). >>>> >>>> [Denis] The text does not say how to obtain and validate the >>>> certification path for the complete (???) CRL issuer. The text is >>>> not clear enough so that two implementors only looking at this >>>> sentence will provide interoperable implementations. >>>> >>>> ========================================================================== >>>> >>>> >>>> [Stefan] It is my hope that the provided responses here can help >>>> convince you to change your mind about that. If it doesn't I still >>>> argue >>>> that the place to specify requirements and security considerations for >>>> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. >>>> >>>> [Denis] I can agree with your last sentence, ... which means that it >>>> should not be in the main body of the document. In the security >>>> considerations section, text is free and we shall at the very >>>> minimum warn implementers and we should provide some guidance. When >>>> the same certification path (i.e. the path used to validate the >>>> target certificate) is used, then there is no security issue: this >>>> should be said. For all other cases, there MAY be problems: this >>>> should also be said. It is as simple as that. >>>> >>>> Denis >>> >> >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9NDlB095459; Thu, 12 May 2005 02:23:13 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C9NDdO095458; Thu, 12 May 2005 02:23:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C9NBhk095409 for ; Thu, 12 May 2005 02:23:11 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA36536; Thu, 12 May 2005 11:37:59 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051211230124:968 ; Thu, 12 May 2005 11:23:01 +0200 Message-ID: <428320AE.5080809@bull.net> Date: Thu, 12 May 2005 11:23:58 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: David Cross CC: pkix Subject: Re: Comments on References: <3C69AE30038D9A4590F5EC20DCD41F680665BB8F@RED-MSG-41.redmond.corp.microsoft.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:23:01, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 12/05/2005 11:23:02, Serialize complete at 12/05/2005 11:23:02 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, Since Tim has now made the call at the WG level, please consider this message as an answer to the call. > Denis: > I have to disagree on removal of the text. I have not seen any > objections from the list or working group to this inclusion. I have to > disagree with your assertion that removing the text is a more secure > recommendation. The below text (slightly edited to my taste) is an > excellent recommendation from an implementation standoint and a security > consideration. You are using the wording "excellent" but as it will be demonstrated this is far from excellent. > I would personally concede that using MUST *may* be > incorrect here and a SHOULD *may* be more appropriate. Fine. > As a means of mitigating implementation challenges and security > issues related to issuer name collisions, CA names SHOULD be > formed in such a way that reduce the likelihood of name collisions. The word "mitigating" is used: it already indicates that it is not a secure solution. While this recommendation is wise, nothing forces CA to follow it. So the question is : what would happen if a CA name is formed in such a way that there is a name collision ? Relying parties cannot base their security on this "SHOULD requirement". So this does not suppress the issue: this should clearly be said that this is not a solution. > Implementations validating CRLs SHOULD ensure that the certification > path of the target certificate and the CRL issuer certification path > used to validate the target certificate, terminate at a common trust > anchor. This does not solve the issue either. Under the same trust anchor there may be a tree with many branches and leaves, nothing prevents two CRL Issuers to have the same name. For this reason the proposed text is inappropriate. Denis > David B. Cross > > > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of Denis Pinkas > Sent: Tuesday, May 10, 2005 12:01 AM > To: Russ Housley > Cc: ietf-pkix@imc.org > Subject: Re: Comments on > > > Russ, > > >>Denis: >> >>Yes, it is OBVIOUS that the CRL issuer certificate needs to be > > validated. > >>You say that it is not clear what validation policy needs to be used, >>but this is completely irrelevant to the discussion of the CRL AIA >>extension. This extension aid in certification path construction, not > > >>the validation of the path once it is constructed. > > > Not exactly, it could "help" finding a wrong path ! > > >>There are many factors which need to be considered in the validation >>of the CRL issue certificate. The values of the key usage extension >>and the certificate policies extension are two that jump to mind. >>There are probably more if I spend the time to consider each possible > > scenario. > > One simple rule would allow no security problem at all and I wonder why > you have so much resistance to mention it. > > >>In my opinion, this document is ready for WG Last Call. > > > As an editor of the draft, I may understand your position; but it is up > the the PKIX chairs to decide whether or not the document is ready for > WG last call. > > Once again the current Security Considerations section is not > acceptable. > In particular it contains a "MUST" statement that cannot be placed in > such a section and which is in addition fully wrong. > > Hereabove is the last one from draft 01: > > 3 Security Considerations > > Implementers should take into account the possible existence of > multiple unrelated CAs and CRL issuers with the same name. As > means of reducing problems and security issues related to issuer > name collisions, CA names SHOULD be formed in a way that reduce > the > likelihood of name collisions. Implementations validating CRLs > MUST ensure that the certification path of the target certificate > and the CRL issuer certification path used to validate the target > certificate, terminate at the same trust anchor. > > Implementers should be aware of risks involved if the Authority > Information Access extensions of corrupted CRLs contain links to > malicious code. Implementers should always take the steps of > validating the retrieved data to ensure that the data is properly > formed. > > Hereafter is a "minimalist" rewriting of this section, if we take the > choice to mention the issue, but not to provide any secure solution > (mentioning insecure or insufficient solutions is not appropriate). Two > sentences have thus been deleted. > > 3 Security Considerations > > Implementers should take into account the possible existence of > multiple unrelated CAs and CRL issuers with the same name. > > Implementers should be aware of risks involved if the Authority > Information Access extensions of corrupted CRLs contain links to > malicious code. Implementers should always take the steps of > validating the retrieved data to ensure that the data is properly > formed. > > Denis > > > >>Russ >> >> >>At 09:07 AM 5/9/2005, Denis Pinkas wrote: >> >> >>>Russ, >>> >>> >>>>Here is a quote from RFC 3280. To me, it is clear that a CRL >>>>issuer >>> >>>has >>> >>>>a certificate. >>> >>>True, a CRL issuer (that is different from the CA that has issued the >> > >>>target >>>certificate) has a certificate. So we both strongly agree on this >>>this. :-) >>> >>> >>>>Obviously, all certificates need to be validated, which includes >>>>certification path construction and certification path >>> >>>validation. >>> >>>When a sentence starts with "Obviously", it means that it is not so >>>obvious. >>>:-| >>> >>>The real question is whether the CRL issuer certificate has to be >>>verified using rules (i.e. a validation policy) which are independent >> > >>>from the certification path construction of the target certificate. >>>RFC 3280 does not provide a crystal clear answer to that question. >>> >>>If the rules are different, then you MAY end up with a security issue >> > >>>(see my previous explanations). The current "recommendations" that >>>are in the security considerations section do NOT solve this issue in >> > >>>the general case. >>> >>>If the rules are the same, i.e. the path used to validate the >>>certification path from the certificate are also used, then there is >>>no security issue. >>> >>>I do not think it would be good to hide this issue in the proposed >> > draft. > >>>Anyway, the current "recommendations" do NOT solve the issue and are >>>thus not acceptable and so this section cannot stand as it is. >>> >>>Denis >>> >>> >>>>5.1.1.3 signatureValue >>>> >>>> The signatureValue field contains a digital signature computed >>> > upon > >>>> the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded >>> >>>tbsCertList >>> >>>> is used as the input to the signature function. This signature >>> >>>value >>> >>>> is encoded as a BIT STRING and included in the CRL >>> > signatureValue > >>>> field. The details of this process are specified for each of >>> > the > >>>> supported algorithms in [PKIXALGS]. >>>> >>>> CAs that are also CRL issuers MAY use one private key to >>> > digitally > >>>> sign certificates and CRLs, or MAY use separate private keys to >>>> digitally sign certificates and CRLs. When separate private >>>>keys >>> >>>are >>> >>>> employed, each of the public keys associated with these private >>> > keys > >>>> is placed in a separate certificate, one with the keyCertSign >>>>bit >>> >>>set >>> >>>> in the key usage extension, and one with the cRLSign bit set in >>> > the > >>>> key usage extension (section 4.2.1.3). When separate private >>> > keys > >>>> are employed, certificates issued by the CA contain one >>>>authority >>> >>>key >>> >>>> identifier, and the corresponding CRLs contain a different >>> > authority > >>>> key identifier. The use of separate CA certificates for >>> > validation > >>>> of certificate signatures and CRL signatures can offer improved >>>> security characteristics; however, it imposes a burden on >>>> applications, and it might limit interoperability. Many >>> >>>applications >>> >>>> construct a certification path, and then validate the >>> > certification > >>>> path (section 6). CRL checking in turn requires a separate >>>> certification path to be constructed and validated for the CA's >>> > CRL > >>>> signature validation certificate. Applications that perform CRL >>>> checking MUST support certification path validation when >>> >>>certificates >>> >>>> and CRLs are digitally signed with the same CA private key. >>> > These > >>>> applications SHOULD support certification path validation when >>>> certificates and CRLs are digitally signed with different CA >>> > private > >>>> keys. >>>> >>>>Russ >>>> >>>>At 01:12 PM 4/28/2005, Denis Pinkas wrote: >>>> >>>> >>>>>Stefan and Russ, >>>>> >>>>> >>>>>>Denis, >>>>> >>>>> >>>>>>Russ and I have taken a thorough look at your text proposal and >>>>>>we >>>>> >>>have >>> >>>>>>edited a counter proposal where we try to meet your needs as much >>>>> > >>>>>>as possible without compromising what we think is the core >>>>>>purpose of >>>>> >>>the >>> >>>>>>draft (to enable certificate discovery bottom-up). >>>>> >>>>> >>>>>>The conclusion is that we suggest changes to the introduction >>>>>>section but we keep the old security considerations intact. >>>>> >>>>> >>>>>I would suggest that a merge would need to be done between the >>>> > "old" > >>>>>security considerations section and the "new" one. >>>>> >>>>>The "old" security considerations section is mentionning a >>>>>solution which does NOT suppress the problem, but minimize the >>>>>risk only in case the CAs are really "honest". >>>>> >>>>>The old" security considerations section does not provide a >>>>>solution in case the name collsion between two CRL issuer name is >>>>>deliberate, whereas the "new" security considerations section >>>>>provides a secure solution in one case and clearly mentions that >>>>>all other cases are dependant about "zillions" of *local* trust >>>>>conditions which cannot all be standardized. >>>>> >>>>>The main purpose of a security considerations section is to >>>>>provide the adequate warnings and solutions when they exist and >>>>>not to hide the problems. >>>>> >>>>> >>>>>>That is not because >>>>>>we necessarily disagree with all of the statements in your >>>>> >>>proposal, but >>> >>>>>>in the cases we don't, we still think it is out of scope for this >>>>> >>>work. >>> >>>>> >>>>>This is clearly within the scope of a security considerations >>>> > section. > >>>>>>The new introduction proposal based on your input is: >>>>>>-------------------------------------------------------------- >>>>>>RFC 3280 [PKIX1] specifies the validation of certification paths. >>>>> > >>>One >>> >>>>>>aspect involves the determination that a certificate has not been >>>>> > >>>>>>revoked, and one revocation checking mechanism is the Certificate >>>>> > >>>>>>Revocation List (CRL). CRL validation is also specified in RFC >>>>>>3280, >>>>> >>>>> >>>>>I would love this last sentence to be true but the reality is >>>> > that: > >>>>>"CRL validation is NOT specified in RFC 3280". :-( >>>>> >>>>> >>>>>>which involves the constructions of a valid certification path >>>>>>for >>>>> >>>the >>> >>>>>>CRL issuer. >>>>> >>>>> >>>>>There is no such a statement in RFC 3280. >>>>> >>>>> >>>>>>Building a CRL issuer certification path from the signer of >>>>> >>>>> >>>>>There is no notion of "CRL issuer certification path" in RFC 3280. >>>>>The primary requirement is to make sure that the CRL issuer >>>>>designated by the CA is indeed the right one. In some (but not >>>>>all) cases, I mean among the zillion of cases, there MAY be a need >>>> > >>>>>to construct a CRL issuer certification path. >>>>> >>>>> >>>>>>the CRL to a trust anchor is straightforward when the certificate >>>>> >>>of the >>> >>>>>>CRL issuer is present in the certification path associated with >>>>>>the target certificate, but it can be complex in other >>>>> > situations. > >>>>> >>>>>From the comments above, you can see that I cannot agree with the >>>>>above revised text. The remaining of the text is acceptable in >>>>>general, but could possibly be slightly revised to be more in >>>>>continuation with the changes there are needed above (i.e. it is >>>>>not cast in concrete). >>>>> >>>>>Denis >>>>> >>>>> >>>>>>There are several legitimate scenarios where the certificate of >>>>> >>>the CRL >>> >>>>>>issuer is not present, or easily discovered, from the target >>>>>>certification path. This can be the case when indirect CRLs are >>>>> >>>used, >>> >>>>>>when the certification Authority (CA) that issued the target >>>>> >>>certificate >>> >>>>>>changes its certificate signing key, or when the CA employs >>>>>>separate keys for certificate signing and CRL signing. >>>>>>Methods of finding the certificate of the CRL issuer are >>>>>>currently available, such as though an accessible directory >>>>>>location or through use of the Subject Information Access >>>>>>extension in intermediary CA certificates. >>>>>>Directory lookup requires existence and access to a directory >>>>>>that >>>>> >>>has >>> >>>>>>been populated with all of the necessary certificates. The >>>>>>Subject Information Access extension, which supports building the >>>>> > >>>>>>CRL issuer certification path top-down (in the direction from the >>>>> > >>>>>>trust >>>>> >>>anchor to >>> >>>>>>the CRL issuer), requires that some certificates in the CRL >>>>>>issuer certification path includes an appropriate Subject >>>>>>Information Access extension. >>>>>>RFC 3280 [PKIX1] provides for bottom-up discovery of >>>>>>certification >>>>> >>>paths >>> >>>>>>through the Authority Information Access extension, where the >>>>>>id-ad-caIssuers access method may specify one or more >>>>>>accessLocation fields that reference CA certificates associated >>>>>>with the certificate containing this extension. >>>>>>This document enables the use of the Authority Information Access >>>>> > >>>>>>extension in CRLs, enabling a CRL checking application to use the >>>>> >>>access >>> >>>>>>method (id-ad-caIssuers) to locate certificates that may be >>>>>>useful in the construction of a valid CRL issuer certification >>>>>>path to an appropriate trust anchor. >>>>>> >>>>>>Stefan Santesson >>>>>>Program Manager, Standards Liaison Windows Security >>>>>> >>>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>>>>>>Sent: den 18 april 2005 13:41 >>>>>>>To: Stefan Santesson >>>>>>>Cc: Russ Housley; pkix >>>>>>>Subject: Re: Comments on >>>>>>> >>>>>>>Stefan, >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Denis, >>>>>>> >>>>>>> >>>>>>>>I will come back and comment on your text proposals, but before >>>>>>> >>>>>>that, >>>>>> >>>>>> >>>>>>>>a few questions/comments: >>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>You point out some well known issues related to the lack of >>>>>>>>> >>>>>>absolute >>>>>> >>>>>> >>>>>>>>>>cryptographic binding between CRL and certificates where the >>>>>>>>>>certificate and CRL is not signed by the same key. >>>>>>>>> >>>>>>>>> >>>>>>>>>Not really. It is indeed possible to have an absolute >>>>>>>> >>>cryptographic >>> >>>>>>>>>binding between CRL and certificates where the certificate and >>>>>>>> > CRL > >>>>>>is >>>>>> >>>>>> >>>>>>>not >>>>>>> >>>>>>> >>>>>>>>>signed by the same key, but the key point is that proposed >>>>>>>> >>>>>>extension >>>>>> >>>>>> >>>>>>>>>is *not* the means to provide such a binding (and you agree >>>>>>>> > with > >>>>>>this >>>>>> >>>>>> >>>>>>>>>further down in this e-mail). >>>>>>>> >>>>>>> >>>>>>>>We agree that this extension does not add to the concept of >>>>>>>>cryptographic binding. But how do you mean it can be done? >>>>>>> >>>>>>> >>>>>>>Would this mean that you believed this could not be done ? :-) >>>>>>> >>>>>>>I already provided the information, but since at that time you >>>>>> > were > >>>>>>>focussing on another issue, you probably missed the point. >>>>>>> >>>>>>>I would encourage you to read again that thread, but I will >>>>>> >>>provide a >>> >>>>>>>short >>>>>>>reply here to your question. >>>>>>> >>>>>>>This can be done using cRLIssuer from the CRL DP. cRLIssuer >>>>>> > contains > >>>>>>the >>>>>> >>>>>> >>>>>>>DN >>>>>>>of the CRL Issuer and we all know that CAs are free to assign >>>>>> > the > >>>DNs >>> >>>>>>they >>>>>> >>>>>> >>>>>>>wish. The next point is for a verifier to make sure that the DN >>>>>> >>>which >>> >>>>>>>identifies the CRL Issuer (in the CRL DP) is indeed the one that >>>>>> > was > >>>>>>meant >>>>>> >>>>>> >>>>>>>by the CA. The CRL must be issued by a CRL Issuer that has the >>>>>> > same > >>>>>>DN. >>>>>> >>>>>> >>>>>>>The >>>>>>>CRL Issuer will have a certificate issued by a CA. >>>>>>> >>>>>>>Case a): the CA that has issued that certificate is the same as >>>>>> >>>the CA >>> >>>>>>>that >>>>>>>has issued the target certificate (which contains the hereabove >>>>>> >>>>>>mentionned >>>>>> >>>>>> >>>>>>>CRL DP). This is easy to check for a verifier since the verifier >>>>>> > >>>must >>> >>>>>>>first >>>>>>>build the certification path and then test the revocation status >>>>>> > of > >>>>>>every >>>>>> >>>>>> >>>>>>>element of the path. So the verifier knows the validated >>>>>> > sequence of > >>>>>>DNs >>>>>> >>>>>> >>>>>>>starting from a self-signed certificate. It must then use the >>>>>> > same > >>>>>>>sequence >>>>>>>of DNs to validate the CRL Issuer certificate. >>>>>>> >>>>>>>This is a general rule which does not require any extra local >>>>>> > trust > >>>>>>>information. >>>>>>> >>>>>>>Case b) : the CA that has issued that certificate is NOT the >>>>>> > same as > >>>>>>the >>>>>> >>>>>> >>>>>>>CA >>>>>>>that has issued the target certificate. This case requires extra >>>>>> >>>>>>*0local* >>>>>> >>>>>> >>>>>>>trust information. There are many such trust conditions possible >>>>>> > and > >>>>>>thus >>>>>> >>>>>> >>>>>>>this cannot be defined in general. Cases a) and b) are thus not >>>>>> >>>>>>equivalent >>>>>> >>>>>> >>>>>>>and have to be distinguished. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>This draft only introduces a new way to locate certificates >>>>>>>>>>that can be helpful in building this path. >>>>>>>>> >>>>>>>>> >>>>>>>>>At least one sentence of which we both agree ! >>>>>>>>>It should be copied and pasted in the abstract. >>>>>>>> >>>>>>>> >>>>>>>>Good, then I suggest that we leave unrelated topics out of this >>>>>>> >>>>>>draft >>>>>> >>>>>> >>>>>>>>and focus on the issues that are related to this limited scope. >>>>>>> >>>>>>> >>>>>>>This is what I did in my proposal, except that we need to have a >>>>>> >>>>>>security >>>>>> >>>>>> >>>>>>>considerations section and the goal of that section is not to >>>>>> > hide > >>>>>>>problems >>>>>>>but to correctly warn users. Thus why an informatiove annex on >>>>>> > the > >>>>>>topics >>>>>> >>>>>> >>>>>>>mentionned in the security considerations section would be quite >>>>>> >>>>>>useful. >>>>>> >>>>>> >>>>>>>In fact, its content would be along the lines of the >>>>>> > explanations > >>>>>>which >>>>>> >>>>>> >>>>>>>are >>>>>>>just above. >>>>>>> >>>>>>>I hope this e-mail will help us to progress. >>>>>>> >>>>>>>Denis >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Stefan Santesson >>>>>>>>Program Manager - Standards Liaison >>>>>>>>Windows Security >>>>>>> >>>>> >>>> >>> >>> >> > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C8tLCB084393; Thu, 12 May 2005 01:55:21 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C8tLeP084392; Thu, 12 May 2005 01:55:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth04.mail.atl.earthlink.net (smtpauth04.mail.atl.earthlink.net [209.86.89.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C8tK5J084383 for ; Thu, 12 May 2005 01:55:20 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.3]) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DW9TU-0005Td-0m; Thu, 12 May 2005 04:55:20 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:Date:To:From:Subject:Content-Type; b=UKfSvuhS7GB/BmzmmtG0G6YGXwXHboxCRsvY77eKuO7b0ZdGAKsYYZIVV2wuws7K; Mime-Version: 1.0 Message-Id: Date: Thu, 12 May 2005 01:51:24 -0700 To: "X.509":; From: Hoyt L Kesterson II Subject: Technical Corrigenda 3 to the 4th edition of X.509 Content-Type: text/html; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47874241ab66785ff6d62eb916411cfa52e56294888860517e9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Technical Corrigenda 3 to the 4th edition of X.509
Some you worked with the X.509 standards committee over the last few years revising the text on key usage.

The Technical Corrigenda containing that revised text was approved and is currently being incorporated into the 5th edition currently being prepared.

You can find the text of that Technical Corrigenda at:

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC3(4th).pdf

Note that this document is written as a set of editing instructions to integrate the text into the 4th edition. If you prefer to wait, the 5th edition will be published before the end of the year

   hoyt
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C8tKVd084380; Thu, 12 May 2005 01:55:20 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C8tKYq084379; Thu, 12 May 2005 01:55:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth04.mail.atl.earthlink.net (smtpauth04.mail.atl.earthlink.net [209.86.89.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C8tJci084369 for ; Thu, 12 May 2005 01:55:19 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.3]) by smtpauth04.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DW9TS-0005Td-F2; Thu, 12 May 2005 04:55:18 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:Date:To:From:Subject:Content-Type; b=QtwUZIeb55fvwiKyIdax+s9va2hbpoFGh3LQ0B8rDuGUo/kE9yMvRmuJTS+3yoIq; Mime-Version: 1.0 Message-Id: Date: Thu, 12 May 2005 01:54:12 -0700 To: "X.509":; From: Hoyt L Kesterson II Subject: the certificate enhancement DAM Content-Type: text/html; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47874241ab66785ff6d4117eb27ee25f1d6629cc9cca95413eb350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: the certificate enhancement DAM
The directory group has completed work on a new amendment to the standard. That amendment is currently being integrated, along with approved TCs, into the 5th edition of the standard. That edition will be published before the end of the year.

The amendment can be found at

  ftp://ftp.bull.com/pub/OSIdirectory/Orlando2004Output/6N12793CertificateEnhancementDAM.pdf

        hoyt
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C5XlVc098236; Wed, 11 May 2005 22:33:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C5XlSU098235; Wed, 11 May 2005 22:33:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C5XivN098178 for ; Wed, 11 May 2005 22:33:45 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4C5XHgw002099; Thu, 12 May 2005 13:33:17 +0800 Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4C5XAcp030585; Thu, 12 May 2005 13:33:11 +0800 Message-ID: <01a701c556b4$1987f650$4f85900a@wcwang> From: "Wen-Cheng Wang" To: "Peter Gutmann" , , Cc: References: Subject: Re: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 13:33:10 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, I think your clarification about the distinction between the keyEncipherment bit and the dataEncipherment bit is good. It would be better if RFC 3280 and X.509 could revise the explanation of the dataEncipherment bit based on your clarification. However, I worried that the statement "This (dataEncipherment) bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data" might mislead the reader to believe that the keyEncipherment bit and the dataEncipherment bit are mutually exclusive. Therefore, I suggest to revise the statement as "The dataEncipherment bit should not be use to represent the intention of allowing enciphering intermediate cryptographic keys. In that case, the keyEncipherment bit should be set." Wen-Cheng Wang ----- Original Message ----- From: "Peter Gutmann" To: ; ; ; Cc: Sent: Wednesday, May 11, 2005 5:39 PM Subject: Re: key usage - key encipherment or data encipherment > > "Wen-Cheng Wang" writes: > >>It is better to clarify that it is legitimate to assert both the >>keyEncipherment bit and the dataEncipherment bit in one certificate. In that >>case, it means that the key (e.g., RSA key) may be used for enciphering >>intermediate cryptographic keys or directly enciphering raw user data (e.g., >>user password). > > Saying you can use both bits won't help, it still leaves it ambiguous to users > as to what dataEncipherment should be used for. One interpretation I've heard > of is keyEncipherment = exchange of session keys (SSL), dataEncipherment = > data encryption (S/MIME). > > Peter. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C5AZiS084744; Wed, 11 May 2005 22:10:35 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C5AZt3084743; Wed, 11 May 2005 22:10:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C5AXml084687 for ; Wed, 11 May 2005 22:10:34 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4C5AJWM032266; Thu, 12 May 2005 13:10:19 +0800 Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4C5AJX5015110; Thu, 12 May 2005 13:10:19 +0800 Message-ID: <013201c556b0$e4469170$4f85900a@wcwang> From: "Wen-Cheng Wang" To: "Russ Housley" Cc: References: <019e01c555fd$b35a8cf0$4f85900a@wcwang> <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com> Subject: Re: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 13:10:18 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Yes, RFC 3280 is quite clear for that. However, I worried that the discussions of this thread might mislead the participants into believing that the two bits are mutually exclusive. Therefore, I simply want to remind the participants of this thread the fact that the keyEncipherment bit and dataEncipherment bit can work well togethor. Wen-Cheng Wang ----- Original Message ----- From: "Russ Housley" To: "Wen-Cheng Wang" Cc: Sent: Wednesday, May 11, 2005 11:40 PM Subject: Re: key usage - key encipherment or data encipherment >I believe that RFC 3280 is quite clear that more than one of these bits can > be set. It says: > > This profile does not restrict the combinations of bits that may be > set in an instantiation of the keyUsage extension. However, > appropriate values for keyUsage extensions for particular algorithms > are specified in [PKIXALGS]. > > Russ > > At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: > > >>Peter Gutmann wrote: >>>Andrew Sciberras writes: >>> >>>> The keyEncipherment bit is asserted when the subject public key is >>>> used for key transport. For example, when an RSA key is to be >>>> used for key management, then this bit shall asserted. >>>> >>>> The dataEncipherment bit is asserted when the subject public key >>>> is used for enciphering user data, other than cryptographic keys. >>>Quoting that won't help (I've seen this sort of thing before) because as far >>>as the user is concerned what's being encrypted is data, so the valid bit to >>>use is dataEncipherment (quite logical to them). What might help is to make >>>this more explicit in the text: >>> The dataEncipherment bit is asserted when the subject public key is >>> used for >>> directly enciphering raw user data without the use of an intermediate >>> symmetric cipher. This bit MUST NOT be set when the intention is to >>> encipher intermediate cryptographic keys rather than raw user data. >>It is better to clarify that it is legitimate to assert both the >>keyEncipherment bit >>and the dataEncipherment bit in one certificate. In that case, it means >>that the >>key (e.g., RSA key) may be used for enciphering intermediate cryptographic >>keys or directly enciphering raw user data (e.g., user password). >> >>Wen-Cheng Wang >> >> > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C4usv9079787; Wed, 11 May 2005 21:56:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C4ush2079785; Wed, 11 May 2005 21:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C4uo3Q079768 for ; Wed, 11 May 2005 21:56:53 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4C4ulEE030977; Thu, 12 May 2005 12:56:47 +0800 Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4C4ugj8014047; Thu, 12 May 2005 12:56:45 +0800 Message-ID: <011901c556ae$ffda6c10$4f85900a@wcwang> From: "Wen-Cheng Wang" To: "Miguel A Rodriguez" , "Russ Housley" Cc: References: <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com><000d01c5564d$c4a93060$d600a8c0@seguridata.com> <6.2.1.2.2.20050511154032.05801770@mail.binhost.com> Subject: Re: key usage - key encipherment or data encipherment Date: Thu, 12 May 2005 12:56:42 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: FYI: In the Asia PKI Interoperability Guideline (prepared by Asia PKI Forum), we suggest CA vendors or operators to assert both the keyEncipherment and dataEncipherment bits in an encryption cert. The main reason is that we intend to allow users to use the public key for directly enciphering raw user data. We certainly know that the public key is usually used to encrypt intermediate cryptographic keys. However, what if someday users really want to use that public key for directly enciphering raw user data (e.g., user password)? For the sake of supporting both kinds of encipherment, it is better to assert both bits in the beginning. I see no reason why a public key certified by an "encryption" certificate should be prohibit from being used for directly enciphering small-size user data. The second reason is that we believe that asserting both bits is helpful to achieve maximum Interoperability. By asserting both bits, no matter which interpretation the application implementators adopt, the cert should always work. Anyway, I believe that it is not harmful if the dataEncipherment bit is asserted in an encryption cert in addition to the keyEncipherment bit. Wen-Cheng Wang ----- Original Message ----- From: "Russ Housley" To: "Miguel A Rodriguez" Cc: Sent: Thursday, May 12, 2005 3:57 AM Subject: RE: key usage - key encipherment or data encipherment > > As far as I know, SET was the only protocol that used data encipherment. Of course, SET used the > same RSA public key for both data encipherment and key encipherment. > > Russ > > At 01:20 PM 5/11/2005, Miguel A Rodriguez wrote: > >>Does anyone use dataEncipherment? >> >>Miguel A Rodríguez >>SeguriData >>Mexico >> >>At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: >> >> >> >Peter Gutmann wrote: >> >>Andrew Sciberras writes: >> >> >> >>> The keyEncipherment bit is asserted when the subject public key >>is >> >>> used for key transport. For example, when an RSA key is to be >> >>> used for key management, then this bit shall asserted. >> >>> >> >>> The dataEncipherment bit is asserted when the subject public >>key >> >>> is used for enciphering user data, other than cryptographic >> >>> keys. >> >>Quoting that won't help (I've seen this sort of thing before) because >> >>as far as the user is concerned what's being encrypted is data, so the >> >> >>valid bit to use is dataEncipherment (quite logical to them). What >> >>might help is to make this more explicit in the text: >> >> The dataEncipherment bit is asserted when the subject public key is >> >> used for >> >> directly enciphering raw user data without the use of an >>intermediate >> >> symmetric cipher. This bit MUST NOT be set when the intention is to >> >> encipher intermediate cryptographic keys rather than raw user data. >> >It is better to clarify that it is legitimate to assert both the >> >keyEncipherment bit >> >and the dataEncipherment bit in one certificate. In that case, it means >> >> >that the >> >key (e.g., RSA key) may be used for enciphering intermediate >>cryptographic >> >keys or directly enciphering raw user data (e.g., user password). >> > >> >Wen-Cheng Wang >> > >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C2GEsg058827; Wed, 11 May 2005 19:16:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4C2GErC058826; Wed, 11 May 2005 19:16:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4C2GCEf058812 for ; Wed, 11 May 2005 19:16:13 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Thu, 12 May 2005 12:14:49 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Thu, 12 May 2005 12:14:49 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Thu, 12 May 2005 12:14:40 +1000 From: "Simon McMahon" To: Cc: Subject: Re: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4C2GEEf058820 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, They were calling an 'encrypt' function to encrypt XML data and they gave it an RSA key (the cert actually) to do it. Of course it internally made an AES key but they never saw it until the interoperability issue made them look. From what they saw at the level they were looking the interpretation was reasonable. When the transport key is well hidden and simply part of the protocol then it looks just like RSA is encrypting big slabs of data. If you know that RSA is bound by the modulus size then you know what is really happening but not all users of PKI know RSA so well. Why should they? Couple this interpretation of key-usage with a dubious decision to reject encryption requests with certs that dont have key-usage='data encipherment' and you have an interoperability problem. I say "dubious" because it is a public key so you cannot enforce usage policy anyway. The CA could set both flags to fix it, which by the way was the vendors preferred solution, but its not my CA or their CA and the CA doesn't do that. Why should they? This reference, in my opinion, allows the ambiguous interpretation: > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for enciphering user data, other than cryptographic keys. In this case the public key is clearly "intended" to be used to encrypt the XML data but it just doesn't do it directly because it cant. The term "key management" also has associations with more basic and explicit key management operations like installing trusted root certs or secure installation of shared secret keys etc. In this case it is much less obvious that key management is happening because the key is bundled with the data. It looks just like the public key is encrypting the data. In my opinion there are 3 cases presented as 2 in the RFC. 1. RSA encrypts data - hardly ever used. 2. RSA implicitly encrypts keys so it can really encrypt bulk data - common usage. 3. RSA explicitly encrypts keys for explicit key management functions - common usage. The current bits separate 1 from 2/3 yet people make the interpretation that they split the more common 2 from 3 assuming 1 and 2 are the same thing. Knowledge of RSA is required to know that 1 and 2 are different. Peter's comment "This bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data" is most relevant in my case. Does PKIX support this clarification? In my opinion this problem will not entirely go away by clarifying the standard because most people dont read it before they implement something. The two bits are there and as long as they are both there then the mistake will be made by busy developers. Unenforceable key-usage policy, to "public" keys, will also continue to be implemented. People will come looking for clarification once they have an interoperability issue but by then it is often too late - the issue usually gets decided by who has the biggest corporate balls. In this case it wasn't too late so thanks for the assistance. If I could recommend a change to the standard then I would suggest dropping one of the encryption bits and just have a single key-usage = "encryption". Give it the value the same as "key-encryption" since this is the common usage. Thanks, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 >>> Russ Housley 05/12/05 01:06am >>> Simon: If they are encrypting the XML data directly with the RSA key (which is very unlikely), then they are correct. The traditional way to handle this is to generate a random content-encryption key (CEK) and then encrypt the XML data with a symmetric algorithm using the CEK. The CEK is encrypted with the RSA key from the certificate. Thus, the RSA key is really being used to encrypt only symmetric keys. Russ At 08:33 PM 5/10/2005, Simon McMahon wrote: >Hi, > >I have had a recent interoperability issue with a application vendor that >didn't like the key-usage attributes in a cert from a CA vendor's >certificate. Signing certs work fine, it was an encryption cert that failed. > >CA sets key-usage = "key encipherment". >Application wants to encrypt some XML data so looks for key-usage = "data >encipherment". Reason - because XML is data, not a key. > >I believe the application vendor is wrong and I explained that the RSA key >actually encrypts an AES key so it doesn't directly encrypt the data but >they want an official "pkix" ruling based on the standard so can someone >please refer me to a statement in the standard that clears this up. > >Thanks, > >Simon McMahon. > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > > >*********************************************************************************** >This email, including any attachments sent with it, is confidential and >for the sole use of the intended recipient(s). This confidentiality is >not waived or lost, if you receive it and you are not the intended >recipient(s), or if it is transmitted/received in error. > >Any unauthorised use, alteration, disclosure, distribution or review of >this email is prohibited. It may be subject to a statutory duty of >confidentiality if it relates to health service matters. > >If you are not the intended recipient(s), or if you have received this >email in error, you are asked to immediately notify the sender by >telephone or by return email. You should also delete this email and >destroy any hard copies produced. >*********************************************************************************** *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BJx2Ce028403; Wed, 11 May 2005 12:59:02 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BJx2He028402; Wed, 11 May 2005 12:59:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4BJx0kU028395 for ; Wed, 11 May 2005 12:59:01 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 18403 invoked by uid 0); 11 May 2005 19:57:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.94.125) by woodstock.binhost.com with SMTP; 11 May 2005 19:57:15 -0000 Message-Id: <6.2.1.2.2.20050511154032.05801770@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 15:57:12 -0400 To: "Miguel A Rodriguez" From: Russ Housley Subject: RE: key usage - key encipherment or data encipherment Cc: ietf-pkix@imc.org In-Reply-To: <000d01c5564d$c4a93060$d600a8c0@seguridata.com> References: <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com> <000d01c5564d$c4a93060$d600a8c0@seguridata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As far as I know, SET was the only protocol that used data encipherment. Of course, SET used the same RSA public key for both data encipherment and key encipherment. Russ At 01:20 PM 5/11/2005, Miguel A Rodriguez wrote: >Does anyone use dataEncipherment? > >Miguel A Rodríguez >SeguriData >Mexico > >At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: > > > >Peter Gutmann wrote: > >>Andrew Sciberras writes: > >> > >>> The keyEncipherment bit is asserted when the subject public key >is > >>> used for key transport. For example, when an RSA key is to be > >>> used for key management, then this bit shall asserted. > >>> > >>> The dataEncipherment bit is asserted when the subject public >key > >>> is used for enciphering user data, other than cryptographic > >>> keys. > >>Quoting that won't help (I've seen this sort of thing before) because > >>as far as the user is concerned what's being encrypted is data, so the > > >>valid bit to use is dataEncipherment (quite logical to them). What > >>might help is to make this more explicit in the text: > >> The dataEncipherment bit is asserted when the subject public key is > >> used for > >> directly enciphering raw user data without the use of an >intermediate > >> symmetric cipher. This bit MUST NOT be set when the intention is to > >> encipher intermediate cryptographic keys rather than raw user data. > >It is better to clarify that it is legitimate to assert both the > >keyEncipherment bit > >and the dataEncipherment bit in one certificate. In that case, it means > > >that the > >key (e.g., RSA key) may be used for enciphering intermediate >cryptographic > >keys or directly enciphering raw user data (e.g., user password). > > > >Wen-Cheng Wang > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BI2Evj019550; Wed, 11 May 2005 11:02:14 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BI2E6M019549; Wed, 11 May 2005 11:02:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BI2D9s019542 for ; Wed, 11 May 2005 11:02:13 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4BI1jD3004887 for ; Wed, 11 May 2005 14:01:45 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4BI1K9r010680 for ; Wed, 11 May 2005 14:01:20 -0400 (EDT) Message-Id: <5.1.0.14.2.20050511135058.034e5c80@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 11 May 2005 14:02:30 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: Evaluating Rough Consensus for 3770bis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: After reviewing the traffic on the list, it appears to me that rough consensus has been achieved with the release of the latest draft of 3770bis, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)". I intend to forward the document to Sam Hartman this Friday (May 13) for progression unless I hear an outcry on the list. The current draft is available at http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-02.txt Thanks, Tim Polk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BHKpp7015544; Wed, 11 May 2005 10:20:51 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BHKpII015543; Wed, 11 May 2005 10:20:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from [200.53.113.210] (mail.seguridata.com [200.53.113.210]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4BHKnXR015537 for ; Wed, 11 May 2005 10:20:50 -0700 (PDT) (envelope-from mars@seguridata.com) Received: from no.name.available by [200.53.113.210] via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; Wed, 11 May 2005 13:19:03 -0500 Received: from miguel2 ([192.168.0.214]) by mail.seguridata.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 May 2005 12:23:50 -0500 From: "Miguel A Rodriguez" To: Subject: RE: key usage - key encipherment or data encipherment Date: Wed, 11 May 2005 12:20:46 -0500 Message-ID: <000d01c5564d$c4a93060$d600a8c0@seguridata.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 11 May 2005 17:23:50.0119 (UTC) FILETIME=[324BBF70:01C5564E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4BHKoXR015538 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does anyone use dataEncipherment? Miguel A Rodríguez SeguriData Mexico At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: >Peter Gutmann wrote: >>Andrew Sciberras writes: >> >>> The keyEncipherment bit is asserted when the subject public key is >>> used for key transport. For example, when an RSA key is to be >>> used for key management, then this bit shall asserted. >>> >>> The dataEncipherment bit is asserted when the subject public key >>> is used for enciphering user data, other than cryptographic >>> keys. >>Quoting that won't help (I've seen this sort of thing before) because >>as far as the user is concerned what's being encrypted is data, so the >>valid bit to use is dataEncipherment (quite logical to them). What >>might help is to make this more explicit in the text: >> The dataEncipherment bit is asserted when the subject public key is >> used for >> directly enciphering raw user data without the use of an intermediate >> symmetric cipher. This bit MUST NOT be set when the intention is to >> encipher intermediate cryptographic keys rather than raw user data. >It is better to clarify that it is legitimate to assert both the >keyEncipherment bit >and the dataEncipherment bit in one certificate. In that case, it means >that the >key (e.g., RSA key) may be used for enciphering intermediate cryptographic >keys or directly enciphering raw user data (e.g., user password). > >Wen-Cheng Wang > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BFgPTQ006619; Wed, 11 May 2005 08:42:25 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BFgPen006618; Wed, 11 May 2005 08:42:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4BFgOMW006612 for ; Wed, 11 May 2005 08:42:25 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 27169 invoked by uid 0); 11 May 2005 15:40:15 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.135.101) by woodstock.binhost.com with SMTP; 11 May 2005 15:40:15 -0000 Message-Id: <6.2.1.2.2.20050511113838.0555a8a0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 11:40:16 -0400 To: "Wen-Cheng Wang" From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: In-Reply-To: <019e01c555fd$b35a8cf0$4f85900a@wcwang> References: <019e01c555fd$b35a8cf0$4f85900a@wcwang> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I believe that RFC 3280 is quite clear that more than one of these bits can be set. It says: This profile does not restrict the combinations of bits that may be set in an instantiation of the keyUsage extension. However, appropriate values for keyUsage extensions for particular algorithms are specified in [PKIXALGS]. Russ At 03:47 AM 5/11/2005, Wen-Cheng Wang wrote: >Peter Gutmann wrote: >>Andrew Sciberras writes: >> >>> The keyEncipherment bit is asserted when the subject public key is >>> used for key transport. For example, when an RSA key is to be >>> used for key management, then this bit shall asserted. >>> >>> The dataEncipherment bit is asserted when the subject public key >>> is used for enciphering user data, other than cryptographic keys. >>Quoting that won't help (I've seen this sort of thing before) because as far >>as the user is concerned what's being encrypted is data, so the valid bit to >>use is dataEncipherment (quite logical to them). What might help is to make >>this more explicit in the text: >> The dataEncipherment bit is asserted when the subject public key is >> used for >> directly enciphering raw user data without the use of an intermediate >> symmetric cipher. This bit MUST NOT be set when the intention is to >> encipher intermediate cryptographic keys rather than raw user data. >It is better to clarify that it is legitimate to assert both the >keyEncipherment bit >and the dataEncipherment bit in one certificate. In that case, it means >that the >key (e.g., RSA key) may be used for enciphering intermediate cryptographic >keys or directly enciphering raw user data (e.g., user password). > >Wen-Cheng Wang > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BFNfIe004688; Wed, 11 May 2005 08:23:41 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BFNff6004687; Wed, 11 May 2005 08:23:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4BFNego004675 for ; Wed, 11 May 2005 08:23:40 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 26369 invoked by uid 0); 11 May 2005 15:21:29 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.135.101) by woodstock.binhost.com with SMTP; 11 May 2005 15:21:29 -0000 Message-Id: <6.2.1.2.2.20050511110252.04b9c300@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 11 May 2005 11:06:39 -0400 To: "Simon McMahon" From: Russ Housley Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon: If they are encrypting the XML data directly with the RSA key (which is very unlikely), then they are correct. The traditional way to handle this is to generate a random content-encryption key (CEK) and then encrypt the XML data with a symmetric algorithm using the CEK. The CEK is encrypted with the RSA key from the certificate. Thus, the RSA key is really being used to encrypt only symmetric keys. Russ At 08:33 PM 5/10/2005, Simon McMahon wrote: >Hi, > >I have had a recent interoperability issue with a application vendor that >didn't like the key-usage attributes in a cert from a CA vendor's >certificate. Signing certs work fine, it was an encryption cert that failed. > >CA sets key-usage = "key encipherment". >Application wants to encrypt some XML data so looks for key-usage = "data >encipherment". Reason - because XML is data, not a key. > >I believe the application vendor is wrong and I explained that the RSA key >actually encrypts an AES key so it doesn't directly encrypt the data but >they want an official "pkix" ruling based on the standard so can someone >please refer me to a statement in the standard that clears this up. > >Thanks, > >Simon McMahon. > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > > >*********************************************************************************** >This email, including any attachments sent with it, is confidential and >for the sole use of the intended recipient(s). This confidentiality is >not waived or lost, if you receive it and you are not the intended >recipient(s), or if it is transmitted/received in error. > >Any unauthorised use, alteration, disclosure, distribution or review of >this email is prohibited. It may be subject to a statutory duty of >confidentiality if it relates to health service matters. > >If you are not the intended recipient(s), or if you have received this >email in error, you are asked to immediately notify the sender by >telephone or by return email. You should also delete this email and >destroy any hard copies produced. >*********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BAmoDP032162; Wed, 11 May 2005 03:48:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4BAmoL8032161; Wed, 11 May 2005 03:48:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BAmndO032124 for ; Wed, 11 May 2005 03:48:49 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com) Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id 35DF45FF4E; Wed, 11 May 2005 05:48:15 -0500 (CDT) Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id ; Wed, 11 May 2005 05:48:14 -0500 Message-ID: <5.1.0.14.0.20050511064836.00adf900@172.16.146.192> From: "Kazin, Joel" To: pgut001@cs.auckland.ac.nz, andrewsciberras@gmail.com, Simon_McMahon@health.qld.gov.au Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment Date: Wed, 11 May 2005 05:49:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C55616.EE7E8D2C" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C55616.EE7E8D2C Content-Type: text/plain; charset="iso-8859-1" Peters rewording makes it clearer. At 12:34 AM 5/11/2005 -0500, pgut001@cs.auckland.ac.nz wrote: Andrew Sciberras writes: > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for enciphering user data, other than cryptographic keys. Quoting that won't help (I've seen this sort of thing before) because as far as the user is concerned what's being encrypted is data, so the valid bit to use is dataEncipherment (quite logical to them). What might help is to make this more explicit in the text: The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. This bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data. Peter. Joel S. Kazin CPA, CISA, CISSP, CISM Senior Consultant Atos Origin 40 Old Sleepy Hollow Road Pleasantville, New York 10570-3802 USA Phone +1 914-769-8780 Mobile +1 914-564-1484 email joel.kazin@atosorigin.com www.atosorigin.com ------_=_NextPart_001_01C55616.EE7E8D2C Content-Type: text/html; charset="iso-8859-1" Peters rewording makes it clearer.

At 12:34 AM 5/11/2005 -0500, pgut001@cs.auckland.ac.nz wrote:

Andrew Sciberras <andrewsciberras@gmail.com> writes:

>     The keyEncipherment bit is asserted when the subject public key is
>      used for key transport.  For example, when an RSA key is to be
>      used for key management, then this bit shall asserted.
>
>      The dataEncipherment bit is asserted when the subject public key
>      is used for enciphering user data, other than cryptographic keys.

Quoting that won't help (I've seen this sort of thing before) because as far
as the user is concerned what's being encrypted is data, so the valid bit to
use is dataEncipherment (quite logical to them).  What might help is to make
this more explicit in the text:

  The dataEncipherment bit is asserted when the subject public key is used for
  directly enciphering raw user data without the use of an intermediate
  symmetric cipher.  This bit MUST NOT be set when the intention is to
  encipher intermediate cryptographic keys rather than raw user data.

Peter.


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    joel.kazin@atosorigin.com
www.atosorigin.com
 ------_=_NextPart_001_01C55616.EE7E8D2C-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9d1NM006649; Wed, 11 May 2005 02:39:01 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B9d10g006648; Wed, 11 May 2005 02:39:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9cxbj006635 for ; Wed, 11 May 2005 02:39:00 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id A0EA234A98; Wed, 11 May 2005 21:38:58 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28540-21; Wed, 11 May 2005 21:38:58 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id E96153468C; Wed, 11 May 2005 21:38:57 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 9081337744; Wed, 11 May 2005 21:38:57 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DVngG-0006pf-00; Wed, 11 May 2005 21:39:04 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: andrewsciberras@gmail.com, pgut001@cs.auckland.ac.nz, Simon_McMahon@health.qld.gov.au, wcwang@cht.com.tw Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <019e01c555fd$b35a8cf0$4f85900a@wcwang> Message-Id: Date: Wed, 11 May 2005 21:39:04 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Wen-Cheng Wang" writes: >It is better to clarify that it is legitimate to assert both the >keyEncipherment bit and the dataEncipherment bit in one certificate. In that >case, it means that the key (e.g., RSA key) may be used for enciphering >intermediate cryptographic keys or directly enciphering raw user data (e.g., >user password). Saying you can use both bits won't help, it still leaves it ambiguous to users as to what dataEncipherment should be used for. One interpretation I've heard of is keyEncipherment = exchange of session keys (SSL), dataEncipherment = data encryption (S/MIME). Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9S8pR002812; Wed, 11 May 2005 02:28:08 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B9S8Db002811; Wed, 11 May 2005 02:28:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B9S5tV002754 for ; Wed, 11 May 2005 02:28:06 -0700 (PDT) (envelope-from andrewsciberras@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so62335nzn for ; Wed, 11 May 2005 02:28:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Ic6NKFgyvlIzCervQE2SRpcoVJRc+uMzRyCMzJDVnQlqTk/td/3zydNLK3X2QVDt4qKTztNfLULySrtBM4lroijVDLAZDWrw1gnB/Yc0w5s8Tqc7F1xeBJ1lErkeHKcEgELPmhi+jmLJk4yMNgJjcseLCFy/nLewuGt1amIRPeM= Received: by 10.36.146.12 with SMTP id t12mr38413nzd; Wed, 11 May 2005 02:28:00 -0700 (PDT) Received: from ?192.168.1.10? ([202.164.196.167]) by mx.gmail.com with ESMTP id 17sm264287nzo.2005.05.11.02.27.58; Wed, 11 May 2005 02:28:00 -0700 (PDT) Message-ID: <4281D11E.4070009@gmail.com> Date: Wed, 11 May 2005 19:32:14 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann CC: Simon_McMahon@health.qld.gov.au, ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: In-Reply-To: Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Gutmann wrote: 

Andrew Sciberras <andrewsciberras@gmail.com> writes:

  
    The keyEncipherment bit is asserted when the subject public key is
     used for key transport.  For example, when an RSA key is to be
     used for key management, then this bit shall asserted.

     The dataEncipherment bit is asserted when the subject public key
     is used for enciphering user data, other than cryptographic keys.
    

Quoting that won't help (I've seen this sort of thing before) because as far
as the user is concerned what's being encrypted is data, so the valid bit to
use is dataEncipherment (quite logical to them).  What might help is to make
this more explicit in the text:

  The dataEncipherment bit is asserted when the subject public key is used for
  directly enciphering raw user data without the use of an intermediate
  symmetric cipher.  This bit MUST NOT be set when the intention is to
  encipher intermediate cryptographic keys rather than raw user data.
Yeah, I see your point Peter.
Simon seems to know what he's talking about and made the point that the key is actually encrypting an AES key, he then wanted a standards based opinion.
I think RFC 2459 clearly states what each of the key usage bits are to be used for.

I don't think that the user's interpretation of what's being encrypted is significant at all. Its more about the developers who are writing decision making code understanding the various usages. At that point the developer should be very aware of how the key associated with the certificate is being used and therefore 2459's description should suffice.


Peter.
Andrew Sciberras.
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B7mNqw068050; Wed, 11 May 2005 00:48:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B7mNSb068048; Wed, 11 May 2005 00:48:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B7m6Kn067942 for ; Wed, 11 May 2005 00:48:18 -0700 (PDT) (envelope-from wcwang@cht.com.tw) Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j4B7qkS5008400; Wed, 11 May 2005 15:52:46 +0800 Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id j4B7tcGG009941; Wed, 11 May 2005 15:55:39 +0800 Message-ID: <019e01c555fd$b35a8cf0$4f85900a@wcwang> From: "Wen-Cheng Wang" To: "Peter Gutmann" , , Cc: References: Subject: Re: key usage - key encipherment or data encipherment Date: Wed, 11 May 2005 15:47:29 +0800 Organization: Chunghwa Telecom MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="big5"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2527 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter Gutmann wrote: > > Andrew Sciberras writes: > >> The keyEncipherment bit is asserted when the subject public key is >> used for key transport. For example, when an RSA key is to be >> used for key management, then this bit shall asserted. >> >> The dataEncipherment bit is asserted when the subject public key >> is used for enciphering user data, other than cryptographic keys. > > Quoting that won't help (I've seen this sort of thing before) because as far > as the user is concerned what's being encrypted is data, so the valid bit to > use is dataEncipherment (quite logical to them). What might help is to make > this more explicit in the text: > > The dataEncipherment bit is asserted when the subject public key is used for > directly enciphering raw user data without the use of an intermediate > symmetric cipher. This bit MUST NOT be set when the intention is to > encipher intermediate cryptographic keys rather than raw user data. > It is better to clarify that it is legitimate to assert both the keyEncipherment bit and the dataEncipherment bit in one certificate. In that case, it means that the key (e.g., RSA key) may be used for enciphering intermediate cryptographic keys or directly enciphering raw user data (e.g., user password). Wen-Cheng Wang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B5fheW015967; Tue, 10 May 2005 22:41:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B5fhJD015966; Tue, 10 May 2005 22:41:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B5fg6e015950 for ; Tue, 10 May 2005 22:41:42 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 5BCF634DBB; Wed, 11 May 2005 17:41:41 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09358-24; Wed, 11 May 2005 17:41:41 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id DD48D33ED6; Wed, 11 May 2005 17:41:40 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CF24637744; Wed, 11 May 2005 17:41:40 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DVjyc-0006i8-00; Wed, 11 May 2005 17:41:46 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Simon_McMahon@health.qld.gov.au, wpolk@nist.gov Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <1115780746.4281768a300bf@webmail.nist.gov> Message-Id: Date: Wed, 11 May 2005 17:41:46 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: wpolk@nist.gov writes: >This is a recurring problem with applications. If this is a recurring problem then it's a strong indicator that the wording of the spec needs to be changed to address it. >If your vendor is cooperative, that will make your choice easier. They almost never are. The standard flow for this sort of thing is: 1. Vendor does something silly. 2. Vendor uses ambiguous wording of spec to justify their silliness because they don't want to fix their code. 3. User has the option of breaking their code to match the vendor silliness, or going somewhere else (learning to flip burgers, for example). Peter (who just last week went through an argument with a vendor who claimed that some open-ended wording in the X.509v3 spec (before sundry corrections and bugfixes are applied, and not counting X.509v4 updates or any bugfixes to that) allowed them to do something silly, and they weren't going to change their code, and anyone who didn't like it could bugger off). Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B5YRQX012359; Tue, 10 May 2005 22:34:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B5YRff012358; Tue, 10 May 2005 22:34:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpd.itss.auckland.ac.nz (zeppo.itss.auckland.ac.nz [130.216.190.14]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B5YPX6012340 for ; Tue, 10 May 2005 22:34:25 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 08097344BE; Wed, 11 May 2005 17:34:24 +1200 (NZST) Received: from smtpd.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05922-14; Wed, 11 May 2005 17:34:23 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpd.itss.auckland.ac.nz (Postfix) with ESMTP id 6AC40341C8; Wed, 11 May 2005 17:34:23 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 44B0137744; Wed, 11 May 2005 17:34:23 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1DVjrY-0006hg-00; Wed, 11 May 2005 17:34:28 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: andrewsciberras@gmail.com, Simon_McMahon@health.qld.gov.au Subject: Re: key usage - key encipherment or data encipherment Cc: ietf-pkix@vpnc.org In-Reply-To: <42816598.2030001@gmail.com> Message-Id: Date: Wed, 11 May 2005 17:34:28 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Andrew Sciberras writes: > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for enciphering user data, other than cryptographic keys. Quoting that won't help (I've seen this sort of thing before) because as far as the user is concerned what's being encrypted is data, so the valid bit to use is dataEncipherment (quite logical to them). What might help is to make this more explicit in the text: The dataEncipherment bit is asserted when the subject public key is used for directly enciphering raw user data without the use of an intermediate symmetric cipher. This bit MUST NOT be set when the intention is to encipher intermediate cryptographic keys rather than raw user data. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B35qXM089294; Tue, 10 May 2005 20:05:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B35qTX089293; Tue, 10 May 2005 20:05:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B35ojQ089287 for ; Tue, 10 May 2005 20:05:51 -0700 (PDT) (envelope-from wpolk@nist.gov) Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4B35kD1002813; Tue, 10 May 2005 23:05:46 -0400 Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id j4B35kmX003194; Tue, 10 May 2005 23:05:46 -0400 Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id j4B35kc4003192; Tue, 10 May 2005 23:05:46 -0400 Received: from pool-141-156-36-119.res.east.verizon.net (pool-141-156-36-119.res.east.verizon.net [141.156.36.119]) by webmail.nist.gov (IMP) with HTTP for ; Tue, 10 May 2005 23:05:46 -0400 Message-ID: <1115780746.4281768a300bf@webmail.nist.gov> Date: Tue, 10 May 2005 23:05:46 -0400 From: wpolk@nist.gov To: Simon McMahon Cc: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 141.156.36.119 X-NIST-MailScanner: Found to be clean X-MailScanner-From: wpolk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Simon, Your interpretation matches the PKIX interpretation. Since the RSA key is used to encrypt the AES key, it is key encipherment not data encipherment. The AES key enciphers the data. This is a recurring problem with applications. In general, policies used by most PKIs (including the U.S. government) forbid setting the data encipherment bit. There are a number of security problems taht can arise if an application actuially uses the RSA key to encipher the datat directly. It is almost always a better choice to encrypt data under a good symmetric algorithm and encipher the key using the RSA algorithm. Unfortunatley, a number of applications have been implemnnted using your vendor's interpretations. This presents you with an uncomfortable choice - set data encipherment to enable your apps, but open a security vulnerability, or make the security purist choice and break your app. If your vendor is cooperative, that will make your choice easier. Tim Polk Quoting Simon McMahon : > > Hi, > > I have had a recent interoperability issue with a application vendor that > didn't like the key-usage attributes in a cert from a CA vendor's > certificate. Signing certs work fine, it was an encryption cert that failed. > > CA sets key-usage = "key encipherment". > Application wants to encrypt some XML data so looks for key-usage = "data > encipherment". Reason - because XML is data, not a key. > > I believe the application vendor is wrong and I explained that the RSA key > actually encrypts an AES key so it doesn't directly encrypt the data but they > want an official "pkix" ruling based on the standard so can someone please > refer me to a statement in the standard that clears this up. > > Thanks, > > Simon McMahon. > > > > Simon McMahon > > Work: (07) 31311420 > Mobile: (043) 2294180 > > > > Simon McMahon > > Work: (07) 31311420 > Mobile: (043) 2294180 > > > > > ******************************************************************************* **** > This email, including any attachments sent with it, is confidential and for > the sole use of the intended recipient(s). This confidentiality is not > waived or lost, if you receive it and you are not the intended recipient(s), > or if it is transmitted/received in error. > > Any unauthorised use, alteration, disclosure, distribution or review of this > email is prohibited. It may be subject to a statutory duty of > confidentiality if it relates to health service matters. > > If you are not the intended recipient(s), or if you have received this email > in error, you are asked to immediately notify the sender by telephone or by > return email. You should also delete this email and destroy any hard copies > produced. > ******************************************************************************* **** > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B1nLxU083627; Tue, 10 May 2005 18:49:23 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B1nLj9083626; Tue, 10 May 2005 18:49:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B1nHY4083608 for ; Tue, 10 May 2005 18:49:20 -0700 (PDT) (envelope-from andrewsciberras@gmail.com) Received: by zproxy.gmail.com with SMTP id 16so82630nzp for ; Tue, 10 May 2005 18:49:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Z7YVfm2B64NwF/8W5CSoWYYAPmV0Bgtus0x0t8zYxIO9AQDTA8b9zkJ0nRE/TsNkqRckUEJsVS9g0WtZ4KtVqaBSi4KtBvopRAlqY4SJLnO62sHbOp98ZvuDEpycnWpqxPhGvSKTn1p7weUn0EZG6i5N7oSVpduZg6D5KAyVMHw= Received: by 10.36.37.6 with SMTP id k6mr55185nzk; Tue, 10 May 2005 18:49:12 -0700 (PDT) Received: from ?192.168.1.10? ([202.164.196.167]) by mx.gmail.com with ESMTP id 10sm852051nzo.2005.05.10.18.49.10; Tue, 10 May 2005 18:49:12 -0700 (PDT) Message-ID: <42816598.2030001@gmail.com> Date: Wed, 11 May 2005 11:53:28 +1000 From: Andrew Sciberras Organization: eB2Bcom User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon McMahon CC: ietf-pkix@vpnc.org Subject: Re: key usage - key encipherment or data encipherment References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, From RFC2459: > The keyEncipherment bit is asserted when the subject public key is > used for key transport. For example, when an RSA key is to be > used for key management, then this bit shall asserted. > > The dataEncipherment bit is asserted when the subject public key > is used for enciphering user data, other than cryptographic keys. > Andrew Sciberras eB2Bcom Australia. Simon McMahon wrote: >Hi, > >I have had a recent interoperability issue with a application vendor that didn't like the key-usage attributes in a cert from a CA vendor's certificate. Signing certs work fine, it was an encryption cert that failed. > >CA sets key-usage = "key encipherment". >Application wants to encrypt some XML data so looks for key-usage = "data encipherment". Reason - because XML is data, not a key. > >I believe the application vendor is wrong and I explained that the RSA key actually encrypts an AES key so it doesn't directly encrypt the data but they want an official "pkix" ruling based on the standard so can someone please refer me to a statement in the standard that clears this up. > >Thanks, > >Simon McMahon. > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > >Simon McMahon > >Work: (07) 31311420 >Mobile: (043) 2294180 > > > > >*********************************************************************************** >This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. > >Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. > >If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. >*********************************************************************************** > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B0ZUKm079131; Tue, 10 May 2005 17:35:30 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4B0ZUsw079130; Tue, 10 May 2005 17:35:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from gwd-mail02.health.qld.gov.au (mail.health.qld.gov.au [203.202.23.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4B0ZSBN079123 for ; Tue, 10 May 2005 17:35:29 -0700 (PDT) (envelope-from Simon_McMahon@health.qld.gov.au) Received: from health-es2.health.qld.gov.au (unverified) by gwd-mail02.health.qld.gov.au (Content Technologies SMTPRS 4.3.12) with SMTP id for ; Wed, 11 May 2005 10:34:17 +1000 Received: from CORPORATE-SYSTEMS-Message_Server by health-es2.health.qld.gov.au with Novell_GroupWise; Wed, 11 May 2005 10:34:16 +1000 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.6.1 Date: Wed, 11 May 2005 10:33:58 +1000 From: "Simon McMahon" To: Subject: key usage - key encipherment or data encipherment Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4B0ZUBN079124 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I have had a recent interoperability issue with a application vendor that didn't like the key-usage attributes in a cert from a CA vendor's certificate. Signing certs work fine, it was an encryption cert that failed. CA sets key-usage = "key encipherment". Application wants to encrypt some XML data so looks for key-usage = "data encipherment". Reason - because XML is data, not a key. I believe the application vendor is wrong and I explained that the RSA key actually encrypts an AES key so it doesn't directly encrypt the data but they want an official "pkix" ruling based on the standard so can someone please refer me to a statement in the standard that clears this up. Thanks, Simon McMahon. Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 Simon McMahon Work: (07) 31311420 Mobile: (043) 2294180 *********************************************************************************** This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s). This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error. Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited. It may be subject to a statutory duty of confidentiality if it relates to health service matters. If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email. You should also delete this email and destroy any hard copies produced. *********************************************************************************** Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ALQsLG063166; Tue, 10 May 2005 14:26:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4ALQs7I063165; Tue, 10 May 2005 14:26:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4ALQqAg063151 for ; Tue, 10 May 2005 14:26:53 -0700 (PDT) (envelope-from tim.polk@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j4ALQWaF002756; Tue, 10 May 2005 17:26:33 -0400 Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j4ALQA9r023610; Tue, 10 May 2005 17:26:10 -0400 (EDT) Message-Id: <5.1.0.14.2.20050510170022.02cc5b08@email.nist.gov> X-Sender: wpolk@email.nist.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 10 May 2005 17:27:21 -0400 To: ietf-pkix@imc.org From: Tim Polk Subject: WG Last Call: AIA CRL extension Cc: kent@bbn.com, stefans@microsoft.com, housley@vigilsec.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-MailScanner-From: tim.polk@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message initiates working group Last Call for the specification "Internet X.509 Public Key Infrastructure: Authority Information Access CRL Extension". While some issues raised in the working group are unresolved, the editors believe that rough consensus supports the current specification. The URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-01.txt Last Call will run for (at least) two weeks. That is, Last Call will not close before May 24. Thanks, Tim Polk Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AJSsCu052654; Tue, 10 May 2005 12:28:54 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AJSscV052653; Tue, 10 May 2005 12:28:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4AJSrxI052645 for ; Tue, 10 May 2005 12:28:53 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 4329 invoked by uid 0); 10 May 2005 19:26:52 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.157.117) by woodstock.binhost.com with SMTP; 10 May 2005 19:26:52 -0000 Message-Id: <6.2.1.2.2.20050510145818.08308340@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 15:26:38 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: ietf-pkix@imc.org In-Reply-To: <42805C27.8090209@bull.net> References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> <42805C27.8090209@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: >>Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated. >>You say that it is not clear what validation policy needs to be used, but >>this is completely irrelevant to the discussion of the CRL AIA >>extension. This extension aid in certification path construction, not >>the validation of the path once it is constructed. > >Not exactly, it could "help" finding a wrong path ! Not likely. The signer of the CRL is providing a pointer to their own certificate. Path construction to locate a parent of that certificate through a complex PKI might include paths that are acceptable and paths that are unacceptable, but the certificate that contains the public key needed to validate the signature on the CRL is clearly needed. >>There are many factors which need to be considered in the validation of >>the CRL issue certificate. The values of the key usage extension and the >>certificate policies extension are two that jump to mind. There are >>probably more if I spend the time to consider each possible scenario. > >One simple rule would allow no security problem at all and I wonder why >you have so much resistance to mention it. We have that rule: The CA certificate and the CRL Issuer certificate must validate back to the same trust anchor. >>In my opinion, this document is ready for WG Last Call. > >As an editor of the draft, I may understand your position; but it is up >the the PKIX chairs to decide whether or not the document is ready for WG >last call. Correct. I included this sentence for the WG chairs. I hope they will agree with me, and that they will issue WG Last Call for this document. >Once again the current Security Considerations section is not acceptable. To you... No one else is advocating this change. I continue to believe that requiring the CA certificate and the CRL Issuer certificate to validate back to the same trust anchor resolves your concern. I am willing to add a few words to the security considerations about name collisions (my co-author may disagree), but I am not willing to use "MUST" or "SHOULD" in those words. There is absolutely nothing that a client can do to determine deal with name collisions that are subordinate to the same trust anchor. Russ Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AIxWEp050072; Tue, 10 May 2005 11:59:32 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AIxWOi050071; Tue, 10 May 2005 11:59:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4AIxVtl050062 for ; Tue, 10 May 2005 11:59:31 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 26065 invoked by uid 0); 10 May 2005 18:57:35 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.43.168) by woodstock.binhost.com with SMTP; 10 May 2005 18:57:35 -0000 Message-Id: <6.2.1.2.2.20050510145551.082d6310@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 10 May 2005 14:57:33 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: pkix In-Reply-To: <42805BD8.4050608@bull.net> References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> <42805BD8.4050608@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The document already says that the CA and the CRL issuer need to terminate at the same trust anchor. This is the important point. I disagree that there is anything else that ought to be said in the security considerations. Russ At 02:59 AM 5/10/2005, Denis Pinkas wrote: >Russ, > >Your statement below is correct, but does not answer to any of my >questions/issues. In particular, the last one. I am still awaiting your >responses. > >Denis > >>Denis: >>RFC 3280 does not tell an implementor how for locate certificates for any >>certification path construction. There are several extensions that >>provide pointers that may help an implementation, but other approaches to >>obtaining the same certificates are always permitted. I would fully >>expect an implementation to check any local cache before accessing a >>repository. >>The CRL AIA extension fits this pattern. A method for locating a >>certificate is provided, but any other mechanism for locating the same >>certificate is acceptable. >>Russ >> >>>Stefan, >>> >>>I made the e-mail shorter. Your main arguments are the following: >>> >>>========================================================================== >>> >>>[Stefan] But it has to provide a warning to something that is introduced >>>by the standard. This standard does not introduce the concept of CRL >>>signature checking or CRL issuer certificate validation, so that is >>>clearly out of scope. More about that below; >>> >>>[Denis] See below the last answer and also my arguments in the >>>soon-to-be-posted answer to Russ. >>> >>>========================================================================== >>> >>> >>> > > RFC 3280 [PKIX1] specifies the validation of certification paths. >>> > > One aspect involves the determination that a certificate has not been >>> > > revoked, and one revocation checking mechanism is the Certificate >>> > > Revocation List (CRL). CRL validation is also specified in RFC 3280, >>> >>> > I would love this last sentence to be true but the reality is that: >>> > "CRL validation is NOT specified in RFC 3280". :-( >>> >>>[Stefan] In fact it is. >>> >>>RFC 3280, Section 6.3.3 CRL processing - on page 85: >>> >>> (f) Obtain and validate the certification path for the complete CRL >>> issuer. If a key usage extension is present in the CRL issuer's >>> certificate, verify that the cRLSign bit is set. >>> >>> (g) Validate the signature on the complete CRL using the public key >>> validated in step (f). >>> >>>[Denis] The text does not say how to obtain and validate the >>>certification path for the complete (???) CRL issuer. The text is not >>>clear enough so that two implementors only looking at this sentence will >>>provide interoperable implementations. >>> >>>========================================================================== >>> >>>[Stefan] It is my hope that the provided responses here can help >>>convince you to change your mind about that. If it doesn't I still argue >>>that the place to specify requirements and security considerations for >>>CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. >>> >>>[Denis] I can agree with your last sentence, ... which means that it >>>should not be in the main body of the document. In the security >>>considerations section, text is free and we shall at the very minimum >>>warn implementers and we should provide some guidance. When the same >>>certification path (i.e. the path used to validate the target >>>certificate) is used, then there is no security issue: this should be >>>said. For all other cases, there MAY be problems: this should also be >>>said. It is as simple as that. >>> >>>Denis > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AEn4Fm026318; Tue, 10 May 2005 07:49:04 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4AEn4gB026317; Tue, 10 May 2005 07:49:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4AEn1CL026307 for ; Tue, 10 May 2005 07:49:01 -0700 (PDT) (envelope-from dcross@microsoft.com) Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 07:48:56 -0700 Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 07:48:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on Date: Tue, 10 May 2005 07:49:03 -0700 Message-ID: <3C69AE30038D9A4590F5EC20DCD41F680665BB8F@RED-MSG-41.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Thread-Index: AcVVNbs3zSlsD+3rRaWiQ+PF2lgiPAAOMTdA From: "David Cross" To: "Denis Pinkas" , X-OriginalArrivalTime: 10 May 2005 14:48:55.0762 (UTC) FILETIME=[6403AB20:01C5556F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4AEn1CL026311 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: I have to disagree on removal of the text. I have not seen any objections from the list or working group to this inclusion. I have to disagree with your assertion that removing the text is a more secure recommendation. The below text (slightly edited to my taste) is an excellent recommendation from an implementation standoint and a security consideration. I would personally concede that using MUST *may* be incorrect here and a SHOULD *may* be more appropriate. As a means of mitigating implementation challenges and security issues related to issuer name collisions, CA names SHOULD be formed in such a way that reduce the likelihood of name collisions. Implementations validating CRLs SHOULD ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at a common trust anchor. David B. Cross -----Original Message----- From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] On Behalf Of Denis Pinkas Sent: Tuesday, May 10, 2005 12:01 AM To: Russ Housley Cc: ietf-pkix@imc.org Subject: Re: Comments on Russ, > Denis: > > Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated. > > You say that it is not clear what validation policy needs to be used, > but this is completely irrelevant to the discussion of the CRL AIA > extension. This extension aid in certification path construction, not > the validation of the path once it is constructed. Not exactly, it could "help" finding a wrong path ! > There are many factors which need to be considered in the validation > of the CRL issue certificate. The values of the key usage extension > and the certificate policies extension are two that jump to mind. > There are probably more if I spend the time to consider each possible scenario. One simple rule would allow no security problem at all and I wonder why you have so much resistance to mention it. > In my opinion, this document is ready for WG Last Call. As an editor of the draft, I may understand your position; but it is up the the PKIX chairs to decide whether or not the document is ready for WG last call. Once again the current Security Considerations section is not acceptable. In particular it contains a "MUST" statement that cannot be placed in such a section and which is in addition fully wrong. Hereabove is the last one from draft 01: 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. As means of reducing problems and security issues related to issuer name collisions, CA names SHOULD be formed in a way that reduce the likelihood of name collisions. Implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at the same trust anchor. Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Hereafter is a "minimalist" rewriting of this section, if we take the choice to mention the issue, but not to provide any secure solution (mentioning insecure or insufficient solutions is not appropriate). Two sentences have thus been deleted. 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Denis > Russ > > > At 09:07 AM 5/9/2005, Denis Pinkas wrote: > >> Russ, >> >> > Here is a quote from RFC 3280. To me, it is clear that a CRL >> > issuer >> has >> > a certificate. >> >> True, a CRL issuer (that is different from the CA that has issued the >> target >> certificate) has a certificate. So we both strongly agree on this >> this. :-) >> >> > Obviously, all certificates need to be validated, which includes >> > certification path construction and certification path >> validation. >> >> When a sentence starts with "Obviously", it means that it is not so >> obvious. >> :-| >> >> The real question is whether the CRL issuer certificate has to be >> verified using rules (i.e. a validation policy) which are independent >> from the certification path construction of the target certificate. >> RFC 3280 does not provide a crystal clear answer to that question. >> >> If the rules are different, then you MAY end up with a security issue >> (see my previous explanations). The current "recommendations" that >> are in the security considerations section do NOT solve this issue in >> the general case. >> >> If the rules are the same, i.e. the path used to validate the >> certification path from the certificate are also used, then there is >> no security issue. >> >> I do not think it would be good to hide this issue in the proposed draft. >> Anyway, the current "recommendations" do NOT solve the issue and are >> thus not acceptable and so this section cannot stand as it is. >> >> Denis >> >> > 5.1.1.3 signatureValue >> > >> > The signatureValue field contains a digital signature computed upon >> > the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded >> tbsCertList >> > is used as the input to the signature function. This signature >> value >> > is encoded as a BIT STRING and included in the CRL signatureValue >> > field. The details of this process are specified for each of the >> > supported algorithms in [PKIXALGS]. >> > >> > CAs that are also CRL issuers MAY use one private key to digitally >> > sign certificates and CRLs, or MAY use separate private keys to >> > digitally sign certificates and CRLs. When separate private >> > keys >> are >> > employed, each of the public keys associated with these private keys >> > is placed in a separate certificate, one with the keyCertSign >> > bit >> set >> > in the key usage extension, and one with the cRLSign bit set in the >> > key usage extension (section 4.2.1.3). When separate private keys >> > are employed, certificates issued by the CA contain one >> > authority >> key >> > identifier, and the corresponding CRLs contain a different authority >> > key identifier. The use of separate CA certificates for validation >> > of certificate signatures and CRL signatures can offer improved >> > security characteristics; however, it imposes a burden on >> > applications, and it might limit interoperability. Many >> applications >> > construct a certification path, and then validate the certification >> > path (section 6). CRL checking in turn requires a separate >> > certification path to be constructed and validated for the CA's CRL >> > signature validation certificate. Applications that perform CRL >> > checking MUST support certification path validation when >> certificates >> > and CRLs are digitally signed with the same CA private key. These >> > applications SHOULD support certification path validation when >> > certificates and CRLs are digitally signed with different CA private >> > keys. >> > >> > Russ >> > >> > At 01:12 PM 4/28/2005, Denis Pinkas wrote: >> > >> >> Stefan and Russ, >> >> >> >>> Denis, >> >> >> >> >> >>> Russ and I have taken a thorough look at your text proposal and >> >>> we >> have >> >>> edited a counter proposal where we try to meet your needs as much >> >>> as possible without compromising what we think is the core >> >>> purpose of >> the >> >>> draft (to enable certificate discovery bottom-up). >> >> >> >> >> >>> The conclusion is that we suggest changes to the introduction >> >>> section but we keep the old security considerations intact. >> >> >> >> >> >> I would suggest that a merge would need to be done between the "old" >> >> security considerations section and the "new" one. >> >> >> >> The "old" security considerations section is mentionning a >> >> solution which does NOT suppress the problem, but minimize the >> >> risk only in case the CAs are really "honest". >> >> >> >> The old" security considerations section does not provide a >> >> solution in case the name collsion between two CRL issuer name is >> >> deliberate, whereas the "new" security considerations section >> >> provides a secure solution in one case and clearly mentions that >> >> all other cases are dependant about "zillions" of *local* trust >> >> conditions which cannot all be standardized. >> >> >> >> The main purpose of a security considerations section is to >> >> provide the adequate warnings and solutions when they exist and >> >> not to hide the problems. >> >> >> >>> That is not because >> >>> we necessarily disagree with all of the statements in your >> proposal, but >> >>> in the cases we don't, we still think it is out of scope for this >> work. >> >> >> >> >> >> This is clearly within the scope of a security considerations section. >> >> >> >>> The new introduction proposal based on your input is: >> >>> -------------------------------------------------------------- >> >>> RFC 3280 [PKIX1] specifies the validation of certification paths. >> One >> >>> aspect involves the determination that a certificate has not been >> >>> revoked, and one revocation checking mechanism is the Certificate >> >>> Revocation List (CRL). CRL validation is also specified in RFC >> >>> 3280, >> >> >> >> >> >> I would love this last sentence to be true but the reality is that: >> >> "CRL validation is NOT specified in RFC 3280". :-( >> >> >> >>> which involves the constructions of a valid certification path >> >>> for >> the >> >>> CRL issuer. >> >> >> >> >> >> There is no such a statement in RFC 3280. >> >> >> >>> Building a CRL issuer certification path from the signer of >> >> >> >> >> >> There is no notion of "CRL issuer certification path" in RFC 3280. >> >> The primary requirement is to make sure that the CRL issuer >> >> designated by the CA is indeed the right one. In some (but not >> >> all) cases, I mean among the zillion of cases, there MAY be a need >> >> to construct a CRL issuer certification path. >> >> >> >>> the CRL to a trust anchor is straightforward when the certificate >> of the >> >>> CRL issuer is present in the certification path associated with >> >>> the target certificate, but it can be complex in other situations. >> >> >> >> >> >> From the comments above, you can see that I cannot agree with the >> >> above revised text. The remaining of the text is acceptable in >> >> general, but could possibly be slightly revised to be more in >> >> continuation with the changes there are needed above (i.e. it is >> >> not cast in concrete). >> >> >> >> Denis >> >> >> >>> There are several legitimate scenarios where the certificate of >> the CRL >> >>> issuer is not present, or easily discovered, from the target >> >>> certification path. This can be the case when indirect CRLs are >> used, >> >>> when the certification Authority (CA) that issued the target >> certificate >> >>> changes its certificate signing key, or when the CA employs >> >>> separate keys for certificate signing and CRL signing. >> >>> Methods of finding the certificate of the CRL issuer are >> >>> currently available, such as though an accessible directory >> >>> location or through use of the Subject Information Access >> >>> extension in intermediary CA certificates. >> >>> Directory lookup requires existence and access to a directory >> >>> that >> has >> >>> been populated with all of the necessary certificates. The >> >>> Subject Information Access extension, which supports building the >> >>> CRL issuer certification path top-down (in the direction from the >> >>> trust >> anchor to >> >>> the CRL issuer), requires that some certificates in the CRL >> >>> issuer certification path includes an appropriate Subject >> >>> Information Access extension. >> >>> RFC 3280 [PKIX1] provides for bottom-up discovery of >> >>> certification >> paths >> >>> through the Authority Information Access extension, where the >> >>> id-ad-caIssuers access method may specify one or more >> >>> accessLocation fields that reference CA certificates associated >> >>> with the certificate containing this extension. >> >>> This document enables the use of the Authority Information Access >> >>> extension in CRLs, enabling a CRL checking application to use the >> access >> >>> method (id-ad-caIssuers) to locate certificates that may be >> >>> useful in the construction of a valid CRL issuer certification >> >>> path to an appropriate trust anchor. >> >>> >> >>> Stefan Santesson >> >>> Program Manager, Standards Liaison Windows Security >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >> >>>> Sent: den 18 april 2005 13:41 >> >>>> To: Stefan Santesson >> >>>> Cc: Russ Housley; pkix >> >>>> Subject: Re: Comments on >> >>>> >> >>>> Stefan, >> >>>> >> >>>> >> >>>>> Denis, >> >>>> >> >>>> >> >>>>> I will come back and comment on your text proposals, but before >> >>>> >> >>> that, >> >>> >> >>>> > a few questions/comments: >> >>>> >> >>>> >> >>>>> >> >>>> >> >>>> >> >>>>>>> You point out some well known issues related to the lack of >> >>>>>> >> >>> absolute >> >>> >> >>>>>>> cryptographic binding between CRL and certificates where the >> >>>>>>> certificate and CRL is not signed by the same key. >> >>>>>> >> >>>>>> >> >>>>>> Not really. It is indeed possible to have an absolute >> cryptographic >> >>>>>> binding between CRL and certificates where the certificate and CRL >> >>>>> >> >>> is >> >>> >> >>>> not >> >>>> >> >>>>>> signed by the same key, but the key point is that proposed >> >>>>> >> >>> extension >> >>> >> >>>> >> is *not* the means to provide such a binding (and you agree with >> >>> >> >>> this >> >>> >> >>>> >> further down in this e-mail). >> >>>> >> >>>> >> >>>>> We agree that this extension does not add to the concept of >> >>>>> cryptographic binding. But how do you mean it can be done? >> >>>> >> >>>> >> >>>> Would this mean that you believed this could not be done ? :-) >> >>>> >> >>>> I already provided the information, but since at that time you were >> >>>> focussing on another issue, you probably missed the point. >> >>>> >> >>>> I would encourage you to read again that thread, but I will >> provide a >> >>>> short >> >>>> reply here to your question. >> >>>> >> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains >> >>> >> >>> the >> >>> >> >>>> DN >> >>>> of the CRL Issuer and we all know that CAs are free to assign the >> DNs >> >>> >> >>> they >> >>> >> >>>> wish. The next point is for a verifier to make sure that the DN >> which >> >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was >> >>> >> >>> meant >> >>> >> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same >> >>> >> >>> DN. >> >>> >> >>>> The >> >>>> CRL Issuer will have a certificate issued by a CA. >> >>>> >> >>>> Case a): the CA that has issued that certificate is the same as >> the CA >> >>>> that >> >>>> has issued the target certificate (which contains the hereabove >> >>> >> >>> mentionned >> >>> >> >>>> CRL DP). This is easy to check for a verifier since the verifier >> must >> >>>> first >> >>>> build the certification path and then test the revocation status of >> >>> >> >>> every >> >>> >> >>>> element of the path. So the verifier knows the validated sequence of >> >>> >> >>> DNs >> >>> >> >>>> starting from a self-signed certificate. It must then use the same >> >>>> sequence >> >>>> of DNs to validate the CRL Issuer certificate. >> >>>> >> >>>> This is a general rule which does not require any extra local trust >> >>>> information. >> >>>> >> >>>> Case b) : the CA that has issued that certificate is NOT the same as >> >>> >> >>> the >> >>> >> >>>> CA >> >>>> that has issued the target certificate. This case requires extra >> >>> >> >>> *0local* >> >>> >> >>>> trust information. There are many such trust conditions possible and >> >>> >> >>> thus >> >>> >> >>>> this cannot be defined in general. Cases a) and b) are thus not >> >>> >> >>> equivalent >> >>> >> >>>> and have to be distinguished. >> >>>> >> >>>> >> >>>>> >> >>>> >> >>>> >> >>>>>>> This draft only introduces a new way to locate certificates >> >>>>>>> that can be helpful in building this path. >> >>>>>> >> >>>>>> >> >>>>>> At least one sentence of which we both agree ! >> >>>>>> It should be copied and pasted in the abstract. >> >>>>> >> >>>>> >> >>>>> Good, then I suggest that we leave unrelated topics out of this >> >>>> >> >>> draft >> >>> >> >>>>> and focus on the issues that are related to this limited scope. >> >>>> >> >>>> >> >>>> This is what I did in my proposal, except that we need to have a >> >>> >> >>> security >> >>> >> >>>> considerations section and the goal of that section is not to hide >> >>>> problems >> >>>> but to correctly warn users. Thus why an informatiove annex on the >> >>> >> >>> topics >> >>> >> >>>> mentionned in the security considerations section would be quite >> >>> >> >>> useful. >> >>> >> >>>> In fact, its content would be along the lines of the explanations >> >>> >> >>> which >> >>> >> >>>> are >> >>>> just above. >> >>>> >> >>>> I hope this e-mail will help us to progress. >> >>>> >> >>>> Denis >> >>>> >> >>>> >> >>>>> Stefan Santesson >> >>>>> Program Manager - Standards Liaison >> >>>>> Windows Security >> >>>> >> >> >> >> >> > >> > >> >> >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A709DK089112; Tue, 10 May 2005 00:00:09 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4A709hl089111; Tue, 10 May 2005 00:00:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin.bull.net (odin.bull.net [192.90.70.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A707WS089059 for ; Tue, 10 May 2005 00:00:07 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id JAA16410; Tue, 10 May 2005 09:09:47 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051008595610:22 ; Tue, 10 May 2005 08:59:56 +0200 Message-ID: <42805C27.8090209@bull.net> Date: Tue, 10 May 2005 09:00:55 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: ietf-pkix@imc.org Subject: Re: Comments on References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:59:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:59:58, Serialize complete at 10/05/2005 08:59:58 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, > Denis: > > Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated. > > You say that it is not clear what validation policy needs to be used, > but this is completely irrelevant to the discussion of the CRL AIA > extension. This extension aid in certification path construction, not > the validation of the path once it is constructed. Not exactly, it could "help" finding a wrong path ! > There are many factors which need to be considered in the validation of > the CRL issue certificate. The values of the key usage extension and > the certificate policies extension are two that jump to mind. There are > probably more if I spend the time to consider each possible scenario. One simple rule would allow no security problem at all and I wonder why you have so much resistance to mention it. > In my opinion, this document is ready for WG Last Call. As an editor of the draft, I may understand your position; but it is up the the PKIX chairs to decide whether or not the document is ready for WG last call. Once again the current Security Considerations section is not acceptable. In particular it contains a "MUST" statement that cannot be placed in such a section and which is in addition fully wrong. Hereabove is the last one from draft 01: 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. As means of reducing problems and security issues related to issuer name collisions, CA names SHOULD be formed in a way that reduce the likelihood of name collisions. Implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate, terminate at the same trust anchor. Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Hereafter is a "minimalist" rewriting of this section, if we take the choice to mention the issue, but not to provide any secure solution (mentioning insecure or insufficient solutions is not appropriate). Two sentences have thus been deleted. 3 Security Considerations Implementers should take into account the possible existence of multiple unrelated CAs and CRL issuers with the same name. Implementers should be aware of risks involved if the Authority Information Access extensions of corrupted CRLs contain links to malicious code. Implementers should always take the steps of validating the retrieved data to ensure that the data is properly formed. Denis > Russ > > > At 09:07 AM 5/9/2005, Denis Pinkas wrote: > >> Russ, >> >> > Here is a quote from RFC 3280. To me, it is clear that a CRL issuer >> has >> > a certificate. >> >> True, a CRL issuer (that is different from the CA that has issued the >> target >> certificate) has a certificate. So we both strongly agree on this >> this. :-) >> >> > Obviously, all certificates need to be validated, which >> > includes certification path construction and certification path >> validation. >> >> When a sentence starts with "Obviously", it means that it is not so >> obvious. >> :-| >> >> The real question is whether the CRL issuer certificate has to be >> verified >> using rules (i.e. a validation policy) which are independent from the >> certification path construction of the target certificate. RFC 3280 >> does not >> provide a crystal clear answer to that question. >> >> If the rules are different, then you MAY end up with a security issue >> (see >> my previous explanations). The current "recommendations" that are in the >> security considerations section do NOT solve this issue in the general >> case. >> >> If the rules are the same, i.e. the path used to validate the >> certification >> path from the certificate are also used, then there is no security issue. >> >> I do not think it would be good to hide this issue in the proposed draft. >> Anyway, the current "recommendations" do NOT solve the issue and are >> thus not acceptable and so this section cannot stand as it is. >> >> Denis >> >> > 5.1.1.3 signatureValue >> > >> > The signatureValue field contains a digital signature computed upon >> > the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded >> tbsCertList >> > is used as the input to the signature function. This signature >> value >> > is encoded as a BIT STRING and included in the CRL signatureValue >> > field. The details of this process are specified for each of the >> > supported algorithms in [PKIXALGS]. >> > >> > CAs that are also CRL issuers MAY use one private key to digitally >> > sign certificates and CRLs, or MAY use separate private keys to >> > digitally sign certificates and CRLs. When separate private keys >> are >> > employed, each of the public keys associated with these private keys >> > is placed in a separate certificate, one with the keyCertSign bit >> set >> > in the key usage extension, and one with the cRLSign bit set in the >> > key usage extension (section 4.2.1.3). When separate private keys >> > are employed, certificates issued by the CA contain one authority >> key >> > identifier, and the corresponding CRLs contain a different authority >> > key identifier. The use of separate CA certificates for validation >> > of certificate signatures and CRL signatures can offer improved >> > security characteristics; however, it imposes a burden on >> > applications, and it might limit interoperability. Many >> applications >> > construct a certification path, and then validate the certification >> > path (section 6). CRL checking in turn requires a separate >> > certification path to be constructed and validated for the CA's CRL >> > signature validation certificate. Applications that perform CRL >> > checking MUST support certification path validation when >> certificates >> > and CRLs are digitally signed with the same CA private key. These >> > applications SHOULD support certification path validation when >> > certificates and CRLs are digitally signed with different CA private >> > keys. >> > >> > Russ >> > >> > At 01:12 PM 4/28/2005, Denis Pinkas wrote: >> > >> >> Stefan and Russ, >> >> >> >>> Denis, >> >> >> >> >> >>> Russ and I have taken a thorough look at your text proposal and we >> have >> >>> edited a counter proposal where we try to meet your needs as much as >> >>> possible without compromising what we think is the core purpose of >> the >> >>> draft (to enable certificate discovery bottom-up). >> >> >> >> >> >>> The conclusion is that we suggest changes to the introduction section >> >>> but we keep the old security considerations intact. >> >> >> >> >> >> I would suggest that a merge would need to be done between the "old" >> >> security considerations section and the "new" one. >> >> >> >> The "old" security considerations section is mentionning a solution >> >> which does NOT suppress the problem, but minimize the risk only in >> >> case the CAs are really "honest". >> >> >> >> The old" security considerations section does not provide a solution >> >> in case the name collsion between two CRL issuer name is deliberate, >> >> whereas the "new" security considerations section provides a secure >> >> solution in one case and clearly mentions that all other cases are >> >> dependant about "zillions" of *local* trust conditions which cannot >> >> all be standardized. >> >> >> >> The main purpose of a security considerations section is to provide >> >> the adequate warnings and solutions when they exist and not to hide >> >> the problems. >> >> >> >>> That is not because >> >>> we necessarily disagree with all of the statements in your >> proposal, but >> >>> in the cases we don't, we still think it is out of scope for this >> work. >> >> >> >> >> >> This is clearly within the scope of a security considerations section. >> >> >> >>> The new introduction proposal based on your input is: >> >>> -------------------------------------------------------------- >> >>> RFC 3280 [PKIX1] specifies the validation of certification paths. >> One >> >>> aspect involves the determination that a certificate has not been >> >>> revoked, and one revocation checking mechanism is the Certificate >> >>> Revocation List (CRL). CRL validation is also specified in RFC 3280, >> >> >> >> >> >> I would love this last sentence to be true but the reality is that: >> >> "CRL validation is NOT specified in RFC 3280". :-( >> >> >> >>> which involves the constructions of a valid certification path for >> the >> >>> CRL issuer. >> >> >> >> >> >> There is no such a statement in RFC 3280. >> >> >> >>> Building a CRL issuer certification path from the signer of >> >> >> >> >> >> There is no notion of "CRL issuer certification path" in RFC 3280. >> >> The primary requirement is to make sure that the CRL issuer designated >> >> by the CA is indeed the right one. In some (but not all) cases, I mean >> >> among the zillion of cases, there MAY be a need to construct a CRL >> >> issuer certification path. >> >> >> >>> the CRL to a trust anchor is straightforward when the certificate >> of the >> >>> CRL issuer is present in the certification path associated with the >> >>> target certificate, but it can be complex in other situations. >> >> >> >> >> >> From the comments above, you can see that I cannot agree with the >> >> above revised text. The remaining of the text is acceptable in >> >> general, but could possibly be slightly revised to be more in >> >> continuation with the changes there are needed above (i.e. it is not >> >> cast in concrete). >> >> >> >> Denis >> >> >> >>> There are several legitimate scenarios where the certificate of >> the CRL >> >>> issuer is not present, or easily discovered, from the target >> >>> certification path. This can be the case when indirect CRLs are >> used, >> >>> when the certification Authority (CA) that issued the target >> certificate >> >>> changes its certificate signing key, or when the CA employs separate >> >>> keys for certificate signing and CRL signing. >> >>> Methods of finding the certificate of the CRL issuer are currently >> >>> available, such as though an accessible directory location or through >> >>> use of the Subject Information Access extension in intermediary CA >> >>> certificates. >> >>> Directory lookup requires existence and access to a directory that >> has >> >>> been populated with all of the necessary certificates. The Subject >> >>> Information Access extension, which supports building the CRL issuer >> >>> certification path top-down (in the direction from the trust >> anchor to >> >>> the CRL issuer), requires that some certificates in the CRL issuer >> >>> certification path includes an appropriate Subject Information Access >> >>> extension. >> >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification >> paths >> >>> through the Authority Information Access extension, where the >> >>> id-ad-caIssuers access method may specify one or more accessLocation >> >>> fields that reference CA certificates associated with the certificate >> >>> containing this extension. >> >>> This document enables the use of the Authority Information Access >> >>> extension in CRLs, enabling a CRL checking application to use the >> access >> >>> method (id-ad-caIssuers) to locate certificates that may be useful in >> >>> the construction of a valid CRL issuer certification path to an >> >>> appropriate trust anchor. >> >>> >> >>> Stefan Santesson >> >>> Program Manager, Standards Liaison >> >>> Windows Security >> >>> >> >>> >> >>>> -----Original Message----- >> >>>> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >> >>>> Sent: den 18 april 2005 13:41 >> >>>> To: Stefan Santesson >> >>>> Cc: Russ Housley; pkix >> >>>> Subject: Re: Comments on >> >>>> >> >>>> Stefan, >> >>>> >> >>>> >> >>>>> Denis, >> >>>> >> >>>> >> >>>>> I will come back and comment on your text proposals, but before >> >>>> >> >>> that, >> >>> >> >>>> > a few questions/comments: >> >>>> >> >>>> >> >>>>> >> >>>> >> >>>> >> >>>>>>> You point out some well known issues related to the lack of >> >>>>>> >> >>> absolute >> >>> >> >>>>>>> cryptographic binding between CRL and certificates where the >> >>>>>>> certificate and CRL is not signed by the same key. >> >>>>>> >> >>>>>> >> >>>>>> Not really. It is indeed possible to have an absolute >> cryptographic >> >>>>>> binding between CRL and certificates where the certificate and CRL >> >>>>> >> >>> is >> >>> >> >>>> not >> >>>> >> >>>>>> signed by the same key, but the key point is that proposed >> >>>>> >> >>> extension >> >>> >> >>>> >> is *not* the means to provide such a binding (and you agree with >> >>> >> >>> this >> >>> >> >>>> >> further down in this e-mail). >> >>>> >> >>>> >> >>>>> We agree that this extension does not add to the concept of >> >>>>> cryptographic binding. But how do you mean it can be done? >> >>>> >> >>>> >> >>>> Would this mean that you believed this could not be done ? :-) >> >>>> >> >>>> I already provided the information, but since at that time you were >> >>>> focussing on another issue, you probably missed the point. >> >>>> >> >>>> I would encourage you to read again that thread, but I will >> provide a >> >>>> short >> >>>> reply here to your question. >> >>>> >> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains >> >>> >> >>> the >> >>> >> >>>> DN >> >>>> of the CRL Issuer and we all know that CAs are free to assign the >> DNs >> >>> >> >>> they >> >>> >> >>>> wish. The next point is for a verifier to make sure that the DN >> which >> >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was >> >>> >> >>> meant >> >>> >> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same >> >>> >> >>> DN. >> >>> >> >>>> The >> >>>> CRL Issuer will have a certificate issued by a CA. >> >>>> >> >>>> Case a): the CA that has issued that certificate is the same as >> the CA >> >>>> that >> >>>> has issued the target certificate (which contains the hereabove >> >>> >> >>> mentionned >> >>> >> >>>> CRL DP). This is easy to check for a verifier since the verifier >> must >> >>>> first >> >>>> build the certification path and then test the revocation status of >> >>> >> >>> every >> >>> >> >>>> element of the path. So the verifier knows the validated sequence of >> >>> >> >>> DNs >> >>> >> >>>> starting from a self-signed certificate. It must then use the same >> >>>> sequence >> >>>> of DNs to validate the CRL Issuer certificate. >> >>>> >> >>>> This is a general rule which does not require any extra local trust >> >>>> information. >> >>>> >> >>>> Case b) : the CA that has issued that certificate is NOT the same as >> >>> >> >>> the >> >>> >> >>>> CA >> >>>> that has issued the target certificate. This case requires extra >> >>> >> >>> *0local* >> >>> >> >>>> trust information. There are many such trust conditions possible and >> >>> >> >>> thus >> >>> >> >>>> this cannot be defined in general. Cases a) and b) are thus not >> >>> >> >>> equivalent >> >>> >> >>>> and have to be distinguished. >> >>>> >> >>>> >> >>>>> >> >>>> >> >>>> >> >>>>>>> This draft only introduces a new way to locate certificates >> >>>>>>> that can be helpful in building this path. >> >>>>>> >> >>>>>> >> >>>>>> At least one sentence of which we both agree ! >> >>>>>> It should be copied and pasted in the abstract. >> >>>>> >> >>>>> >> >>>>> Good, then I suggest that we leave unrelated topics out of this >> >>>> >> >>> draft >> >>> >> >>>>> and focus on the issues that are related to this limited scope. >> >>>> >> >>>> >> >>>> This is what I did in my proposal, except that we need to have a >> >>> >> >>> security >> >>> >> >>>> considerations section and the goal of that section is not to hide >> >>>> problems >> >>>> but to correctly warn users. Thus why an informatiove annex on the >> >>> >> >>> topics >> >>> >> >>>> mentionned in the security considerations section would be quite >> >>> >> >>> useful. >> >>> >> >>>> In fact, its content would be along the lines of the explanations >> >>> >> >>> which >> >>> >> >>>> are >> >>>> just above. >> >>>> >> >>>> I hope this e-mail will help us to progress. >> >>>> >> >>>> Denis >> >>>> >> >>>> >> >>>>> Stefan Santesson >> >>>>> Program Manager - Standards Liaison >> >>>>> Windows Security >> >>>> >> >> >> >> >> > >> > >> >> >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6xhTt088921; Mon, 9 May 2005 23:59:43 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4A6xh0I088920; Mon, 9 May 2005 23:59:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin.bull.net (odin.bull.net [192.90.70.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6xfiF088874 for ; Mon, 9 May 2005 23:59:42 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id JAA42264; Tue, 10 May 2005 09:09:20 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051008593076:20 ; Tue, 10 May 2005 08:59:30 +0200 Message-ID: <42805C0D.3030207@bull.net> Date: Tue, 10 May 2005 09:00:29 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: Russ Housley , pkix Subject: Re: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:59:30, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:59:31, Serialize complete at 10/05/2005 08:59:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, > Denis, > I think all arguments have been spoken about this by now. ... but not all replied. > The bottom line is not whether your arguments are right or wrong. It is > that your discussion is out of scope for this draft. > In the end of the day that is the reason why we are reluctant to add > your proposed text in this document. More important, I am requesting the *deletion* of two sentences in the security considerations section. See my response posted to Russ. Denis > Unless you can find others to > support you, you are in clear minority and as such I will not agree to > do any changes. > > I second WG last call for this draft. > > > Stefan Santesson > Program Manager, Standards Liaison > Windows Security > > > >>-----Original Message----- >>From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>Sent: den 9 maj 2005 15:05 >>To: Stefan Santesson >>Cc: Russ Housley; pkix >>Subject: Re: Comments on >> >>Stefan, >> >>I made the e-mail shorter. Your main arguments are the following: >> >> > > ======================================================================== > == > >>[Stefan] But it has to provide a warning to something that is > > introduced > >>by the standard. This standard does not introduce the concept of CRL >>signature checking or CRL issuer certificate validation, so that is >>clearly out of scope. More about that below; >> >>[Denis] See below the last answer and also my arguments in the >>soon-to-be-posted answer to Russ. >> >> > > ======================================================================== > == > >> >> > > RFC 3280 [PKIX1] specifies the validation of certification paths. >> > > One aspect involves the determination that a certificate has not > > been > >> > > revoked, and one revocation checking mechanism is the Certificate >> > > Revocation List (CRL). CRL validation is also specified in RFC > > 3280, > >> > I would love this last sentence to be true but the reality is that: >> > "CRL validation is NOT specified in RFC 3280". :-( >> >>[Stefan] In fact it is. >> >>RFC 3280, Section 6.3.3 CRL processing - on page 85: >> >> (f) Obtain and validate the certification path for the complete > > CRL > >> issuer. If a key usage extension is present in the CRL issuer's >> certificate, verify that the cRLSign bit is set. >> >> (g) Validate the signature on the complete CRL using the public > > key > >> validated in step (f). >> >>[Denis] The text does not say how to obtain and validate the > > certification > >>path for the complete (???) CRL issuer. The text is not clear enough > > so > >>that >>two implementors only looking at this sentence will provide > > interoperable > >>implementations. >> >> > > ======================================================================== > == > >>[Stefan] It is my hope that the provided responses here can help >>convince you to change your mind about that. If it doesn't I still > > argue > >>that the place to specify requirements and security considerations for >>CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. >> >>[Denis] I can agree with your last sentence, ... which means that it >>should >>not be in the main body of the document. In the security > > considerations > >>section, text is free and we shall at the very minimum warn > > implementers > >>and >>we should provide some guidance. When the same certification path > > (i.e. > >>the >>path used to validate the target certificate) is used, then there is > > no > >>security issue: this should be said. For all other cases, there MAY be >>problems: this should also be said. It is as simple as that. >> >>Denis > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6wqv6088629; Mon, 9 May 2005 23:58:52 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4A6wqOH088628; Mon, 9 May 2005 23:58:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin.bull.net (odin.bull.net [192.90.70.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4A6wmMb088568 for ; Mon, 9 May 2005 23:58:49 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin.bull.net (8.9.3/8.9.3) with ESMTP id JAA18358; Tue, 10 May 2005 09:08:28 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005051008583774:19 ; Tue, 10 May 2005 08:58:37 +0200 Message-ID: <42805BD8.4050608@bull.net> Date: Tue, 10 May 2005 08:59:36 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: pkix Subject: Re: Comments on References: <427F6014.1030001@bull.net> <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:58:37, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/05/2005 08:58:39, Serialize complete at 10/05/2005 08:58:39 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, Your statement below is correct, but does not answer to any of my questions/issues. In particular, the last one. I am still awaiting your responses. Denis > Denis: > > RFC 3280 does not tell an implementor how for locate certificates for > any certification path construction. There are several extensions that > provide pointers that may help an implementation, but other approaches > to obtaining the same certificates are always permitted. I would fully > expect an implementation to check any local cache before accessing a > repository. > > The CRL AIA extension fits this pattern. A method for locating a > certificate is provided, but any other mechanism for locating the same > certificate is acceptable. > > Russ > >> Stefan, >> >> I made the e-mail shorter. Your main arguments are the following: >> >> ========================================================================== >> >> >> [Stefan] But it has to provide a warning to something that is introduced >> by the standard. This standard does not introduce the concept of CRL >> signature checking or CRL issuer certificate validation, so that is >> clearly out of scope. More about that below; >> >> [Denis] See below the last answer and also my arguments in the >> soon-to-be-posted answer to Russ. >> >> ========================================================================== >> >> >> >> > > RFC 3280 [PKIX1] specifies the validation of certification paths. >> > > One aspect involves the determination that a certificate has not been >> > > revoked, and one revocation checking mechanism is the Certificate >> > > Revocation List (CRL). CRL validation is also specified in RFC 3280, >> >> > I would love this last sentence to be true but the reality is that: >> > "CRL validation is NOT specified in RFC 3280". :-( >> >> [Stefan] In fact it is. >> >> RFC 3280, Section 6.3.3 CRL processing - on page 85: >> >> (f) Obtain and validate the certification path for the complete CRL >> issuer. If a key usage extension is present in the CRL issuer's >> certificate, verify that the cRLSign bit is set. >> >> (g) Validate the signature on the complete CRL using the public key >> validated in step (f). >> >> [Denis] The text does not say how to obtain and validate the >> certification path for the complete (???) CRL issuer. The text is not >> clear enough so that two implementors only looking at this sentence >> will provide interoperable implementations. >> >> ========================================================================== >> >> >> [Stefan] It is my hope that the provided responses here can help >> convince you to change your mind about that. If it doesn't I still argue >> that the place to specify requirements and security considerations for >> CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. >> >> [Denis] I can agree with your last sentence, ... which means that it >> should not be in the main body of the document. In the security >> considerations section, text is free and we shall at the very minimum >> warn implementers and we should provide some guidance. When the same >> certification path (i.e. the path used to validate the target >> certificate) is used, then there is no security issue: this should be >> said. For all other cases, there MAY be problems: this should also be >> said. It is as simple as that. >> >> Denis >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49NOnoi011377; Mon, 9 May 2005 16:24:49 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49NOnYH011376; Mon, 9 May 2005 16:24:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49NOif0011366 for ; Mon, 9 May 2005 16:24:45 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 00:24:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Comments on Date: Tue, 10 May 2005 00:24:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on Thread-Index: AcVUl9MJMVgI74HMQmuqqLZ8fHOU/wAVNaWg From: "Stefan Santesson" To: "Denis Pinkas" Cc: "Russ Housley" , "pkix" X-OriginalArrivalTime: 09 May 2005 23:24:39.0162 (UTC) FILETIME=[454E0DA0:01C554EE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j49NOjf0011370 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis, I think all arguments have been spoken about this by now. The bottom line is not whether your arguments are right or wrong. It is that your discussion is out of scope for this draft. In the end of the day that is the reason why we are reluctant to add your proposed text in this document. Unless you can find others to support you, you are in clear minority and as such I will not agree to do any changes. I second WG last call for this draft. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > Sent: den 9 maj 2005 15:05 > To: Stefan Santesson > Cc: Russ Housley; pkix > Subject: Re: Comments on > > Stefan, > > I made the e-mail shorter. Your main arguments are the following: > > ======================================================================== == > > [Stefan] But it has to provide a warning to something that is introduced > by the standard. This standard does not introduce the concept of CRL > signature checking or CRL issuer certificate validation, so that is > clearly out of scope. More about that below; > > [Denis] See below the last answer and also my arguments in the > soon-to-be-posted answer to Russ. > > ======================================================================== == > > > > > RFC 3280 [PKIX1] specifies the validation of certification paths. > > > One aspect involves the determination that a certificate has not been > > > revoked, and one revocation checking mechanism is the Certificate > > > Revocation List (CRL). CRL validation is also specified in RFC 3280, > > > I would love this last sentence to be true but the reality is that: > > "CRL validation is NOT specified in RFC 3280". :-( > > [Stefan] In fact it is. > > RFC 3280, Section 6.3.3 CRL processing - on page 85: > > (f) Obtain and validate the certification path for the complete CRL > issuer. If a key usage extension is present in the CRL issuer's > certificate, verify that the cRLSign bit is set. > > (g) Validate the signature on the complete CRL using the public key > validated in step (f). > > [Denis] The text does not say how to obtain and validate the certification > path for the complete (???) CRL issuer. The text is not clear enough so > that > two implementors only looking at this sentence will provide interoperable > implementations. > > ======================================================================== == > > [Stefan] It is my hope that the provided responses here can help > convince you to change your mind about that. If it doesn't I still argue > that the place to specify requirements and security considerations for > CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. > > [Denis] I can agree with your last sentence, ... which means that it > should > not be in the main body of the document. In the security considerations > section, text is free and we shall at the very minimum warn implementers > and > we should provide some guidance. When the same certification path (i.e. > the > path used to validate the target certificate) is used, then there is no > security issue: this should be said. For all other cases, there MAY be > problems: this should also be said. It is as simple as that. > > Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49FWoZD072717; Mon, 9 May 2005 08:32:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49FWoD0072716; Mon, 9 May 2005 08:32:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j49FWnZf072710 for ; Mon, 9 May 2005 08:32:49 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 31850 invoked by uid 0); 9 May 2005 15:31:06 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.5.34) by woodstock.binhost.com with SMTP; 9 May 2005 15:31:06 -0000 Message-Id: <6.2.1.2.2.20050509112536.05e0e7d0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 09 May 2005 11:30:44 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: ietf-pkix@imc.org In-Reply-To: <427F609E.6020309@bull.net> References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> <427F609E.6020309@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: Yes, it is OBVIOUS that the CRL issuer certificate needs to be validated. You say that it is not clear what validation policy needs to be used, but this is completely irrelevant to the discussion of the CRL AIA extension. This extension aid in certification path construction, not the validation of the path once it is constructed. There are many factors which need to be considered in the validation of the CRL issue certificate. The values of the key usage extension and the certificate policies extension are two that jump to mind. There are probably more if I spend the time to consider each possible scenario. In my opinion, this document is ready for WG Last Call. Russ At 09:07 AM 5/9/2005, Denis Pinkas wrote: >Russ, > > > Here is a quote from RFC 3280. To me, it is clear that a CRL issuer has > > a certificate. > >True, a CRL issuer (that is different from the CA that has issued the target >certificate) has a certificate. So we both strongly agree on this this. :-) > > > Obviously, all certificates need to be validated, which > > includes certification path construction and certification path validation. > >When a sentence starts with "Obviously", it means that it is not so obvious. >:-| > >The real question is whether the CRL issuer certificate has to be verified >using rules (i.e. a validation policy) which are independent from the >certification path construction of the target certificate. RFC 3280 does not >provide a crystal clear answer to that question. > >If the rules are different, then you MAY end up with a security issue (see >my previous explanations). The current "recommendations" that are in the >security considerations section do NOT solve this issue in the general case. > >If the rules are the same, i.e. the path used to validate the certification >path from the certificate are also used, then there is no security issue. > >I do not think it would be good to hide this issue in the proposed draft. >Anyway, the current "recommendations" do NOT solve the issue and are thus >not acceptable and so this section cannot stand as it is. > >Denis > > > 5.1.1.3 signatureValue > > > > The signatureValue field contains a digital signature computed upon > > the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList > > is used as the input to the signature function. This signature value > > is encoded as a BIT STRING and included in the CRL signatureValue > > field. The details of this process are specified for each of the > > supported algorithms in [PKIXALGS]. > > > > CAs that are also CRL issuers MAY use one private key to digitally > > sign certificates and CRLs, or MAY use separate private keys to > > digitally sign certificates and CRLs. When separate private keys are > > employed, each of the public keys associated with these private keys > > is placed in a separate certificate, one with the keyCertSign bit set > > in the key usage extension, and one with the cRLSign bit set in the > > key usage extension (section 4.2.1.3). When separate private keys > > are employed, certificates issued by the CA contain one authority key > > identifier, and the corresponding CRLs contain a different authority > > key identifier. The use of separate CA certificates for validation > > of certificate signatures and CRL signatures can offer improved > > security characteristics; however, it imposes a burden on > > applications, and it might limit interoperability. Many applications > > construct a certification path, and then validate the certification > > path (section 6). CRL checking in turn requires a separate > > certification path to be constructed and validated for the CA's CRL > > signature validation certificate. Applications that perform CRL > > checking MUST support certification path validation when certificates > > and CRLs are digitally signed with the same CA private key. These > > applications SHOULD support certification path validation when > > certificates and CRLs are digitally signed with different CA private > > keys. > > > > Russ > > > > At 01:12 PM 4/28/2005, Denis Pinkas wrote: > > > >> Stefan and Russ, > >> > >>> Denis, > >> > >> > >>> Russ and I have taken a thorough look at your text proposal and we have > >>> edited a counter proposal where we try to meet your needs as much as > >>> possible without compromising what we think is the core purpose of the > >>> draft (to enable certificate discovery bottom-up). > >> > >> > >>> The conclusion is that we suggest changes to the introduction section > >>> but we keep the old security considerations intact. > >> > >> > >> I would suggest that a merge would need to be done between the "old" > >> security considerations section and the "new" one. > >> > >> The "old" security considerations section is mentionning a solution > >> which does NOT suppress the problem, but minimize the risk only in > >> case the CAs are really "honest". > >> > >> The old" security considerations section does not provide a solution > >> in case the name collsion between two CRL issuer name is deliberate, > >> whereas the "new" security considerations section provides a secure > >> solution in one case and clearly mentions that all other cases are > >> dependant about "zillions" of *local* trust conditions which cannot > >> all be standardized. > >> > >> The main purpose of a security considerations section is to provide > >> the adequate warnings and solutions when they exist and not to hide > >> the problems. > >> > >>> That is not because > >>> we necessarily disagree with all of the statements in your proposal, but > >>> in the cases we don't, we still think it is out of scope for this work. > >> > >> > >> This is clearly within the scope of a security considerations section. > >> > >>> The new introduction proposal based on your input is: > >>> -------------------------------------------------------------- > >>> RFC 3280 [PKIX1] specifies the validation of certification paths. One > >>> aspect involves the determination that a certificate has not been > >>> revoked, and one revocation checking mechanism is the Certificate > >>> Revocation List (CRL). CRL validation is also specified in RFC 3280, > >> > >> > >> I would love this last sentence to be true but the reality is that: > >> "CRL validation is NOT specified in RFC 3280". :-( > >> > >>> which involves the constructions of a valid certification path for the > >>> CRL issuer. > >> > >> > >> There is no such a statement in RFC 3280. > >> > >>> Building a CRL issuer certification path from the signer of > >> > >> > >> There is no notion of "CRL issuer certification path" in RFC 3280. > >> The primary requirement is to make sure that the CRL issuer designated > >> by the CA is indeed the right one. In some (but not all) cases, I mean > >> among the zillion of cases, there MAY be a need to construct a CRL > >> issuer certification path. > >> > >>> the CRL to a trust anchor is straightforward when the certificate of the > >>> CRL issuer is present in the certification path associated with the > >>> target certificate, but it can be complex in other situations. > >> > >> > >> From the comments above, you can see that I cannot agree with the > >> above revised text. The remaining of the text is acceptable in > >> general, but could possibly be slightly revised to be more in > >> continuation with the changes there are needed above (i.e. it is not > >> cast in concrete). > >> > >> Denis > >> > >>> There are several legitimate scenarios where the certificate of the CRL > >>> issuer is not present, or easily discovered, from the target > >>> certification path. This can be the case when indirect CRLs are used, > >>> when the certification Authority (CA) that issued the target certificate > >>> changes its certificate signing key, or when the CA employs separate > >>> keys for certificate signing and CRL signing. > >>> Methods of finding the certificate of the CRL issuer are currently > >>> available, such as though an accessible directory location or through > >>> use of the Subject Information Access extension in intermediary CA > >>> certificates. > >>> Directory lookup requires existence and access to a directory that has > >>> been populated with all of the necessary certificates. The Subject > >>> Information Access extension, which supports building the CRL issuer > >>> certification path top-down (in the direction from the trust anchor to > >>> the CRL issuer), requires that some certificates in the CRL issuer > >>> certification path includes an appropriate Subject Information Access > >>> extension. > >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths > >>> through the Authority Information Access extension, where the > >>> id-ad-caIssuers access method may specify one or more accessLocation > >>> fields that reference CA certificates associated with the certificate > >>> containing this extension. > >>> This document enables the use of the Authority Information Access > >>> extension in CRLs, enabling a CRL checking application to use the access > >>> method (id-ad-caIssuers) to locate certificates that may be useful in > >>> the construction of a valid CRL issuer certification path to an > >>> appropriate trust anchor. > >>> > >>> Stefan Santesson > >>> Program Manager, Standards Liaison > >>> Windows Security > >>> > >>> > >>>> -----Original Message----- > >>>> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] > >>>> Sent: den 18 april 2005 13:41 > >>>> To: Stefan Santesson > >>>> Cc: Russ Housley; pkix > >>>> Subject: Re: Comments on > >>>> > >>>> Stefan, > >>>> > >>>> > >>>>> Denis, > >>>> > >>>> > >>>>> I will come back and comment on your text proposals, but before > >>>> > >>> that, > >>> > >>>> > a few questions/comments: > >>>> > >>>> > >>>>> > >>>> > >>>> > >>>>>>> You point out some well known issues related to the lack of > >>>>>> > >>> absolute > >>> > >>>>>>> cryptographic binding between CRL and certificates where the > >>>>>>> certificate and CRL is not signed by the same key. > >>>>>> > >>>>>> > >>>>>> Not really. It is indeed possible to have an absolute cryptographic > >>>>>> binding between CRL and certificates where the certificate and CRL > >>>>> > >>> is > >>> > >>>> not > >>>> > >>>>>> signed by the same key, but the key point is that proposed > >>>>> > >>> extension > >>> > >>>> >> is *not* the means to provide such a binding (and you agree with > >>> > >>> this > >>> > >>>> >> further down in this e-mail). > >>>> > >>>> > >>>>> We agree that this extension does not add to the concept of > >>>>> cryptographic binding. But how do you mean it can be done? > >>>> > >>>> > >>>> Would this mean that you believed this could not be done ? :-) > >>>> > >>>> I already provided the information, but since at that time you were > >>>> focussing on another issue, you probably missed the point. > >>>> > >>>> I would encourage you to read again that thread, but I will provide a > >>>> short > >>>> reply here to your question. > >>>> > >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains > >>> > >>> the > >>> > >>>> DN > >>>> of the CRL Issuer and we all know that CAs are free to assign the DNs > >>> > >>> they > >>> > >>>> wish. The next point is for a verifier to make sure that the DN which > >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was > >>> > >>> meant > >>> > >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same > >>> > >>> DN. > >>> > >>>> The > >>>> CRL Issuer will have a certificate issued by a CA. > >>>> > >>>> Case a): the CA that has issued that certificate is the same as the CA > >>>> that > >>>> has issued the target certificate (which contains the hereabove > >>> > >>> mentionned > >>> > >>>> CRL DP). This is easy to check for a verifier since the verifier must > >>>> first > >>>> build the certification path and then test the revocation status of > >>> > >>> every > >>> > >>>> element of the path. So the verifier knows the validated sequence of > >>> > >>> DNs > >>> > >>>> starting from a self-signed certificate. It must then use the same > >>>> sequence > >>>> of DNs to validate the CRL Issuer certificate. > >>>> > >>>> This is a general rule which does not require any extra local trust > >>>> information. > >>>> > >>>> Case b) : the CA that has issued that certificate is NOT the same as > >>> > >>> the > >>> > >>>> CA > >>>> that has issued the target certificate. This case requires extra > >>> > >>> *0local* > >>> > >>>> trust information. There are many such trust conditions possible and > >>> > >>> thus > >>> > >>>> this cannot be defined in general. Cases a) and b) are thus not > >>> > >>> equivalent > >>> > >>>> and have to be distinguished. > >>>> > >>>> > >>>>> > >>>> > >>>> > >>>>>>> This draft only introduces a new way to locate certificates > >>>>>>> that can be helpful in building this path. > >>>>>> > >>>>>> > >>>>>> At least one sentence of which we both agree ! > >>>>>> It should be copied and pasted in the abstract. > >>>>> > >>>>> > >>>>> Good, then I suggest that we leave unrelated topics out of this > >>>> > >>> draft > >>> > >>>>> and focus on the issues that are related to this limited scope. > >>>> > >>>> > >>>> This is what I did in my proposal, except that we need to have a > >>> > >>> security > >>> > >>>> considerations section and the goal of that section is not to hide > >>>> problems > >>>> but to correctly warn users. Thus why an informatiove annex on the > >>> > >>> topics > >>> > >>>> mentionned in the security considerations section would be quite > >>> > >>> useful. > >>> > >>>> In fact, its content would be along the lines of the explanations > >>> > >>> which > >>> > >>>> are > >>>> just above. > >>>> > >>>> I hope this e-mail will help us to progress. > >>>> > >>>> Denis > >>>> > >>>> > >>>>> Stefan Santesson > >>>>> Program Manager - Standards Liaison > >>>>> Windows Security > >>>> > >> > >> > > > > > > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49FWiU8072697; Mon, 9 May 2005 08:32:44 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49FWiSB072696; Mon, 9 May 2005 08:32:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j49FWf22072683 for ; Mon, 9 May 2005 08:32:43 -0700 (PDT) (envelope-from housley@vigilsec.com) Received: (qmail 31827 invoked by uid 0); 9 May 2005 15:31:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.5.34) by woodstock.binhost.com with SMTP; 9 May 2005 15:31:05 -0000 Message-Id: <6.2.1.2.2.20050509111902.05e0c6a0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Mon, 09 May 2005 11:24:15 -0400 To: Denis Pinkas From: Russ Housley Subject: Re: Comments on Cc: pkix In-Reply-To: <427F6014.1030001@bull.net> References: <427F6014.1030001@bull.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Denis: RFC 3280 does not tell an implementor how for locate certificates for any certification path construction. There are several extensions that provide pointers that may help an implementation, but other approaches to obtaining the same certificates are always permitted. I would fully expect an implementation to check any local cache before accessing a repository. The CRL AIA extension fits this pattern. A method for locating a certificate is provided, but any other mechanism for locating the same certificate is acceptable. Russ >Stefan, > >I made the e-mail shorter. Your main arguments are the following: > >========================================================================== > >[Stefan] But it has to provide a warning to something that is introduced >by the standard. This standard does not introduce the concept of CRL >signature checking or CRL issuer certificate validation, so that is >clearly out of scope. More about that below; > >[Denis] See below the last answer and also my arguments in the >soon-to-be-posted answer to Russ. > >========================================================================== > > > > > RFC 3280 [PKIX1] specifies the validation of certification paths. > > > One aspect involves the determination that a certificate has not been > > > revoked, and one revocation checking mechanism is the Certificate > > > Revocation List (CRL). CRL validation is also specified in RFC 3280, > > > I would love this last sentence to be true but the reality is that: > > "CRL validation is NOT specified in RFC 3280". :-( > >[Stefan] In fact it is. > >RFC 3280, Section 6.3.3 CRL processing - on page 85: > > (f) Obtain and validate the certification path for the complete CRL > issuer. If a key usage extension is present in the CRL issuer's > certificate, verify that the cRLSign bit is set. > > (g) Validate the signature on the complete CRL using the public key > validated in step (f). > >[Denis] The text does not say how to obtain and validate the certification >path for the complete (???) CRL issuer. The text is not clear enough so >that two implementors only looking at this sentence will provide >interoperable implementations. > >========================================================================== > >[Stefan] It is my hope that the provided responses here can help >convince you to change your mind about that. If it doesn't I still argue >that the place to specify requirements and security considerations for >CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. > >[Denis] I can agree with your last sentence, ... which means that it >should not be in the main body of the document. In the security >considerations section, text is free and we shall at the very minimum warn >implementers and we should provide some guidance. When the same >certification path (i.e. the path used to validate the target certificate) >is used, then there is no security issue: this should be said. For all >other cases, there MAY be problems: this should also be said. It is as >simple as that. > >Denis > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49D6wap060393; Mon, 9 May 2005 06:06:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49D6wfW060392; Mon, 9 May 2005 06:06:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49D6v6o060347 for ; Mon, 9 May 2005 06:06:57 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA10012; Mon, 9 May 2005 15:21:39 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005050915064398:376 ; Mon, 9 May 2005 15:06:43 +0200 Message-ID: <427F609E.6020309@bull.net> Date: Mon, 09 May 2005 15:07:42 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Russ Housley CC: Stefan Santesson , pkix Subject: Re: Comments on References: <42711979.4030201@bull.net> <6.2.0.14.2.20050429032158.046a1a60@mail.binhost.com> X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/05/2005 15:06:44, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/05/2005 15:06:45, Serialize complete at 09/05/2005 15:06:45 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Russ, > Here is a quote from RFC 3280. To me, it is clear that a CRL issuer has > a certificate. True, a CRL issuer (that is different from the CA that has issued the target certificate) has a certificate. So we both strongly agree on this this. :-) > Obviously, all certificates need to be validated, which > includes certification path construction and certification path validation. When a sentence starts with "Obviously", it means that it is not so obvious. :-| The real question is whether the CRL issuer certificate has to be verified using rules (i.e. a validation policy) which are independent from the certification path construction of the target certificate. RFC 3280 does not provide a crystal clear answer to that question. If the rules are different, then you MAY end up with a security issue (see my previous explanations). The current "recommendations" that are in the security considerations section do NOT solve this issue in the general case. If the rules are the same, i.e. the path used to validate the certification path from the certificate are also used, then there is no security issue. I do not think it would be good to hide this issue in the proposed draft. Anyway, the current "recommendations" do NOT solve the issue and are thus not acceptable and so this section cannot stand as it is. Denis > 5.1.1.3 signatureValue > > The signatureValue field contains a digital signature computed upon > the ASN.1 DER encoded tbsCertList. The ASN.1 DER encoded tbsCertList > is used as the input to the signature function. This signature value > is encoded as a BIT STRING and included in the CRL signatureValue > field. The details of this process are specified for each of the > supported algorithms in [PKIXALGS]. > > CAs that are also CRL issuers MAY use one private key to digitally > sign certificates and CRLs, or MAY use separate private keys to > digitally sign certificates and CRLs. When separate private keys are > employed, each of the public keys associated with these private keys > is placed in a separate certificate, one with the keyCertSign bit set > in the key usage extension, and one with the cRLSign bit set in the > key usage extension (section 4.2.1.3). When separate private keys > are employed, certificates issued by the CA contain one authority key > identifier, and the corresponding CRLs contain a different authority > key identifier. The use of separate CA certificates for validation > of certificate signatures and CRL signatures can offer improved > security characteristics; however, it imposes a burden on > applications, and it might limit interoperability. Many applications > construct a certification path, and then validate the certification > path (section 6). CRL checking in turn requires a separate > certification path to be constructed and validated for the CA's CRL > signature validation certificate. Applications that perform CRL > checking MUST support certification path validation when certificates > and CRLs are digitally signed with the same CA private key. These > applications SHOULD support certification path validation when > certificates and CRLs are digitally signed with different CA private > keys. > > Russ > > At 01:12 PM 4/28/2005, Denis Pinkas wrote: > >> Stefan and Russ, >> >>> Denis, >> >> >>> Russ and I have taken a thorough look at your text proposal and we have >>> edited a counter proposal where we try to meet your needs as much as >>> possible without compromising what we think is the core purpose of the >>> draft (to enable certificate discovery bottom-up). >> >> >>> The conclusion is that we suggest changes to the introduction section >>> but we keep the old security considerations intact. >> >> >> I would suggest that a merge would need to be done between the "old" >> security considerations section and the "new" one. >> >> The "old" security considerations section is mentionning a solution >> which does NOT suppress the problem, but minimize the risk only in >> case the CAs are really "honest". >> >> The old" security considerations section does not provide a solution >> in case the name collsion between two CRL issuer name is deliberate, >> whereas the "new" security considerations section provides a secure >> solution in one case and clearly mentions that all other cases are >> dependant about "zillions" of *local* trust conditions which cannot >> all be standardized. >> >> The main purpose of a security considerations section is to provide >> the adequate warnings and solutions when they exist and not to hide >> the problems. >> >>> That is not because >>> we necessarily disagree with all of the statements in your proposal, but >>> in the cases we don't, we still think it is out of scope for this work. >> >> >> This is clearly within the scope of a security considerations section. >> >>> The new introduction proposal based on your input is: >>> -------------------------------------------------------------- >>> RFC 3280 [PKIX1] specifies the validation of certification paths. One >>> aspect involves the determination that a certificate has not been >>> revoked, and one revocation checking mechanism is the Certificate >>> Revocation List (CRL). CRL validation is also specified in RFC 3280, >> >> >> I would love this last sentence to be true but the reality is that: >> "CRL validation is NOT specified in RFC 3280". :-( >> >>> which involves the constructions of a valid certification path for the >>> CRL issuer. >> >> >> There is no such a statement in RFC 3280. >> >>> Building a CRL issuer certification path from the signer of >> >> >> There is no notion of "CRL issuer certification path" in RFC 3280. >> The primary requirement is to make sure that the CRL issuer designated >> by the CA is indeed the right one. In some (but not all) cases, I mean >> among the zillion of cases, there MAY be a need to construct a CRL >> issuer certification path. >> >>> the CRL to a trust anchor is straightforward when the certificate of the >>> CRL issuer is present in the certification path associated with the >>> target certificate, but it can be complex in other situations. >> >> >> From the comments above, you can see that I cannot agree with the >> above revised text. The remaining of the text is acceptable in >> general, but could possibly be slightly revised to be more in >> continuation with the changes there are needed above (i.e. it is not >> cast in concrete). >> >> Denis >> >>> There are several legitimate scenarios where the certificate of the CRL >>> issuer is not present, or easily discovered, from the target >>> certification path. This can be the case when indirect CRLs are used, >>> when the certification Authority (CA) that issued the target certificate >>> changes its certificate signing key, or when the CA employs separate >>> keys for certificate signing and CRL signing. >>> Methods of finding the certificate of the CRL issuer are currently >>> available, such as though an accessible directory location or through >>> use of the Subject Information Access extension in intermediary CA >>> certificates. >>> Directory lookup requires existence and access to a directory that has >>> been populated with all of the necessary certificates. The Subject >>> Information Access extension, which supports building the CRL issuer >>> certification path top-down (in the direction from the trust anchor to >>> the CRL issuer), requires that some certificates in the CRL issuer >>> certification path includes an appropriate Subject Information Access >>> extension. >>> RFC 3280 [PKIX1] provides for bottom-up discovery of certification paths >>> through the Authority Information Access extension, where the >>> id-ad-caIssuers access method may specify one or more accessLocation >>> fields that reference CA certificates associated with the certificate >>> containing this extension. >>> This document enables the use of the Authority Information Access >>> extension in CRLs, enabling a CRL checking application to use the access >>> method (id-ad-caIssuers) to locate certificates that may be useful in >>> the construction of a valid CRL issuer certification path to an >>> appropriate trust anchor. >>> >>> Stefan Santesson >>> Program Manager, Standards Liaison >>> Windows Security >>> >>> >>>> -----Original Message----- >>>> From: Denis Pinkas [mailto:Denis.Pinkas@bull.net] >>>> Sent: den 18 april 2005 13:41 >>>> To: Stefan Santesson >>>> Cc: Russ Housley; pkix >>>> Subject: Re: Comments on >>>> >>>> Stefan, >>>> >>>> >>>>> Denis, >>>> >>>> >>>>> I will come back and comment on your text proposals, but before >>>> >>> that, >>> >>>> > a few questions/comments: >>>> >>>> >>>>> >>>> >>>> >>>>>>> You point out some well known issues related to the lack of >>>>>> >>> absolute >>> >>>>>>> cryptographic binding between CRL and certificates where the >>>>>>> certificate and CRL is not signed by the same key. >>>>>> >>>>>> >>>>>> Not really. It is indeed possible to have an absolute cryptographic >>>>>> binding between CRL and certificates where the certificate and CRL >>>>> >>> is >>> >>>> not >>>> >>>>>> signed by the same key, but the key point is that proposed >>>>> >>> extension >>> >>>> >> is *not* the means to provide such a binding (and you agree with >>> >>> this >>> >>>> >> further down in this e-mail). >>>> >>>> >>>>> We agree that this extension does not add to the concept of >>>>> cryptographic binding. But how do you mean it can be done? >>>> >>>> >>>> Would this mean that you believed this could not be done ? :-) >>>> >>>> I already provided the information, but since at that time you were >>>> focussing on another issue, you probably missed the point. >>>> >>>> I would encourage you to read again that thread, but I will provide a >>>> short >>>> reply here to your question. >>>> >>>> This can be done using cRLIssuer from the CRL DP. cRLIssuer contains >>> >>> the >>> >>>> DN >>>> of the CRL Issuer and we all know that CAs are free to assign the DNs >>> >>> they >>> >>>> wish. The next point is for a verifier to make sure that the DN which >>>> identifies the CRL Issuer (in the CRL DP) is indeed the one that was >>> >>> meant >>> >>>> by the CA. The CRL must be issued by a CRL Issuer that has the same >>> >>> DN. >>> >>>> The >>>> CRL Issuer will have a certificate issued by a CA. >>>> >>>> Case a): the CA that has issued that certificate is the same as the CA >>>> that >>>> has issued the target certificate (which contains the hereabove >>> >>> mentionned >>> >>>> CRL DP). This is easy to check for a verifier since the verifier must >>>> first >>>> build the certification path and then test the revocation status of >>> >>> every >>> >>>> element of the path. So the verifier knows the validated sequence of >>> >>> DNs >>> >>>> starting from a self-signed certificate. It must then use the same >>>> sequence >>>> of DNs to validate the CRL Issuer certificate. >>>> >>>> This is a general rule which does not require any extra local trust >>>> information. >>>> >>>> Case b) : the CA that has issued that certificate is NOT the same as >>> >>> the >>> >>>> CA >>>> that has issued the target certificate. This case requires extra >>> >>> *0local* >>> >>>> trust information. There are many such trust conditions possible and >>> >>> thus >>> >>>> this cannot be defined in general. Cases a) and b) are thus not >>> >>> equivalent >>> >>>> and have to be distinguished. >>>> >>>> >>>>> >>>> >>>> >>>>>>> This draft only introduces a new way to locate certificates >>>>>>> that can be helpful in building this path. >>>>>> >>>>>> >>>>>> At least one sentence of which we both agree ! >>>>>> It should be copied and pasted in the abstract. >>>>> >>>>> >>>>> Good, then I suggest that we leave unrelated topics out of this >>>> >>> draft >>> >>>>> and focus on the issues that are related to this limited scope. >>>> >>>> >>>> This is what I did in my proposal, except that we need to have a >>> >>> security >>> >>>> considerations section and the goal of that section is not to hide >>>> problems >>>> but to correctly warn users. Thus why an informatiove annex on the >>> >>> topics >>> >>>> mentionned in the security considerations section would be quite >>> >>> useful. >>> >>>> In fact, its content would be along the lines of the explanations >>> >>> which >>> >>>> are >>>> just above. >>>> >>>> I hope this e-mail will help us to progress. >>>> >>>> Denis >>>> >>>> >>>>> Stefan Santesson >>>>> Program Manager - Standards Liaison >>>>> Windows Security >>>> >> >> > > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49D4wGj059644; Mon, 9 May 2005 06:04:58 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j49D4w27059643; Mon, 9 May 2005 06:04:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49D4uQN059593 for ; Mon, 9 May 2005 06:04:57 -0700 (PDT) (envelope-from Denis.Pinkas@bull.net) Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA06584; Mon, 9 May 2005 15:19:22 +0200 Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005050915042621:374 ; Mon, 9 May 2005 15:04:26 +0200 Message-ID: <427F6014.1030001@bull.net> Date: Mon, 09 May 2005 15:05:24 +0200 From: Denis Pinkas Organization: Bull SA. User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en, fr MIME-Version: 1.0 To: Stefan Santesson CC: Russ Housley , pkix Subject: Re: Comments on References: X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/05/2005 15:04:26, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 09/05/2005 15:04:31, Serialize complete at 09/05/2005 15:04:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan, I made the e-mail shorter. Your main arguments are the following: ========================================================================== [Stefan] But it has to provide a warning to something that is introduced by the standard. This standard does not introduce the concept of CRL signature checking or CRL issuer certificate validation, so that is clearly out of scope. More about that below; [Denis] See below the last answer and also my arguments in the soon-to-be-posted answer to Russ. ========================================================================== > > RFC 3280 [PKIX1] specifies the validation of certification paths. > > One aspect involves the determination that a certificate has not been > > revoked, and one revocation checking mechanism is the Certificate > > Revocation List (CRL). CRL validation is also specified in RFC 3280, > I would love this last sentence to be true but the reality is that: > "CRL validation is NOT specified in RFC 3280". :-( [Stefan] In fact it is. RFC 3280, Section 6.3.3 CRL processing - on page 85: (f) Obtain and validate the certification path for the complete CRL issuer. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set. (g) Validate the signature on the complete CRL using the public key validated in step (f). [Denis] The text does not say how to obtain and validate the certification path for the complete (???) CRL issuer. The text is not clear enough so that two implementors only looking at this sentence will provide interoperable implementations. ========================================================================== [Stefan] It is my hope that the provided responses here can help convince you to change your mind about that. If it doesn't I still argue that the place to specify requirements and security considerations for CRL validation is RFC 3280 and 3280bis and not the AIA in CRL draft. [Denis] I can agree with your last sentence, ... which means that it should not be in the main body of the document. In the security considerations section, text is free and we shall at the very minimum warn implementers and we should provide some guidance. When the same certification path (i.e. the path used to validate the target certificate) is used, then there is no security issue: this should be said. For all other cases, there MAY be problems: this should also be said. It is as simple as that. Denis Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j470K0Fe086605; Fri, 6 May 2005 17:20:00 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j470K0UZ086604; Fri, 6 May 2005 17:20:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j470JxRL086577 for ; Fri, 6 May 2005 17:19:59 -0700 (PDT) (envelope-from rfc-ed@ISI.EDU) Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j470Ig626566; Fri, 6 May 2005 17:18:42 -0700 (PDT) Message-Id: <200505070018.j470Ig626566@boreas.isi.edu> To: ietf-announce@ietf.org Subject: RFC 4059 on Internet X.509 Public Key Infrastructure Warranty Certificate Extension Cc: rfc-editor@rfc-editor.org, ietf-pkix@imc.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 06 May 2005 17:18:42 -0700 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4059 Title: Internet X.509 Public Key Infrastructure Warranty Certificate Extension Author(s): D. Linsenbardt, S. Pontius, A. Sturgeon Status: Informational Date: May 2005 Mailbox: dlinsenbardt@spyrus.com, spontius@spyrus.com, asturgeon@spyrus.com Pages: 9 Characters: 17904 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pkix-warranty-extn-04.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4059.txt This document describes a certificate extension to explicitly state the warranty offered by a Certificate Authority (CA) for the certificate containing the extension. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050506171655.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4059 --OtherAccess Content-Type: Message/External-body; name="rfc4059.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050506171655.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46F1jok094276; Fri, 6 May 2005 08:01:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j46F1jQF094275; Fri, 6 May 2005 08:01:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46F1h6q094240 for ; Fri, 6 May 2005 08:01:44 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 16:01:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC3280bis: policy processing. Date: Fri, 6 May 2005 16:01:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3280bis: policy processing. Thread-Index: AcVSOvZ7kjZdkgoCRm+Z4EYVCYta0QAEKasw From: "Stefan Santesson" To: "David A. Cooper" Cc: "pkix" X-OriginalArrivalTime: 06 May 2005 15:01:37.0786 (UTC) FILETIME=[80904DA0:01C5524C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j46F1i6q094261 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Thanks David, you are absolutely right. This property just slipped my mind for a moment. Stefan Santesson Program Manager, Standards Liaison Windows Security   ________________________________________ From: David A. Cooper [mailto:david.cooper@nist.gov] Sent: den 6 maj 2005 14:53 To: Stefan Santesson Cc: pkix Subject: Re: RFC3280bis: policy processing. Stefan Santesson wrote: David, Another aspect of this strikes me. That is what happens when a policy mapping extension maps from one issuer domain policy to several subject domain policies. The text in X.509 has noticed the need to duplicate the row (node in RFC 3280) for the issuer domain policy to accommodate both mappings. Reading this corresponding text from RFC 3280 it seems that the corresponding creation of a new node is not specified in RFC 3280 which would result in the same node being overwritten twice with a new subject domain policy, resulting in a loss of the first mapping. Unless I misread this, this seems to be a bug that we do need to fix. Stefan, In RFC 3280, this is addressed by maintaining, within a single node, the set of policies that appear as subject domain policies for a given issuerDomainPolicy (the expected_policy_set): 6.1.4  Preparation for Certificate i+1    To prepare for processing of certificate i+1, perform the following    steps for certificate i:       (b)  If a policy mappings extension is present, then for each       issuerDomainPolicy ID-P in the policy mappings extension:          (1)  If the policy_mapping variable is greater than 0, for each          node in the valid_policy_tree of depth i where ID-P is the          valid_policy, set expected_policy_set to the set of          subjectDomainPolicy values that are specified as equivalent to          ID-P by the policy mappings extension. Take, for example figure 6 from RFC 3280:                           +-----------------+                           |      Red        |                           +-----------------+                           |       {}        |                           +-----------------+ node of depth i-1                           |  {Gold, Silver} |                           +-----------------+                              /           \                             /             \                            /               \                           /                 \             +-----------------+          +-----------------+             |      Gold       |          |     Silver      |             +-----------------+          +-----------------+             |       {}        |          |       {}        |             +-----------------+ nodes of +-----------------+             |     {Gold}      | depth i  |    {Silver}     |             +-----------------+          +-----------------+          Figure 6.  Processing unmatched policies when the certificate          policies extension specifies anyPolicy This subtree would be created as a result of: certificate i-1: certificatePolicies:  Red policyMappings:     issuerDomainPolicy: Red     subjectDomainPolicy: Gold     issuerDomainPolicy: Red     subjectDomainPolicy: Silver certificate i: certificatePolicies: Gold, Silver Dave Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46CuT63067316; Fri, 6 May 2005 05:56:29 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j46CuThN067315; Fri, 6 May 2005 05:56:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from relay1.mail.uk.clara.net (relay1.mail.uk.clara.net [80.168.70.141]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46CuS12067292 for ; Fri, 6 May 2005 05:56:28 -0700 (PDT) (envelope-from lists@drh-consultancy.demon.co.uk) Received: from future-is.orange.co.uk ([193.35.129.169] helo=[10.40.179.196]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.46) id 1DU2NV-000BDC-GF; Fri, 06 May 2005 13:56:26 +0100 Message-ID: <427B6965.60901@drh-consultancy.demon.co.uk> Date: Fri, 06 May 2005 13:56:05 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Santesson CC: "David A. Cooper" , pkix Subject: Re: RFC3280bis: policy processing. References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Stefan Santesson wrote: > David, > > Another aspect of this strikes me. > > That is what happens when a policy mapping extension maps from one > issuer domain policy to several subject domain policies. > > The text in X.509 has noticed the need to duplicate the row (node in RFC > 3280) for the issuer domain policy to accommodate both mappings. > > Reading this corresponding text from RFC 3280 it seems that the > corresponding creation of a new node is not specified in RFC 3280 which > would result in the same node being overwritten twice with a new subject > domain policy, resulting in a loss of the first mapping. > > Unless I misread this, this seems to be a bug that we do need to fix. > I believe this is the same issue (albeit from a different direction) I queried before in this thread on 22 November last year. Steve. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46Csj0b066483; Fri, 6 May 2005 05:54:45 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j46Csj3i066481; Fri, 6 May 2005 05:54:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j46CsgOu066456 for ; Fri, 6 May 2005 05:54:44 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j46CqQa9004027; Fri, 6 May 2005 08:52:26 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j46Cpn9q023053; Fri, 6 May 2005 08:51:50 -0400 (EDT) Message-ID: <427B68A8.1040205@nist.gov> Date: Fri, 06 May 2005 08:52:56 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stefan Santesson CC: pkix Subject: Re: RFC3280bis: policy processing. References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030500040500090801030508" X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------030500040500090801030508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Stefan Santesson wrote: >David, > >Another aspect of this strikes me. > >That is what happens when a policy mapping extension maps from one >issuer domain policy to several subject domain policies. > >The text in X.509 has noticed the need to duplicate the row (node in RFC >3280) for the issuer domain policy to accommodate both mappings. > >Reading this corresponding text from RFC 3280 it seems that the >corresponding creation of a new node is not specified in RFC 3280 which >would result in the same node being overwritten twice with a new subject >domain policy, resulting in a loss of the first mapping. > >Unless I misread this, this seems to be a bug that we do need to fix. > > Stefan, In RFC 3280, this is addressed by maintaining, within a single node, the set of policies that appear as subject domain policies for a given issuerDomainPolicy (the expected_policy_set): 6.1.4 Preparation for Certificate i+1 To prepare for processing of certificate i+1, perform the following steps for certificate i: (b) If a policy mappings extension is present, then for each issuerDomainPolicy ID-P in the policy mappings extension: (1) If the policy_mapping variable is greater than 0, for each node in the valid_policy_tree of depth i where ID-P is the valid_policy, set expected_policy_set to the set of subjectDomainPolicy values that are specified as equivalent to ID-P by the policy mappings extension. Take, for example figure 6 from RFC 3280: +-----------------+ | Red | +-----------------+ | {} | +-----------------+ node of depth i-1 | {Gold, Silver} | +-----------------+ / \ / \ / \ / \ +-----------------+ +-----------------+ | Gold | | Silver | +-----------------+ +-----------------+ | {} | | {} | +-----------------+ nodes of +-----------------+ | {Gold} | depth i | {Silver} | +-----------------+ +-----------------+ Figure 6. Processing unmatched policies when the certificate policies extension specifies anyPolicy This subtree would be created as a result of: _certificate i-1_: certificatePolicies: Red policyMappings: issuerDomainPolicy: Red subjectDomainPolicy: Gold issuerDomainPolicy: Red subjectDomainPolicy: Silver _ certificate i_: certificatePolicies: Gold, Silver Dave --------------030500040500090801030508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Stefan Santesson wrote: 
David,

Another aspect of this strikes me.

That is what happens when a policy mapping extension maps from one
issuer domain policy to several subject domain policies.

The text in X.509 has noticed the need to duplicate the row (node in RFC
3280) for the issuer domain policy to accommodate both mappings.

Reading this corresponding text from RFC 3280 it seems that the
corresponding creation of a new node is not specified in RFC 3280 which
would result in the same node being overwritten twice with a new subject
domain policy, resulting in a loss of the first mapping.

Unless I misread this, this seems to be a bug that we do need to fix.

Stefan,

In RFC 3280, this is addressed by maintaining, within a single node, the set of policies that appear as subject domain policies for a given issuerDomainPolicy (the expected_policy_set):
6.1.4  Preparation for Certificate i+1

   To prepare for processing of certificate i+1, perform the following
   steps for certificate i:

      (b)  If a policy mappings extension is present, then for each
      issuerDomainPolicy ID-P in the policy mappings extension:

         (1)  If the policy_mapping variable is greater than 0, for each
         node in the valid_policy_tree of depth i where ID-P is the
         valid_policy, set expected_policy_set to the set of
         subjectDomainPolicy values that are specified as equivalent to
         ID-P by the policy mappings extension.
Take, for example figure 6 from RFC 3280:
                          +-----------------+
                          |      Red        |
                          +-----------------+
                          |       {}        |
                          +-----------------+ node of depth i-1
                          |  {Gold, Silver} |
                          +-----------------+
                             /           \
                            /             \
                           /               \
                          /                 \
            +-----------------+          +-----------------+
            |      Gold       |          |     Silver      |
            +-----------------+          +-----------------+
            |       {}        |          |       {}        |
            +-----------------+ nodes of +-----------------+
            |     {Gold}      | depth i  |    {Silver}     |
            +-----------------+          +-----------------+

         Figure 6.  Processing unmatched policies when the certificate
         policies extension specifies anyPolicy
This subtree would be created as a result of:

certificate i-1:
certificatePolicies:  Red
policyMappings:
    issuerDomainPolicy: Red
    subjectDomainPolicy: Gold

    issuerDomainPolicy: Red
    subjectDomainPolicy: Silver

certificate i:
certificatePolicies: Gold, Silver



Dave
--------------030500040500090801030508-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j468cBWq059189; Fri, 6 May 2005 01:38:11 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j468cBUS059188; Fri, 6 May 2005 01:38:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j468c9OZ059141 for ; Fri, 6 May 2005 01:38:09 -0700 (PDT) (envelope-from stefans@microsoft.com) Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 May 2005 09:38:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC3280bis: policy processing. Date: Fri, 6 May 2005 09:38:06 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC3280bis: policy processing. Thread-Index: AcVQ5joX8lJSC3shRF6u2SbO1EJWVABLvLiw From: "Stefan Santesson" To: "David A. Cooper" , "Stephen Henson" Cc: "pkix" X-OriginalArrivalTime: 06 May 2005 08:38:03.0779 (UTC) FILETIME=[EB258530:01C55216] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j468cAOZ059179 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: David, Another aspect of this strikes me. That is what happens when a policy mapping extension maps from one issuer domain policy to several subject domain policies. The text in X.509 has noticed the need to duplicate the row (node in RFC 3280) for the issuer domain policy to accommodate both mappings. Reading this corresponding text from RFC 3280 it seems that the corresponding creation of a new node is not specified in RFC 3280 which would result in the same node being overwritten twice with a new subject domain policy, resulting in a loss of the first mapping. Unless I misread this, this seems to be a bug that we do need to fix. Stefan Santesson Program Manager, Standards Liaison Windows Security > -----Original Message----- > From: owner-ietf-pkix@mail.imc.org [mailto:owner-ietf-pkix@mail.imc.org] > On Behalf Of David A. Cooper > Sent: den 4 maj 2005 21:20 > To: Stephen Henson > Cc: pkix > Subject: Re: RFC3280bis: policy processing. > > Steve, > > A few of the members of the design team spent some time reviewing the > issue that you brought up below. We agree that X.509 and RFC 3280 > differ as you describe and that in some circumstances the outputs of the > algorithms could differ. However, we do not believe that the > differences in the two algorithms will result in different outcomes in > any realistic scenarios and so we do not believe that it is necessary to > change 3280bis to align with X.509. > > An example of where X.509 and RFC 3280 could produce different results > is shown in "X509vsRFC3280_policyMappings.pdf" (attached). Pages 1 and > 2 describe Certification Path 1 and the steps that would result from > processing this certification path under X.509. Under X.509 the output > consists of a authorities-constrained-policy-set of {1, 2} whereas under > RFC 3280 the authorities-constrained-policy-set would be {1}. Note > however, that the first certificate in the path include a policyMappings > extension that maps from policy 1 to policy 2. So, the outcome of path > validation would effectively be the same in either case unless the > user-initial-policy-set included the subjectDomainPolicy from the policy > mapping (2), but not the issuerDomainPolicy (1). This seem unlikely. > On page 3, Certification Path 2 demonstrates that RFC 3280 would get the > same result as X.509 if the first certificate in the certification path > explicitly asserted policy 2 in addition to asserting policy 1. > > As shown in "MorePolicyMappingOddities.pdf", it turns out that a number > of unusual things can happen when the policyMappings extension is > included in a certificate that also asserts anyPolicy. These oddities > occur in both X.509 and RFC 3280. But, as before, they would only > result in a different outcome for path validation if the > user-initial-policy-set asserted a policy that appeared as a > subjectDomainPolicy in the policyMappings extension but did not assert > the corresponding issuerDomainPolicy. So, while the results are > unusual, it does not seem that it is necessary to make any changes to > the algorithm. > > Dave > > Stephen Henson wrote: > > > While I was checking the X509 policy processing against the RFC3280 > > version I've noticed what I believe to be a discrepancy between the two. > > > > In RFC3280 the policy mapping processing is described in 6.1.4 b(1) as: > > > >> (1) If the policy_mapping variable is greater than 0, for each node > >> in the valid_policy_tree of depth i where ID-P is the valid_policy, > >> set expected_policy_set to the set of subjectDomainPolicy values that > >> are specified as equivalent to ID-P by the policy mapping extension. > >> > >> If no node of depth i in the valid_policy_tree has a valid_policy of > >> ID-P but there is a node of depth i with a valid_policy of anyPolicy, > >> then generate a child node of the node of depth i-1 that has a > >> valid_policy of anyPolicy as follows: > > > > Whereas the corresponding text in X509 is in 10.5.2 d): > > > >> process any policy mappings extension by, for each mapping identified > >> in the extension, locate all rows in the > >> authorities-constrained-policy-set table whose [path-depth] column > >> entry is equal to the issuer domain policy value in the extension, > >> and write the subject domain policy value from the extension in the > >> [path-depth+1] column entry of the same row. If the extension maps an > >> issuer domain policy to more than one subject domain policy, then the > >> affected row must be copied and the new entry added to each row. If > >> the value in authoritiesconstrained- policy-set[0, path-depth] is > >> any-policy, then write each issuer domain policy identifier from the > >> policy mappings extension in the [path-depth] column, making > >> duplicate rows as necessary and retaining qualifiers if they are > >> present, and write the subject domain policy value from the extension > >> in the [pathdepth+ 1] column entry of the same row. > > > > > > Translating this into RFC3280 terms it appears the processing of > > anyPolicy is different. > > > > In RFC3280 a new node is added only if a node of depth i doesn't exist > > with a valid policy of ID-P. > > > > In X509 it appears to be saying a new node is added unconditionally. > > > > I believe this difference could result in different outputs from the > > algorithm. In particular the X509 processing will (significantly) > > result in nodes whose parent is anyPolicy which will not appear in the > > RFC3280 version. > > > > Steve. > Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j457Soja053458; Thu, 5 May 2005 00:28:50 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j457SoiR053456; Thu, 5 May 2005 00:28:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtpauth03.mail.atl.earthlink.net (smtpauth03.mail.atl.earthlink.net [209.86.89.63]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j457SoZJ053445 for ; Thu, 5 May 2005 00:28:50 -0700 (PDT) (envelope-from hoytkesterson@earthlink.net) Received: from [130.13.81.218] (helo=[192.168.0.4]) by smtpauth03.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1DTamn-0001Zc-6O; Thu, 05 May 2005 03:28:49 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=test1; d=earthlink.net; h=Mime-Version:Message-Id:Date:To:From:Subject:Content-Type; b=MKVMfi8oLTbBdw1uGdivP9dFxPwGH0X9AS4JTUiRrfjgqgWHCHB9ivhi2gSsnKAk; Mime-Version: 1.0 Message-Id: Date: Thu, 5 May 2005 00:10:26 -0700 To: "X.509":; From: "Hoyt L. Kesterson II" Subject: Defect reports against X.509 Content-Type: text/html; charset="us-ascii" X-ELNK-Trace: 59f3edefb26af0321a6f9084d36cbc6474bf435c0eb9d47874241ab66785ff6de41cf0f164e7efc3a7069264c324fa7c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.13.81.218 Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Defect reports against X.509
Hello

I have posted two defect reports on the server

DR 310 - Unrecognized CRL and CRL entry extensions
DR 311 - Differences between crl and crl entry extensions

The DRs can be found at

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_310.pdf

ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/DefectReports/X.509andRelated/DR_311.pdf

I plan to submit these solutions in DTCs, within the next four weeks, for formal voting in ISO. If there are any concerns about the proposed solutions, please let me know as soon as possible so any necessary modifications can be made before submitting for ballot.

   hoyt

Received: from modemcable104.177-81-70.mc.videotron.ca (modemcable104.177-81-70.mc.videotron.ca [70.81.177.104]) by above.proper.com (8.12.11/8.12.9) with SMTP id j44Lu9ik016448; Wed, 4 May 2005 14:56:53 -0700 (PDT) (envelope-from TCUTKZSNBMM@juno.com) X-Message-Info: 7nlmvka5050ecuLPD/jsUGLhjWWfwHVnotBL6CKqvk Received: from compliment (78.134.114.110) by i5.flaw.mossy.dispel.att.net (InterMail vG.6.37.27.23 3-3-27-1161-411-6880663) with ESMTP id <6882599043.RTLO4809.ntmk740-mail.crumple.anthracite.net.cable.rogers.com@alsatian> for ; Wed, 04 May 2005 19:53:51 -0300 Message-ID: <71010pwc9x$3445976vov2$44236i960si8@bump> Reply-To: "Corrine Holley" From: "Corrine Holley" To: Subject: In the site you can get cheep mads charon Date: Wed, 04 May 2005 21:48:51 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--PEMFH87531007MMVB" ----PEMFH87531007MMVB Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Our site is all about high quallity cheep-pr1ce errection meddicatioons. If you want it, we can give it to you. Bast and cheepest mads available in our online site. you won't stop screewing after you use it, for sure :) Come to see by yourself: http://longue.felsjkdbm.com/?GLcZcbGiqKhuSaGmanuel society for historical archaeology website contains links to contents of monographs papers and the journal australasian journal of historical archaeology and complete issues of the. from nick greene your guide to space and astronomy a new e-mail course on developing science fair projects great science fair pr ojects. the main new feature is the ability to add delete and edit multiple templates in manila using only your web browser and your brain. this is very interesting there are more and more manila sites created by net developers here s. information and up-to-date programs of the frankfurt opera frankfurt ballet and tat theater am turm. in today s fast-paced world the south pacific hotel has everything for the discerning traveler located right next to wide variety of shopping dining and entertainment in popular causeway bay. and so we began discussing the compound bow s wheels and cams and it was very clear we have very diffrent opinions on the subject. information on mail order sources of palms and information on the hardy palm international a publication of the pacific northwest palm and exotic plant society. let the car guys offer up their knowledge on collectibles news and information car care and more. ever since we ve had more than one site i ve always wanted to have a structure that all our sites are linked into. manchild - eels the warmth - incubus no woman no cry - spunge learning how to smile - everclear or american dream - dustfly. battlefield archaeology is a relatively american phenomenon but there are some pretty interesting battlefield sites to visit around the world here is a short selection. brings you products that will enhance your lifestyle with exercise weight loss and whiter teeth. ----PEMFH87531007MMVB-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44KutR2008858; Wed, 4 May 2005 13:56:55 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44Kutej008857; Wed, 4 May 2005 13:56:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44Kus9d008848 for ; Wed, 4 May 2005 13:56:55 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j44Ku1a9003486 for ; Wed, 4 May 2005 16:56:01 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j44Kto9q009747 for ; Wed, 4 May 2005 16:55:50 -0400 (EDT) Message-ID: <42793714.90503@nist.gov> Date: Wed, 04 May 2005 16:56:52 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: name constraints on uniformResourceIdentifiers in 3280bis References: <4278E0BA.7020706@nist.gov> In-Reply-To: <4278E0BA.7020706@nist.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, The new text in section 4.2.1.10 (Name Constraints) of 3280bis for imposing name constraints on URIs was added based on comments from some of the members of the design team. After further consideration, most of the members of the design team decided that the additional flexibility provided by the proposed new rules were not absolutely necessary and that adding this additional flexibility could cause problems for existing clients. So, unless there are objections from the working group, the -01 draft of 3280bis will revert to the RFC 3280 rules for name constraints on URIs. (The -01 draft will still require that internationalized domain names be compared as specified in section 7 of 3280bis). Dave David A. Cooper wrote: > 3280bis disposition of comments: > > 21) There is a need to be able to specify name constraints for URIs > that limit schemes that may be specified. > > 3280bis includes an extended set of rules for specifying name > constraints on URIs. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44JKIvW099743; Wed, 4 May 2005 12:20:18 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44JKIin099742; Wed, 4 May 2005 12:20:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44JKHnI099734 for ; Wed, 4 May 2005 12:20:17 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j44JK0DT016769; Wed, 4 May 2005 15:20:01 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j44JJF9q029602; Wed, 4 May 2005 15:19:19 -0400 (EDT) Message-ID: <42792071.1060704@nist.gov> Date: Wed, 04 May 2005 15:20:17 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Henson CC: pkix Subject: Re: RFC3280bis: policy processing. References: <419CA07A.7020806@drh-consultancy.demon.co.uk> <419D004F.2080205@nist.gov> <419D3BF2.7070100@drh-consultancy.demon.co.uk> <41A21934.507@drh-consultancy.demon.co.uk> In-Reply-To: <41A21934.507@drh-consultancy.demon.co.uk> Content-Type: multipart/mixed; boundary="------------010400010004030801000000" X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------010400010004030801000000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Steve, A few of the members of the design team spent some time reviewing the issue that you brought up below. We agree that X.509 and RFC 3280 differ as you describe and that in some circumstances the outputs of the algorithms could differ. However, we do not believe that the differences in the two algorithms will result in different outcomes in any realistic scenarios and so we do not believe that it is necessary to change 3280bis to align with X.509. An example of where X.509 and RFC 3280 could produce different results is shown in "X509vsRFC3280_policyMappings.pdf" (attached). Pages 1 and 2 describe Certification Path 1 and the steps that would result from processing this certification path under X.509. Under X.509 the output consists of a authorities-constrained-policy-set of {1, 2} whereas under RFC 3280 the authorities-constrained-policy-set would be {1}. Note however, that the first certificate in the path include a policyMappings extension that maps from policy 1 to policy 2. So, the outcome of path validation would effectively be the same in either case unless the user-initial-policy-set included the subjectDomainPolicy from the policy mapping (2), but not the issuerDomainPolicy (1). This seem unlikely. On page 3, Certification Path 2 demonstrates that RFC 3280 would get the same result as X.509 if the first certificate in the certification path explicitly asserted policy 2 in addition to asserting policy 1. As shown in "MorePolicyMappingOddities.pdf", it turns out that a number of unusual things can happen when the policyMappings extension is included in a certificate that also asserts anyPolicy. These oddities occur in both X.509 and RFC 3280. But, as before, they would only result in a different outcome for path validation if the user-initial-policy-set asserted a policy that appeared as a subjectDomainPolicy in the policyMappings extension but did not assert the corresponding issuerDomainPolicy. So, while the results are unusual, it does not seem that it is necessary to make any changes to the algorithm. Dave Stephen Henson wrote: > While I was checking the X509 policy processing against the RFC3280 > version I've noticed what I believe to be a discrepancy between the two. > > In RFC3280 the policy mapping processing is described in 6.1.4 b(1) as: > >> (1) If the policy_mapping variable is greater than 0, for each node >> in the valid_policy_tree of depth i where ID-P is the valid_policy, >> set expected_policy_set to the set of subjectDomainPolicy values that >> are specified as equivalent to ID-P by the policy mapping extension. >> >> If no node of depth i in the valid_policy_tree has a valid_policy of >> ID-P but there is a node of depth i with a valid_policy of anyPolicy, >> then generate a child node of the node of depth i-1 that has a >> valid_policy of anyPolicy as follows: > > Whereas the corresponding text in X509 is in 10.5.2 d): > >> process any policy mappings extension by, for each mapping identified >> in the extension, locate all rows in the >> authorities-constrained-policy-set table whose [path-depth] column >> entry is equal to the issuer domain policy value in the extension, >> and write the subject domain policy value from the extension in the >> [path-depth+1] column entry of the same row. If the extension maps an >> issuer domain policy to more than one subject domain policy, then the >> affected row must be copied and the new entry added to each row. If >> the value in authoritiesconstrained- policy-set[0, path-depth] is >> any-policy, then write each issuer domain policy identifier from the >> policy mappings extension in the [path-depth] column, making >> duplicate rows as necessary and retaining qualifiers if they are >> present, and write the subject domain policy value from the extension >> in the [pathdepth+ 1] column entry of the same row. > > > Translating this into RFC3280 terms it appears the processing of > anyPolicy is different. > > In RFC3280 a new node is added only if a node of depth i doesn't exist > with a valid policy of ID-P. > > In X509 it appears to be saying a new node is added unconditionally. > > I believe this difference could result in different outputs from the > algorithm. In particular the X509 processing will (significantly) > result in nodes whose parent is anyPolicy which will not appear in the > RFC3280 version. > > Steve. --------------010400010004030801000000 Content-Type: application/pdf; name="X509vsRFC3280_policyMappings.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="X509vsRFC3280_policyMappings.pdf" JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1auZLUMBDN5ysULsEYXZYtQo6AgCqgJiSBPTgXdpejir9Hl2ek J8n2sMMx4NpgqqXuVl/qJ8l7TWjDCLV/4ff0cnW9uvtcktefV9eEuanh5/SS3N+YSU0YJ5uL lZdgRNOGS9JR3Zjhy9XJgzubd6u+YcrMbs5WJ+eWbhsqA31jadnQPtBfLC0ao9TTbz0tBvkL T/eyMn/q9fNB30ugp/R/8vzdQH8EmliaN/2g76mlVdPxmeu9mdDHnL5A3LPEow15ttKUm6Ca VXSriCY35+Riz5QoTY8iIecwPx2gNReWfc1czRWWRJU3YPIXMPktmHQBIam4uA3hvi6GGpID /Sl28cOEcegsGoeLffbOtIpSFkfRiuyGMOro0nZb7ES+x1bPcSkvqZ0y9MopXzPBTZpFI+Xh 45aY/8QSjJooVfy/gm18FUvjUh/jydcgGfLRx7lYS263rHWVFzWC0Dangf4aLzhV/Q99Q1Ay jmJk4KWl9W5tDMWot8UUpXXzIc/+Xrm6B8wEaOZLhzLrUlQ9o0F7FRPvJvYvmof9JEQ4CfCt opsG8JfstXSJGR2C+zB3feM26dCLjx1u+BjchEpa8OYfxxu+wM0CNzPhhi9w8zvgRvybcCMW uPkTcBOqiSvXBwVv5FFU09/2eIH6sBLRvqlKxp5ZSO40+G3fT2SnOWGiYz/3gCKVa+n2DeUx +JUsikmZShoGHVsoAsy3eLGXUJG4nUahGdOXbEysVcd89zljIThGrtM6qdTiosUaqhVs2FA1 NJoK5YxmsPYitQpMQpCktaALzbnJWZK4jNYq2n6Ww+Ia2s1VznIgMN7SIVy90FrXA4G2Y2BC 7eikdKBABEYt0vcqd7RwjEMrPHwy1bmTGOc2cHacuq7Od20lvBBI7YG2tw1syxiVvJSNLOU1 yWMtghKTdgg0dIuJrtG8alfh0jSe3+RucZB62mXenGJas/fshaNLLlVd7fCAEIJtqdhBovlw 4K1GdPSyhA3yvqUx2iN4NXWSQv1/+3ljCkBQX9LrK9cYGpXe+0LDFTUcfHGS127ycYDGRAOm tmOTiZoXd/J1RpEzbLu2Zvjc83u0XqFHzjzFV1c9/HeYwhHb7HfV2J6qDtN81+Yk5sKy9OD/ tQf/tjvGIYzFhluohsLWntEQtiGtSxUOkIViGS4Q483mPOc6XFcbq+Vf3dUKh1nMoceZyAaW B3ZPqMHnwlRZFXAiscLDZqG2pvD5VsiTpSkVnNGYbl97lCZf+eDhTKpG2zfY1naHGHxEItVT /IrFubbt3KKRUVBFo1q7/6MwJH/eLgSg6avl3q/owr2wJenPanhfM7PHhNs/9kdoydvwkr89 mbDjqIWdD4pOlHsrXLkf6YlguZWl88utrLSH/o9bWeHfFZh23yALd7AFBhcYXGBwKHf3nYhJ yYlkBisEYb3y34n8oJDGU9VSIv0o58YQxyqBVYieOXkZD7ZKenkRyTtWCaxcGWyx8m082Blz uWSCACtLRp1Wp0DuFAjai2zQy0uWuOrF7WDklBeHQSfOlNBZpFhvatvZJFJWlVvqFOBSOOjl pWndUVC8uB1ER3FwyGkafsPa19LX6ZwVMyX6llVjmvrvWTGodrDiqdRJpDwrePXM/P0AQyFA EmVuZHN0cmVhbQplbmRvYmoKNyAwIG9iagoxMjI5CmVuZG9iagoxNSAwIG9iago8PC9MZW5n dGggMTYgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWEtPGzEQvu+v8BGk rvF77Uq9ULXngnLkggIBWgIlTQ+o6n/v2l7v2mM7aUOQiFRxQB6Pv/nmZU/2CRFMEbF/w//5 snlqnhB1svBvvkSns+bk3CDK0GzReFWKDMFMoI4Y3IuXzdGX49nXRuGO9buzq+bo2q4lZnpY r+yaYy2G9QKsH71+pyr6S7s2mIf9O79Pg70HZ39Y3AAwZNcM60AGkoXGIJk5cAY698OuBZaq sn4R2eHw6PlD0CeEDqJ1UJlEtfhzYwwMaf3UVW7rLrd16bVIhF1nFGshEJdtcS44sQYQBXoL nw2iK9mAVi/BGpqoZn8yCXN4cQQ40DywJC4KDABkthkRYjnYxXEeKhjtx/xYobagK7vniG+u okV+sKBVSdYLao+QJI4hyO/tomVCYaNQS6W9HcY0aYY5i1OpCRYxSiemiHGHxImwZ1qqLeCI dHJO6XC1CjFiXMZMktviGfjfgqvrO7hNHuPD9+Aq2dYJzhjvsNidVxTxkdqUlzK7rEy2EFRV dqm1IseoKV+NIPnb8BExQQd2nTH7IDiVeeAYAT/7UgyPfMuZ6msxqlV6GLU6uaBCzEN7Ktif oyDrz34uGBXfvs9vvj+npEg9zUS1NDDt0iBYSMNBTZanzitsWJyQDZMiHO7m4R6o4H901Yyp SoMx6q/AlVYdjyrBqvDZeTbaNj3cxsGFh0Mwohr9FusPwRxfYjjg+KkrLXIaA/zjyBVtJjDV YSs6kHTS8DbJGvG9zlgj6mvPwdBlHrvsxylquL2sWqosjTEFLxunhnviQMap/TxRh/Us/3+i 9vJE0eS+iDrtM7Bf/WRQ6ex7ECN4Hw3+iZo/SQ7gE7bjx5Iq+ZvsWokaoO05tf3wqkRebD8B 0BoYut1U96syyzFEEAx6AR9q6DVsQlimpfejq4UQkhnJg282G0eetM2KX4YgedipSSRTvF07 dcPPt8J3mMLv/nXa7709akxXaawPoLHg/q/csWQyeFdqrOh88sXht118mqGzhgrBkFKGIo6o Vmh1jRaDUPdJ55TLfieSqh7RSYWXMtbn3gGICYATzXOhFl3FlOyL1QplKqQFS1ZVTKreEhQ6 S0VQTr1Qx5hWKCahx4RChwmOO0wpuXHCOE6yYyn7oKpynxyAmACc/Uxo7ZdNcWEyn5wQ+pQJ HSY4LmQnsjR5YSWiLCkTrwoC5YQ19l1+HpI66//+AORrMvtlbmRzdHJlYW0KZW5kb2JqCjE2 IDAgb2JqCjkxNAplbmRvYmoKMTkgMCBvYmoKPDwvTGVuZ3RoIDIwIDAgUi9GaWx0ZXIgL0Zs YXRlRGVjb2RlPj4Kc3RyZWFtCnic7Vldj1y3DX2fXzGPadCdSNR3gL40LfpUoHYWyHOy8SYO Zh1766Iwiv738pDU/dDMeGfsrNMECwPee+6VKJLiISnNm63b+a3DP/t7c7d5s3mz9fKu/7m5 2/75evPF87b1tL2+3ehQv21uR3FbXNvx67vNZ1/94fqnTd35zF+vv9989gI47Vw0fA8cd64a fgscdixU8UvFoc+/VVzjie83Kp+6vG8H/JD8n3V86fjVgLfAtKtd3j+A867Qmev9+IA8EnkG vgT46/X22aY5YqfyKi3lbdvev9jeXrglubnfxIa8GL6PDvIHDrqigOFXXmLuyJKjyPtB5beD yi8HlW4Hl5wwcXLhpSZaDMWOf16auH9AudHYUblxsX+qMSk755dexJT51ej10aSJFvOUd0ut zzHpMKRmYaNV7w7X++Mg5SiTrnwMINuVD7sYf3lvr4z+O4B37NsTXns9kP/1cva41Kvlxx+G mbaLdbmDV5FAdJhKRyUOk6ZIMPyv5YIPceYvmkZyXHpxoeAdcJvXHl3xXmuPbtF696eNml9d tFdfHoueBfYaPc4P0fNep323BD89wPpRvTELmYdXDv4o764d+AkYekZeMZKWugu0yOC/9SJ1 WMUXRcoi6alK/T6rFCcLWiThp3LzVG4eLjf0VG4+RbkJv89yE57Kza9RbsTtXzz33g7cV56y pETKBMpOZh9l79GbgVPXEPdDHhgNeigiTxps+ErHnwrQlfNXuXMUNCoyKr7yx3uz8qjy94NL roaAfX3gv49PLxPui4XW2umYGVV+qwHSL2Tec1j9k0Z7OVUf/nOY7vzhq7OOxN0r/wWQy6Vn mzcbXBXd8f+lkdvuN9nT+hkPP26+2b6ya6Xnf7OH+x/44eWGWigoz8FlYkEMiaMpuER4S43z UQOOkpeoeQ9jgwvoHm42VFvF1gZHxDWIai1gUnA+y/xaCszoGBNyU4l9RMqQzAIkkVMNVXFy SCKYwWXV4U0Vl1BpRSSg6mZA2jUCTPjLE0rVRb0LyGNUSoCo4JrbYX7yWIktrrZCCRkDeU1J jFTYaoyPWVQqrIAYrRgTeK3FgIwF5+k5NR2fmzop54DCxRaAqpRLxF5P+uUWQLTg2QUUVT73 TLAgorJ3fXzOgthDYnD1u6QG827AIl+lbLDCXgSS9HjTesSGB9E/x4hdJvZowADSTeRNgEdm zF2q6DO9IA2LHJ1sUuDgKbAoR3FgSFI5ZA/UJqIElfbYxsLCWIkC7vM+q5OIN6Vh33m/2Rpe QpwooZV3eXqxn1949XpzIjBo88WhqoFD1WH3WUBjL6rdEX7l+YFB0E2qVcOGyEMficwM9wRy XSMvseyxa3WOTF8cNMcMi10fu8wGjTyvC7ik1s3m9hfiK+8phPIk4SsihVHVjalN2YWQp6p8 hJdL7nzlWMBOlqR8xXtIi52NQahjGBNiUol9BCcI2FyS8dVHxbXztbAXwNfqja9Fc0gNytes 4VvDxNesi9ZgfI1N+FpJ+UpForu0ia8sGeFWqhGOrYYKpdNRQ8sw4pepshyQhU/TdNZExrfO V45N8BWZB8M5ND3N+mXmNWK7ps7XzJLA11qEr6YP4lXYGMVg5E7jq2tiUdM2T/IHBLaofLX1 Wp34yp7I2+i88dXJJkYXjK8dx87X/sLSePYSqNFl4ysPZEuiqxNfk9rUUudr4awUoYTx1YuT oiNjB/dMCThNfC0kSqaJr/bCsmStEMhKG19dVJ1852ut0ew2vubGIBu3koZNSxNf+SALvrbQ NdLaIwypc2Q2N/HVYhckEJk5wUQQW/i6oNblfAWf/q0cTSwgJi8EJR4kz3t7xi9B/Mx2rZ9t zDR3v/naZpSAbb2zcYrw9dwfkojjmx0SKw71+C3Jenq36IrOvHKZGh1rdFPHpw/a48Fisei7 D2xlzjacY5TtznLhAcOPtGOPchd17iXEkVb2wD+rXxwXTeKH9oFznHK7EKR4EALjbuOTlAJB e0VRew7ELnMlH+B59EoWolOltehEdh+v+JLo9TVr4kngPXaRHjlsfJGUx3kBYbCKm3Ma9PHj hzfsnEqQTXkbuEaqGx1yLmdKdXpr8tXLIN4UHGQxmlBpgb3OJv2K9g7IttCxipFC0LFOalck 2yByWWVxCTEMoZFrh+GlZvvN7ecWWcT9FgZa/nOFuygskzWjJelEzAT+nlIQsU2UyLSOsgxz gzcVchQD+PSxk1yZJRVOc70aYM7hIqgG1Djl1f7MG4w1q62y0klNSXlpRBdltn6NniVKCyHH Hh4RGs143/FkSPAhH8Hz+JU8WcEkdgL1GZcTCDvY8pJA/3c57jFrAPfm0ssdkvmpCHCGCVmu U0MJ+MNxRtx95473HUdfNe5YMyH0gOfxK3mI0y4RraWsYDMUXxLJgZtUaVtL30v/yNETcAvB wRNRgs4MnkcrBgGNHPKU140izVrwBhwfclltDFnmlezISPNs1dIw4dwMZyQ/TvfJtj1LMQiG LNkH34Miymjq0mbNlqWgaKwkU7iXgmo5zje5YKCWSNoP+SBo31EImtz5VL967qMWErTp0Fk4 o0telnmKLms65HQbqFrL/Pg9R9Nrr3zQq56IpPAYYbY4xBRo1PeGuwLEifnZEO+H9g7BJ2H0 gPvohSSpbDbbZ61rOhfosqoW5bDGO4Qr+4861XxY3v41DzYx6a1rfqpoiwTJrEU+ConkOFMl t4UUNKV5zLMc4pukhMW3jKwpM4FiVeSszw5RRnvNXCopeZWEu67pix2DppkLjRaJUQVM5y4V 53Jv/YrX5aQZvsN9ES2VpSI9+UQ3znFI04vvXQnpg0tXwRr7InXC1Jfb5DgjORssxi41UQNs 8anzNTyrz3oUWTDqCNGDkRWaJOeMEL3m5JBJfd2/W/+gs4GdqitCMV/74hT0UNDlJbsWCSnH 5de0mrvUTMzp06f2p4uj0NsXXKbhdkjOPyhjItvwvuMQ7VQSmpwSRjyPX8nTBkkleDmW3E0S FF/WIIl91HAx8ynKVmCi6E8dOGKcmYvOrlzPNv8DhdGmI2VuZHN0cmVhbQplbmRvYmoKMjAg MCBvYmoKMjI4MwplbmRvYmoKNSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2 MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMTIgMCBSCi9Gb250IDEzIDAgUgo+PgovQ29udGVudHMg NiAwIFIKPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYx MiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BE RiAvVGV4dF0KL0ZvbnQgMTcgMCBSCj4+Ci9Db250ZW50cyAxNSAwIFIKPj4KZW5kb2JqCjE4 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMjEg MCBSCj4+Ci9Db250ZW50cyAxOSAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1Bh Z2VzIC9LaWRzIFsKNSAwIFIKMTQgMCBSCjE4IDAgUgpdIC9Db3VudCAzCj4+CmVuZG9iagox IDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iago0IDAgb2Jq Cjw8L1R5cGUvRXh0R1N0YXRlL05hbWUvUjQvVFIvSWRlbnRpdHk+PgplbmRvYmoKMTIgMCBv YmoKPDwvUjQKNCAwIFI+PgplbmRvYmoKMTMgMCBvYmoKPDwvUjkKOSAwIFIvUjExCjExIDAg Uj4+CmVuZG9iagoxNyAwIG9iago8PC9SOQo5IDAgUi9SMTEKMTEgMCBSPj4KZW5kb2JqCjIx IDAgb2JqCjw8L1I5CjkgMCBSL1IxMQoxMSAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9UeXBl L0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1RpbWVzLVJvbWFuPj4KZW5kb2JqCjkgMCBvYmoK PDwvU3VidHlwZS9UeXBlMS9CYXNlRm9udC9UaW1lcy1Sb21hbi9UeXBlL0ZvbnQvTmFtZS9S OT4+CmVuZG9iagoxMCAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL1Rp bWVzLUl0YWxpYz4+CmVuZG9iagoxMSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250 L1RpbWVzLUl0YWxpYy9UeXBlL0ZvbnQvTmFtZS9SMTE+PgplbmRvYmoKMiAwIG9iago8PC9Q cm9kdWNlcihFU1AgR2hvc3RzY3JpcHQgNy4wNyk+PmVuZG9iagp4cmVmCjAgMjIKMDAwMDAw MDAwMCA2NTUzNSBmIAowMDAwMDA1MjM3IDAwMDAwIG4gCjAwMDAwMDU3NjYgMDAwMDAgbiAK MDAwMDAwNTE2NCAwMDAwMCBuIAowMDAwMDA1Mjg1IDAwMDAwIG4gCjAwMDAwMDQ3MTYgMDAw MDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAxMzE0IDAwMDAwIG4gCjAwMDAwMDU0 OTMgMDAwMDAgbiAKMDAwMDAwNTU1NCAwMDAwMCBuIAowMDAwMDA1NjI3IDAwMDAwIG4gCjAw MDAwMDU2OTAgMDAwMDAgbiAKMDAwMDAwNTM0MCAwMDAwMCBuIAowMDAwMDA1MzcwIDAwMDAw IG4gCjAwMDAwMDQ4NzYgMDAwMDAgbiAKMDAwMDAwMTMzNCAwMDAwMCBuIAowMDAwMDAyMzIw IDAwMDAwIG4gCjAwMDAwMDU0MTEgMDAwMDAgbiAKMDAwMDAwNTAyMCAwMDAwMCBuIAowMDAw MDAyMzQwIDAwMDAwIG4gCjAwMDAwMDQ2OTUgMDAwMDAgbiAKMDAwMDAwNTQ1MiAwMDAwMCBu IAp0cmFpbGVyCjw8IC9TaXplIDIyIC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCj4+CnN0YXJ0 eHJlZgo1ODE2CiUlRU9GCg== --------------010400010004030801000000 Content-Type: application/pdf; name="MorePolicyMappingOddities.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="MorePolicyMappingOddities.pdf" JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1aS2/cNhC+76/g0TmswpcoMUAvSRsghwJNsMdcEsd283Bib9IC RdH/Xr60Ij+S0q6tpF504cNiKM5wHh9nhqRvCW0YofYv/J5fr25Xj19JcvV1dUuY+zT8nF+T pxvzURPGyeZy5TkY0bThknRUN2b4enX27NHmw6pvmDJfN+9WZxeWbhsqA721tGxoH+hvlhaN Eerp954WA/+lp3tZ+X7u5fNB3hug5+R/8fO7gf4MNLE0b/pB3m+WVk3H91zv9xl5zMkLxBNL /LIhL1eacuNUs4puFdFke0EuDwyJ0vQoAnIB3+cdtObCTl8zh7nCkihyCyp/A5Xfg0qX4JKK iTsXHmpiwJAc6C+xiZ9mlENjUTlc7Ks3plWUstiLlmUcQq+jSbttMbL8FWu9j0k5pEZhaJUT vmaCmzCLRsrl/Zao/6slGDVeqth/A9v4JubGpT7HH6+AM8Sjj2OxltxuWWsqL0oEpl1MA/1H vOAc+n/2CUHJ2IuRgteW1uPa6IpJa4shSnHzKY/+QbF6ApMJ0MxDhzJrUoSeSae9jYkPM/sX 1cN8EjycOPhe3k0d+F32WrrEHhmCezd3feM26ZCLj73c8KlyE5B0qjeL15uAJq5cHhS8kUeB pofWTaI8RCLqN4dkzJmF4M4Xv11D27ZdR5joGOnv0tG20v3YpvYF2JUsikGZCxo6HVMoFpg/ 48XeACJxO02WZgxfsjERq27y41eMBecYvk7rBKnFRYsYqgE2bKhaNZpz5R7JYO1ZaghMXJCE tSAL1dnmUxK/TGIVdX+Xl8U1pJubfMpCxXhHB3f1QmtddwTqjo4J2NEJdAAgAr0WyXubG1po 41ALXz6Z6lwnxrl1nB2nLqvzMa2Elk1qX2h7m8B2EyPIS9nIUlyTONY8KDFoS1RDt5joGs2r ehVOTdPxTc4Wi+BpjLzpYlqz9+yBI/gYS8ZcM4NpqZhBou+h4a16dPKwhAnyqaXR2xP1aq6T QvkPvd+YKyAoL8n1lWMMjaD3sZBwRa0Ovj7LsZvc1tCYaEDVdupjIub1o3ydycoZtl1bU3zf /j1ar5Aj9+ziq6sufzFWaLHNfleNzalqmeS7Ni2Yc8spBy+Rg2V/fDn4h50xllAWE24BDYWt vUdC2Lm0zlVoIAtgGQ4Q08nmIp+1XFabwvL3zmqFZhZj6OtMpAPLHXtgqYkU4rmwasGJ2AoX mwVszdXne1WeLEwp4x6J6f7YozS5doWLM6karUrFRyRcPcWLIM61Tee2GhkB1WpUS/f/aRmS d9cLC9D80fLgW3ThbtiS8GcYPlTN7DLh/pf9UbXkbbjJ33Um7DiwMNqg6AzcW+HgfjqVFeWf TmXR/NOp7EGfygrvR0y7N8j/Uxk8gtSX3o1GEXwO61ePEBXEzD0f4Gtc8fxUS413PDxVlb/K 4BqBa210WnMV3uLyF4ZIDj5x4kNVYtS2rCS+MiDk8JVh5xQ0GvE9/8aQ/39GW7PsTm8MaVNU PCii8j+gycKUEKXJ+htDdlgY97pZj2ndVfbVT7Cv8PvfuWFJwfnHEu4tkUnJidSSEUFYr/xb ohtsGVeEqZaaL26UcxM4N1XCVMmUcvwiHhRmWzp+GfPbqRKmCmE0x/VF2wnCJRMD/zBV+dFY Kycg0kpQIx8HPT+niame3Q5m7DDo2Lk0Hb9lb+NBZWIda+qEuqlynOqE4mBwv9CJp83Uvupp WZgKThV9yyrmG1Al7vNTK6ayxCo3FQ14af7+BQ5rPEtlbmRzdHJlYW0KZW5kb2JqCjcgMCBv YmoKMTMxNAplbmRvYmoKMTUgMCBvYmoKPDwvTGVuZ3RoIDE2IDAgUi9GaWx0ZXIgL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCnic7VpLbxs3EL7rV/DoHHbD13KXBnpJH0APBZpAx1wSx06Txomt JgX678vXrsiP5K5kyalVCD4Iw+UMZ7558eF7QltGqP0Lv1e3q/vVPWFubPy5uiUv1qvnrzRh nKxvVn4qI5q2XJKe6tYM364ufny2/rgaWqbM1/W71cW1pbuWykBvLC1bOgT6q6VFa4R6+oOn xch/4+lBVr5fefl8lPcG6CX5X/z8fqQ/A00szdthlPe7pVXb8x3X+2NBHnfyAnFpiZ/X5OVK U25ANavoThFNNtfkZk+XKE1PwiHX8B0BYhlADRd2esNczBWWRJEbUPkrqPwBVLoBSComThDu a2KIITnSX2ITPy0oh8aicrjYX96YTlHKYhQty3YIUUeTprTYsvwTa72LSXlIbYWhVU54wwQ3 bhatlMfHLVH/N0swalCq2H8HaXwXc+NSn+OP74Ez+GOIfdFIblPWmsqLEoFp8mmgv8ULLkX/ T74gKBmjGCl4a2m9XRuhmLW26KI0bj7l3t/LV5cwmQDNfOhQZk2KomcWtLcx8XEhf1E9rCcB 4QTgg9BNAXyUXEuX2KFCcA9zP7QuScdafOrtJu/HUbsJkXTuN//XfqP6tjPRLHgrTyKan9pu FuVhJqB+S5mENbsQXMvNd9pQd13fEyZ6RoaH7Kg76X7spvpXsCtZFJ2y5DQEHcMXG9zf8WJv ICIxnWe3Bui+JIswVt3k568YC+AYvl7rJFKLixZjqBawIaFq3XAJyh2KUeNZahGYQJC4tSAL 1dnkUxJcZmMVdX+Xl8AGys1dPuVIm4GJDnANQmtdBwJ1R2BC7OgkdCBABKIWyXubG1rYRqIW l1NRtztBzi1wdpy6qs63ZSVsGaX2jX6wBWyaGIW8lK0s+TXxYw1BiU47Rjd2i4m+1byqV6GL zvs3OdscJZ62nje7qM7knj3wBIyxZSxtprAsFStI9D1suKuIzh7WsEC+sDSiPdOvlnZyKP+p 7zeWGgjKS2p95RhFo9D7s1BwRa0Pvr7IYze5LaIx0YKq3dzHRMzrZ/k6s50zpF1XU3zX80O0 XqFG7niKqK56/Iu5whbf5LtqbU1Vxym+jdmCOVjONfgYNVgOp1eDv9sZ4xjKYsEtREMhtXco CBOkda7CBrIQLOMBYr7YXOezjlfV5mL5sataYTOLPvR9JtKB5cDu2WoihXgurNpwIrbCxWoh tpb680GdJ3NTyrhDYTo89ihNrn3h4k6qVqtS8xEJ10DxWpNzbcu57UZGQLUb1cr9f9qG5MP1 wga0fLTc+xZfKHuHkrg/i+F91cwuEw5/bIi6Je/CS8K0M2GnEQtbGxRdCPdOuHA/n8qK8s+n smj++VT2pE9lhfcrpt0b6LkNntvgvmo2nPYW+qj5PSU3n0CHS6/Ao0T9BdavnhQrhWHplQhf SIvH5FoHfOAZuar8+6wqRTWkMTo1XNn/SMkC7BsIwqd0fJBMrNqUtcTXJIw5fE2aUEGrMcCX 35Ly/wPqapY96C0pzfrihQAq/x2qCNaEqB3W35KyQ+E22c16TOu+klg/QGLhu2Wk7eGt4RHQ cs/VTEpOpJaMCMIG5Z+r3WDHuCJMddR8caOcm5hxUyVMlUwpxy/iQWFKguOXMb+dKmGqEAZU XF90vSBcMjHyj1OVH421cgIirQQ18nHQ83OamOrZ7WDGDoOOnUvTTS17Fw8qE2aZpmYqS0bd Uk6A3ApwS+Gg53eagaYeQ9AUB4NPhU7cZ6YOVffJwlTwlBg6VsHUJEniEz8VQbWDNUtlzo9W vTR//wJGcvG6ZW5kc3RyZWFtCmVuZG9iagoxNiAwIG9iagoxMzQzCmVuZG9iagoxOSAwIG9i ago8PC9MZW5ndGggMjAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWktv 3DYQvu+v4NEBugpfosQAvSRpgR4KNMEec3EcO4/Wib1NCgRF/3v52hX5kZS03q1hoYYPxgw5 w3nPUNxbQhtGqP0L/y+uV7erW8Icbvfv4po836yevtaEcbK5WvmtjGjacEk6qhuDvl6dvXiy +bTqG6bM6ubd6uzSwm1DZYC3FpYN7QP81cKiMUw9/NHDYkd/5eFeVtYvPH++43cO8BT/L35/ t4M/A0wszJt+x+83C6um4zPP+zDBTzh+AXhmgZ825NVKU26Mak7RrSKabC/J1YEuUZouwiGX sI4GYpmB1lzY7WvmYq5wJLLcgshfQeSPINIVmKSi4t6Eh6oYYkju4C+xin9MCIfKonB42J9e mVZRymIrWpIBhVZHlfZpMZB8j6Weo1IeUgMz1Op7ft4PwAVF5i42mBQ22dZMNFKe3tqJ0r9a gFFj24rVbiD5b2JqPOpzvPgeKIMX+9iDa8ltoltVeZEjEO0jIcDf4gOncualLyNKxlaMBLy2 sB7ORlOMalt0Uer9vaMG1EG+elaKnghmPnoog+gZNdrbGPg0kfUoHlahYOHEwEdZNzXgPWTo jLoSkrTrG8GjCr70JsXHmlSIpMcudfIuFaKJK1cHBW/kIqLpoc2gyA8jEeWbimSsmQXnTje/ /Rjctl1HmOgY6e8yB7fS/bOj8C+gV3IoOmXKaWh0LKHYYP6KDzuHiMR0Gm3N6L4kMTFW3ean rxkLxjF0ndZJpBYPLcZQLWBDQtW60ZQpZxSDtSepRWBigsStBV4ozjbfkthlNFZR9nd5W1xD ubnJt5yoGe/hYK5eaK3rhkDZ0TAhdnQSOhAgAq0W8XubK1oY41AK3z6Z6twkxrk1nMVTV9X5 UFbCyCa1b7S9LWD7jVHIS9nIkl8TP9YsKNFpp+iG7jDRNZpX5Srctcb9m9wtThJPg+fNFNOa 3LMXjmBjbBlTwwyWpWIFidbDwFu16OhlCQvkcwujtUf61dQkhfwf+rwx1UCQX1LrK9cYGoXe 74WCK2p98M1ZHrvJNx4aAw2I2o4tJmzePMnPGe2cIe3amuBz5/fovEKNnDnFV089/ee0woht 8l01tqaq0xTftRnBnFkea/ARNbhjtgYPpmbL6HODCspN4n5p9yHA35IX2lju7eJ0CmGxixRC vFCvZlS5vUnrVIWpuJABu1vReAW9zHedrlSPJeh/XaoLEzr60DfPSAaWG/bA/hkJxHNm1S4a kRW+1hZia2roOKqdZm5KCWdU2+Njj9LkWzJ8DZSq0arUUUVC1VP8usW5tj1qkfcbeXe5sKtO 35cPfhoQamhH55UYPlTM7AvJ8S8Y0QjA2/A80dtgWugMEEf3nHDni1WxltGtcCoudOh5vE2n 64+36VIO/T9u04V3P6bd2/FxnT5U94V0+mOq+3Ib2EOr7tUfxvwM51cvgpWkmHrZwofi4i24 Vv3veAWuCv8+y8gouNZGpjVX9lcsWYB9A0b4/I6PqIlW27KU+AKGMYcvYHuroNYY4NPvX/lv h9qaZnd6/0pn2+J9H4W/h1kZa0LUCurvX9mdb0h2cx7Tuqsk1o+QWLj+d65Y0lRn/aJtt/kf C7hHcSYlJ1JLRgRhvfKP4g7ZMq4IUy01Kw7LufGy2yphq2RKOXoRI4VJYkcv062ywNUykMBA 6M5z1dFOh5QD0u/k1MsfnySEAblkgiRMjQsSrOdqGciBgaBGEkR6emosbI/qEyQNTGXM1G6V w1bPFJCOnvfm7hjZ35E7ZGRpR45IT05ll7nP8OC5+marzCV1DLKjAOnoDUTdUW1E7pByQDpy RIZAEzrxvtnaZzHlkZWQkDk9xoToW5a71CEr1k8t5bZm5nfIsk3aLrGp24r6vzJ//wLkFBuP ZW5kc3RyZWFtCmVuZG9iagoyMCAwIG9iagoxNDEwCmVuZG9iagoyMyAwIG9iago8PC9MZW5n dGggMjQgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztWklv3DYUvs+v4NEB KoWbKDFAL+kC5BCgCeaYS+LYadI6sadJgKDofy+3GZEfSUm21cCDDnwwHpfH9763UpwbQltG qP0L/8+vNjebG8Lc2P7f+RV5ut08fqkJ42R7ufFLGdG05ZL0VLdm+Gpz9tOj7YfN0DJlZrdv N2cXlu5aKgO9s7Rs6RDoz5YWrWHq6feeFvv9l54eZGX+3PPne36vgZ7j/8mv7/f0R6CJpXk7 7Pn9ZmnV9nzheb/P8JOOXyCeWOKXLXmx0ZQbUM0pulNEk90FubylSZSmR2GQC5hHgFgGUMOF Xd4w53OFI5HlDkT+DCK/B5EuAZKKigcIb6ti8CG5pz/FKv45Ixwqi8LhYX95ZTpFKYtRtFvG oUnUf4BJAiJxZxVGuQ2LholWyvX1/BZvfm4JRo1WFRNcQ9hdx7vxqI/x5DvYGfAbYuwayW2I WVV5kSNsOtgg0F/iA+e89WcfwErGKEYCXllaj2cjFJPaFk1kmY+ucTDUOHQrWz2Bxeg9LHgP sypF3jMJ2puY+DATbygexn9AOAH4XuimAC4JgzzdjvuL6KZHLIjoEKT90Aoe5c5jLw98qjwE TzrVh9XrQ/AmrlweFLyVR+FND637Q37oiSjfnCdjziwYd774HRrQrut7wkTPyHCXDrST7p9t Qp+BXsmhaJQ5oyHomEKxwHyND3sNHonhNFma0XxJYKKvusWPXzIWwDH7eq0TTy0eWvShmsOG gKpVozkoFySDxm+peWACQWLWAi8UZ5cvSXCZ9FWU/W1eFhtIN9f5kpWK8YEOcA1Ca10HAmVH YILv6MR1wEEEohbxe5MrWmjjUApfPpnqXSfGuQXOjlOX1fmYVkLLJrUvtINNYIeFkctL2cqS XRM71hCUaLQ1qqE7TPSt5lW5UtgW2De5W6ziT6PlTRfTmdizF46AMZaMuWYG01Ixg0TzoeGt Ijp5WcIE+dTSiPZEvZrrpJD/Q+835goI8ktyfeUaQyPX+6OQcEWtDr46y303uefTmGhB1G5q MmHz6lF+zmTlDGHX1QRf2r9H5xVy5MIuvnrq+h+yCi22iXfV2pyq1km+jWnBHCwPLQePKU65 LnFaN3YchaWs1P7m7a+lR5rJv9tNZQ1hMW0X6nohQSxIKwdI67sKbWih7O+vIdMp6yJftV5u nOpK/uvcWGiJ0Ya+WkUysBzYWxYs/GSdMquWrWhb4fNowbfmqvy96ldmpnTjghbz/r5HafLx Fj6/SdVqVSphItk1UPycxLm2reLxXSjivL9YRYPRkZa2WKOCip1wKh5poTtdWdL505WlFEP/ jytL4XGFafdAd8rup+z+fbN7+m00ctJf4fxq818JirnnA3yNK958atn/jteeqvDvsoiMnKsx MjVc2Z8KZA72BRjhGye+VCVa7cpS4jMD+hw+MxxQQa3RwecfGfIfaHQ1ze70yJA29MU7Hgo/ +UV4nZ9UYE6ISkH9kSHr88dgN+cxrftKYP0IgYXzf+eK5T8bwsCqVZd/LOFeHpmUnEgtGRGE Dcq/PLrBjnFFmOqomXGjnBsru6USlkqmlNsv4kFhgtjtl+lSWeBqGUhgIHTvuepopRuU46Bf yamXPz5JCENyyQRJmBoTJKOeq2UgRwaCGklw0O+nBmF71BBvt4NyHPTbYdBt98sBPi458zLJ dKnMJfVwjQzcUTjo91PZZ5K6QZQUB4NPCJ0YyiwdMvP7wYr1ZL4fzSeGjtWApjoBxS9FpO1g TX2Z70dVX5i/fwEqUlbgZW5kc3RyZWFtCmVuZG9iagoyNCAwIG9iagoxMzI2CmVuZG9iago1 IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9Q YXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAxMiAwIFIKL0ZvbnQgMTMgMCBSCj4+Ci9Db250ZW50cyA2IDAgUgo+PgplbmRvYmoKMTQg MCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAxNyAw IFIKPj4KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoKMTggMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAyMSAwIFIKPj4KL0NvbnRlbnRzIDE5 IDAgUgo+PgplbmRvYmoKMjIgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlhQm94IFswIDAgNjEy IDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERG IC9UZXh0XQovRm9udCAyNSAwIFIKPj4KL0NvbnRlbnRzIDIzIDAgUgo+PgplbmRvYmoKMyAw IG9iago8PCAvVHlwZSAvUGFnZXMgL0tpZHMgWwo1IDAgUgoxNCAwIFIKMTggMCBSCjIyIDAg UgpdIC9Db3VudCA0Cj4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUgL0NhdGFsb2cgL1BhZ2Vz IDMgMCBSCj4+CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRlL05hbWUvUjQvVFIv SWRlbnRpdHk+PgplbmRvYmoKMTIgMCBvYmoKPDwvUjQKNCAwIFI+PgplbmRvYmoKMTMgMCBv YmoKPDwvUjkKOSAwIFIvUjExCjExIDAgUj4+CmVuZG9iagoxNyAwIG9iago8PC9SOQo5IDAg Ui9SMTEKMTEgMCBSPj4KZW5kb2JqCjIxIDAgb2JqCjw8L1I5CjkgMCBSL1IxMQoxMSAwIFI+ PgplbmRvYmoKMjUgMCBvYmoKPDwvUjkKOSAwIFIvUjExCjExIDAgUj4+CmVuZG9iago4IDAg b2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvVGltZXMtUm9tYW4+PgplbmRv YmoKOSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L1RpbWVzLVJvbWFuL1R5cGUv Rm9udC9OYW1lL1I5Pj4KZW5kb2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3Iv Rm9udE5hbWUvVGltZXMtSXRhbGljPj4KZW5kb2JqCjExIDAgb2JqCjw8L1N1YnR5cGUvVHlw ZTEvQmFzZUZvbnQvVGltZXMtSXRhbGljL1R5cGUvRm9udC9OYW1lL1IxMT4+CmVuZG9iagoy IDAgb2JqCjw8L1Byb2R1Y2VyKEVTUCBHaG9zdHNjcmlwdCA3LjA3KT4+ZW5kb2JqCnhyZWYK MCAyNgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDY0NDkgMDAwMDAgbiAKMDAwMDAwNzAx OSAwMDAwMCBuIAowMDAwMDA2MzY5IDAwMDAwIG4gCjAwMDAwMDY0OTcgMDAwMDAgbiAKMDAw MDAwNTc3NyAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDEzOTkgMDAwMDAg biAKMDAwMDAwNjc0NiAwMDAwMCBuIAowMDAwMDA2ODA3IDAwMDAwIG4gCjAwMDAwMDY4ODAg MDAwMDAgbiAKMDAwMDAwNjk0MyAwMDAwMCBuIAowMDAwMDA2NTUyIDAwMDAwIG4gCjAwMDAw MDY1ODIgMDAwMDAgbiAKMDAwMDAwNTkzNyAwMDAwMCBuIAowMDAwMDAxNDE5IDAwMDAwIG4g CjAwMDAwMDI4MzQgMDAwMDAgbiAKMDAwMDAwNjYyMyAwMDAwMCBuIAowMDAwMDA2MDgxIDAw MDAwIG4gCjAwMDAwMDI4NTUgMDAwMDAgbiAKMDAwMDAwNDMzNyAwMDAwMCBuIAowMDAwMDA2 NjY0IDAwMDAwIG4gCjAwMDAwMDYyMjUgMDAwMDAgbiAKMDAwMDAwNDM1OCAwMDAwMCBuIAow MDAwMDA1NzU2IDAwMDAwIG4gCjAwMDAwMDY3MDUgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6 ZSAyNiAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgo+PgpzdGFydHhyZWYKNzA2OQolJUVPRgo= --------------010400010004030801000000-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44EmRLf067550; Wed, 4 May 2005 07:48:27 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j44EmRoV067549; Wed, 4 May 2005 07:48:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j44EmQwP067542 for ; Wed, 4 May 2005 07:48:27 -0700 (PDT) (envelope-from david.cooper@nist.gov) Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j44ElvaB009997 for ; Wed, 4 May 2005 10:47:58 -0400 Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j44ElO9q006301 for ; Wed, 4 May 2005 10:47:24 -0400 (EDT) Message-ID: <4278E0BA.7020706@nist.gov> Date: Wed, 04 May 2005 10:48:26 -0400 From: "David A. Cooper" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pkix Subject: Disposition of Comments for 3280bis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-MailScanner-From: david.cooper@nist.gov Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Here is the disposition of comments for 3280bis (http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-00.txt). There is a Diff file on the NIST Web site at http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html that highlights the differences between RFC 3280 and draft -00 of 3280bis. If you submitted a comment and do not believe that it was addressed in the disposition of comments below, please let me know and I will look into it. Please note, however, that draft -00 of 3280bis was originally submitted on February 13 and that the disposition of comments is based on comments that were submitted in late 2004 (or earlier). A few comments have been sent to the PKIX list about 3280bis since mid-February. These comments are not addressed in 3280bis-00 or in the notes below, but will be considered before draft -01 of 3280bis is submitted. Thanks, Dave ----------------------------------------------------------------------------------------------------- 3280bis disposition of comments: 1) There is confusion about the use of the term "CRL issuer" in RFC 3280. In section 3, the explanation of the "CRL issuer" component of Figure 1 has been modified as has the description of "CRL issuer" in section 5. Both note that the CRL issuer is either the CA or an entity that has been delegated the responsibility for issuing CRLs by the CA. 2) There is confusion about whether a CA is identified by its name alone or by a combination of name and key pair. The confusion mainly focused on the scope of CRLs. Section 5 of 3280bis includes the following: A full and complete CRL lists all unexpired certificates issued by a CA that have been revoked for any reason. (Note that since CAs and CRL issuers are identified by name, the scope of a CRL is not affected by the key used to sign the CRL or the key(s) used to sign certificates.) 3) RFC 3280 states that all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString, with some exceptions. 3280bis states that either the PrintableString or UTF8String encoding of DirectoryString MUST be used, except for previously established names that use a different encoding. 4) 3280bis should incorporate the rules for encoding and comparing internationalized name forms. A new section 7 has been added which covers comparing directoryNames using the rules from LDAP StringPrep. Section 7 also covers the encoding and comparison of internationalized domain names and Internationalized Resource Identifiers. 5) There are problems with text in RFC 3280 regarding "name rollover" certificates to support an orderly migration to UTF8String The text about "name rollover" certificates has been deleted. 6) For validity dates, RFC 3280 imposes generation requirements for CAs but does not include requirements for relying parties 3280bis says: "Conforming applications MUST be able to process validity dates that are encoded in either UTCTime or GeneralizedTime." This applies to the thisUpdate and nextUpdate fields of CRLs as well. 7) RFC 3280 states that applications should be capable of processing unique identifiers, but it is not clear what, if any, processing requirements there are. 3280bis explicitly states that there are no processing requirements associated with unique identifiers. 8) The meaning of critical vs. non-critical certificate extension should be clarified. 3280 bis states: "A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it can not process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized." 9) RFC 3280 states that conforming applications must be able to process the name constraints extension, but does not specify which name forms must be supported. 3280bis states that conforming applications MUST be able to process name constraints for directoryName and SHOULD be able to process name constraints for rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress. 3280bis further states that conforming CAs MUST NOT impose name constraints on the x400Address, ediPartyName, or registeredID name forms. 10) RFC 3280 states that conforming applications SHOULD support the policyMappings extension and MUST support the policyConstraints extension. It seems inappropriate to require support for the inhibitPolicyMapping field of policyConstraints without requiring support for the policyMappings extension. 3280bis states that conforming applications MUST support the requireExplicitPolicy field of policyConstraints and SHOULD support the inhibitPolicyMapping field of policyConstraints. 3280bis further states that applications that support the inhibitPolicyMapping field of policyConstraints MUST also support the policyMappings field. 3280bis also requires CAs to mark this policyConstraints as critical. 11) 3280bis should clearly explain that there is no requirement as part of path validation that authorityKeyIdentifiers and subjectKeyIdentifiers match. Section 4.2.1.2 (Subject Key Identifier) now says: "Applications are not required to verify that key identifiers match when performing certification path validation." The requirement for issuing CAs to place matching key identifiers in the certificates that they issue is still present. 12) RFC 3280 states that one common method for generating key identifiers is a monotonically increasing sequence number. Shouldn't key identifiers be globally unique (or at least shouldn't one try to avoid collisions). The phrase "One common method for generating unique values is a monotonically increasing sequence of integers." has be replaced with "Other methods of generating unique numbers are also acceptable." 13) The descriptions of the meanings of the digitalSignature and nonRepudiation bits of keyUsage may need to be adjusted based on the work in X.509 The new text in X.509 aligns with the text in RFC 3280. No changes are required to 3280bis. A comment has been added to the ASN.1 for KeyUsage stating that "recent editions of X.509 have renamed [the nonRepudiation] bit to contentCommitment" 14) 3280bis should note that there may be security issues associated with setting both the digitalSignature and nonRepudiation bits in a certificate. A sentence was added to section 4.2.1.3 (Key Usage) stating: "Combining the nonRepudiation bit in the keyUsage certificate extension with other keyUsage bits may have security implications depending on the context in which the certificate is to be used." 15) RFC 3280 states that the privateKeyUsagePeriod extension "SHOULD NOT be used within the Internet PKI." 3280bis should to changed to state that this may MAY be used. The contents of the section describing the privateKeyUsagePeriod extension were not changed but were moved to appendix D, a new appendix for listing extensions that are outside the scope of the profile. 16) 3280bis should state that a certificate policy OID may appear at most once in a certificatePolicies extension. A sentence was added to the first paragraph of section 4.2.1.4 (Certificate Policies) stating this. 17) RFC 3280 states "The application software SHOULD display all user notices in all certificates of the certification path used, except that if a notice is duplicated only one copy need be displayed." This is inconsistent with section 6, which specifies that only those user notices associated with policies that appear in every certificate in the path (either directly or through mapping) are returned to the application for display. Section 4.2.1.4 (Certificate Policies) states that only those user notices that are returned as a result of path validation are intended for display to the user. It is also noted that this applies to any other policy qualifiers. 18) The user notice qualifier makes use of DisplayText, which is a CHOICE of four different string encoding options. Unlike with DirectoryString in the issuer and subject fields, RFC 3280 provides no guidance on which encodings to use. 3280bis states: "Conforming CAs SHOULD use the UTF8String encoding for explicitText, but MAY use IA5String. Conforming CAs MUST NOT encode explicitText as VisibleString or BMPString." 19) For the policyMappings extension, RFC 3280 states that policies SHOULD NOT be mapped to or from anyPolicy, but section 6 states that relying parties MUST reject any certificate that includes a policyMappings extension that maps to or from anyPolicy. Section 4.2.1.5 (Policy Mappings) of 3280bis states that policies MUST not be mapped to or from anyPolicy. 20) RFC 3280 states that the policyMappings extension MUST be marked non-critical, however given the processing semantics for this extension it may be appropriate to mark the extension critical. X.509 allows for the extension to be marked either critical or non-critical. 3280bis states that the policyMappings extensions SHOULD be marked critical. 21) There is a need to be able to specify name constraints for URIs that limit schemes that may be specified. 3280bis includes an extended set of rules for specifying name constraints on URIs. 22) The rules for specifying name constraints on DNS names are unclear. Does "myexample.com" satisfy a constraint of "example.com"? 3280bis states that "DNS name restrictions are expressed as host.example.com. Any DNS name that can be constructed by simply adding subdomains to the left hand side of the name satisfies the name constraint." 23) 3280bis should clearly state the rules for processing a name constraints extension that specifies constraints on name forms that an application is unable to process. 3280bis states that if a critical name constraints extension specifies a constraint for a name form and a name of that name form appears in a subsequent certificate, then the application must either process the constraint or reject the certificate. 24) 3280bis needs to provide more information about the use of URIs in the cRLDistributionPoints extension. 3280bis provides information about HTTP and LDAP URIs. It indicates that an HTTP URI MUST point to a file containing a DER encoded CRL. It also provides rules for the format of an LDAP URI. 25) RFC 3280 states that when a distribution point name in a cRLDistributionPoints extension is specified as a URI, the URI MUST include a fully qualified domain name or IP address as the host. 3280bis should allow for the use of LDAP URIs that do not specify a host name. 3280bis removes this requirement by no longer specifying that the encoding rules specified for URIs in the subjectAltName extension apply to the cRLDistributionPoints extension. 3280bis also explicitly states that the host name is optional in LDAP URIs in the cRLDistributionPoints extension. 26) RFC 3280 states that if the cRLIssuer field is present in cRLDistributionPoints, it MUST contain at least one X.500 DN. 3280bis should state that this DN must be the DN from the issuer field of the referenced CRL. 3280bis states that the cRLIssuer field MUST only contain the DN from the issuer field of the referenced CRL and that the DN MUST be encoded identically in both places. 27) 3280bis should deprecate segmented CRLs by reason code. 3280bis RECOMMENDS against segmenting CRLs by reason code and requires that certificates that include a cRLDistributionPoints extension MUST include at least one distribution point that points to a CRL that covers the certificate for all reasons. 28) RFC 3280 states that for the id-ad-caIssuers assess method of authorityInfoAccess and the id-ad-caRepository access method of subjectInfoAccess when the accessLocation is a directoryName the information is to be obtained using DAP. This is inconsistent with the cRLDistributionPoints extension where the protocol used to obtain the information is not defined by the standard but is instead considered to be a local matter. 3280bis states that for the authorityInfoAccess and subjectInfoAccess extensions that when accessLocation is a directoryName the protocol used to obtain the information from the directory is a local matter. 29) RFC 3280 states that for the id-ad-caIssuers assess method of authorityInfoAccess and the id-ad-caRepository access method of subjectInfoAccess the access location may be an http, ftp, or ldap URI or an rfc822Name but no information is provided on the format of the URIs or the format of the data that will be retrieved using these access methods. 3280bis specifies the format for LDAP URIs and specifies that FTP and HTTP URIs must point to files that contain either certificates or certs-only CMS messages. The use of rfc822Name as in accessLocation is not mentioned. 30) For the cRLDistributionPoints extension, RFC 3280 clearly states that if a single distribution point contains multiple distribution point names that each distribution point name describes a different mechanism for obtaining the same CRL, whereas distribution point names that appear in different distribution points may point to different CRLs. What is the rule for the authorityInfoAccess and subjectInfoAccess extensions? If an AIA extension includes more than one instance of the id-ad-caIssuers access method, does each instance provide a different mechanism for obtaining the same information or could different instances of the access method point to different information. 3280bis states that different instances of the access method may specify different methods for accessing the same information or may point to different information. 31) RFC 3280 states: "Although the [issuingDistributionPoint] extension is critical, conforming implementations are not required to support this extension." Some people have interpreted this to mean that implementations that are unable to process the extension may ignore it even though it is marked critical. The following sentence has bee added to 3280bis: "However, implementations that do not support this extension MUST either treat the status of any certificate not listed on this CRL as unknown or locate another CRL that does not contain any unrecognized critical extensions." 32) In X.509, there is a proposal to revert to the original version of the issuingDistributionPoint extension, which did not include the onlyContainsAttributeCerts field, and a new extension has been proposed for attribute certificates. [Note: The design team was unable to verify whether this proposal has been approved in X.509] The design team decided to continue to use the ASN.1 from RFC 3280 for the issuingDistributionPoint extension. However, the text now explicitly states that the onlyContainsAttributeCerts field MUST be set to FALSE, since 3280bis only covers public key certificates. When onlyContainsAttributeCerts is set to FALSE, the DER encoding and semantics of the issuingDistributionPoint extension are the same as if the onlyContainsAttributeCerts were not present. 33) The certificateIssuer CRL entry extension contains a GeneralNames. While RFC 3280 does not state this, there seems to be general agreement that the certificateIssuer extension should only contain the DN from the issuer field of the certificate being revoked. 3280bis states: "Conforming CRL issuers MUST include in [the certificateIssuer] extension the distinguished name (DN) from the issuer field of the certificate that corresponds to this CRL entry. The encoding of the DN MUST be identical to the encoding used in the certificate." 34) X.509 states that a certificate may not appear in a certification path more than once. 3280bis should impose the same restriction. Section 6.1 of 3280bis states that a certificate MUST NOT appear more than once in a prospective certification path. 35) The path validation algorithm should indicate how to perform validations for times other than the current time. Adding information about how to perform validations for some time other than the current time was considered to be outside the scope of changes that could be made in 3280bis. 36) The criticality_indicator variable in the nodes of the valid_policy_tree seems to have no application in the algorithm and so it should be removed. The criticality_indicator variable has been removed from the nodes of the valid_policy_tree. 37) Section 6.1.2 of RFC 3280 specifies the initial values for the state variables. Can these variables be set to different initial values in order to impose additional constraints? Section 6.2 of RFC 3280 already states that this is permitted. Section 6.2 of 3280bis includes additional text referring to the possibility of using certificate extensions from self-signed certificates to set these initial values. 38) Section 6.1.4 of RFC 3280 states that one must verify that intermediate certificates are CA certificates using either the contents of the basicConstraints extension or out-of-band means. X.509 states that a version 3 certificate that does not include a basicConstraints extension must not be considered a CA certificate. 3280bis states that for a version 3 intermediate certificate the basicConstraints extension must be present with cA set to TRUE. Conforming applications may either reject all version 1 and version 2 intermediate certificates or may use out-of-band means to verify that they are CA certificates. 39) In section 6.1.5, RFC 3280 states that the explicit_policy variable is only decremented if the final certificate in the certification path is not self-issued. In X.509, the final certificate in a certification path is treated the same way whether it is self-issued or not. In order to make 3280bis consistent with X.509, 3280bis has been changed to state that the explicit_policy variable is always decremented as part of the wrap-up step, whether the final certificate is self-issued or not. 40) Section 6.3 of RFC 3280 states: "Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure." This should be clarified. For example, the CRL validation algorithm in RFC 3280 will only validate a delta-CRL if it was signed using the same key as the corresponding complete CRL. While RFC 3280 requires CRL issuers to sign delta-CRLs using the same key as the key used to sign the corresponding base CRL, this is not an X.509 requirement. Conforming implementations should be permitted to accept delta-CRLs that were signed using a different key even though they are not required to be able to do so. 3280bis has replaced the referenced sentence with: "Conforming implementations that support CRLs are not required to implement this algorithm, but they MUST be functionally equivalent to the external behavior resulting from this procedure when processing CRLs that are issued in conformance with this profile." 41) Section 6.3.1 of RFC 3280 states: "Note that implementations supporting legacy PKIs, such as RFC 1422 and X.509 version 1, will need an additional input indicating whether the supplied certificate is associated with a CA or an end entity." What is the reason for this statement? The only reason that one might need to know whether a certificate is a CA certificate or end entity certificate when validating a CRL is if the CRL includes an issuingDistributionPoint extension with onlyContainsUserCerts or onlyContainsCACerts set to TRUE. But, when one of these is set, the algorithm in section 6.3.3 relies on the basicConstraints extension to determine the type of certificate. The sentence quoted above has been deleted. Section 5.2.5 (Issuing Distribution Point) of 3280bis now states: "If either onlyContainsUserCerts or onlyContainsCACerts is set to TRUE then the scope of the CRL MUST NOT include any version 1 or version 2 certificates." 42) There seems to be two problems with the algorithm in section 6.3.3 when CRLs are segmented by reason code. The algorithm defines a value all-reasons that is the set of reason codes from the CRLReason type. The algorithm continues until CRLs are located that cover all of the reasons in all-reasons. If a CRL cannot be located that covers one or more of the reasons in all-reasons, then the algorithm fails. But, the set of reasons covered by a CRL is specified using the ReasonFlags bit string. In ReasonFlags, however, "unspecified" is replaced by "unused". So, the algorithm will never complete successfully when CRLs are segmented by reason since no CRL can specify that it covers the "unspecified" reason code. It is also not clear on which CRL to include certificates that have been revoked with a reason code of unspecified. In 3280bis, "unspecified" has been removed from all-reasons. In addition, section 5.2.5 (Issuing Distribution Point) of 3280bis states that if a CRL includes an issuingDistributionPoint extension with onlySomeReasons present then every certificate in the scope of that CRL that is revoked must be assigned a revocation reason other than unspecified. 43) It should be noted in 3280bis that there is a risk that two different CAs (or a CA and a CRL issuer) may issue certificates and CRLs under the same name and that if this happens there is a risk that a relying party will validate a certificate issued by one of these entities using a CRL issued by the other. The security considerations section of 3280bis states that CAs and CRL issuers should be formed in a way that reduces the likelihood of name collisions. It also states that implementations validating CRLs MUST ensure that the certification path of the target certificate and the CRL issuer certification path used to validate the target certificate terminate at the same trust anchor. 44) The text from RFC 2510 on root key update should be included in 3280bis. The security considerations section of 3280bis includes a pointer to RFC 2510. Received: from host-148-244-153-252.block.alestra.net.mx ([148.244.153.252]) by above.proper.com (8.12.11/8.12.9) with SMTP id j43Aw5OG057093; Tue, 3 May 2005 03:58:22 -0700 (PDT) (envelope-from mtmjjirtihjgy@idt.net) X-Message-Info: 47npvKNuKK63DBQbylII2TTK361MnyNiBMjSWx685SSW Received: from mindspring.net (138.231.130.249) by y973-su37.mindspring.net with Microsoft SMTPSVC(3.6.1281.4412); Tue, 03 May 2005 10:56:19 -0100 Received: from mindspring.net (mindspring.net 24.236.210.212) by mindspring.net (8.12.10/8.12.9) with ESMTP id sj86HVT367 for ; Tue, 03 May 2005 12:55:19 +0100 (EST) (envelope-from mtmjjirtihjgy@idt.net) Received: from ZN270429408146 (modemcable34.6876-8.ar.mindspring.net 0.200.32.147) (authenticated bits=5) by mindspring.net (8.12.10/8.12.9) with ESMTP id mpq43Z75p916 for ; Tue, 03 May 2005 12:54:19 +0100 (EST) (envelope-from mtmjjirtihjgy@idt.net) Message-ID: <14775i33lpj2$p855rkc25d0$276dr647xy8@VH081727058662> From: "Shirley Marin" To: Subject: FW: impressive carttier repliccas esp. for you cosmetic Date: Tue, 03 May 2005 04:57:19 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--bpcywcmx93210mcgiyeldz" ----bpcywcmx93210mcgiyeldz Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Now presenting: You know you've allways wanted it - watchees: elegent, fancy, impressive repliccas! You can impress you're lady/man with: roleex (including vip roleex), carttier, braitling, bulgari and much much more... The bast brand s in the world! Just naame it - We got it :) hmmmmm i just can't wait :) http://couldn't.hiltiimfj.com/?6oE88HDKSadeBCCalder would like to build one heck of a sleeper to shut up some car owners who think that theirs is unbeatable! might make a good manager for it that club is almost certainly arizona for which melvin had been bench coach under bob brenly who was fired as manager earlier this season. artists and record labels from all over the world can now sell their music directly in digital format. do you have an awesome poster of the tipi s available? for those of us who a re still tryin to make it to crow. you really are multi-faceted dan your comic is well drawn and intriguing so you re my first link! keep it going. nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp all the girls i know. which lists a cool or inventive or new robots of interest for you with easy links one for every week go check it out! son mike ford leicester city devices town - non-league cardiff city oxford united cardiff city oxford united - player manager thame utd - non didcot town brackley town - player coach. half truths at best but most absolute lies is what the state of texas depended on to convict me and sentence me to death by lethal injection. very interesting site its so stimulating to view different sites and their content and designs. well youre more than wecome like i said u do good work here i enjoy dropping in to see whats going on its like takinga trip but never really leaving ya know? congrats again! what can i say? you ve probably heard enough praise already? although your site really is very good keep up the good work! old stories and sorta-local and state stories it will also bring up amazon s bestseller list for that zipcode for the area i grew up in which used to vote republican. for information on antioxidant levels in fruits and vegetables see the u s department of agriculture. on returning from the debauched break last week and immediately found themselves in hot water with the mother-superior. ----bpcywcmx93210mcgiyeldz-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42IQlCp073325; Mon, 2 May 2005 11:26:47 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j42IQlNe073324; Mon, 2 May 2005 11:26:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f Received: from smtprelay-us1.aopn-na.com (smtprelay-us1.aopn-na.com [12.174.169.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j42IQjCw073296 for ; Mon, 2 May 2005 11:26:46 -0700 (PDT) (envelope-from Joel.Kazin@atosorigin.com) Received: from usarx003.arl.us.origin-it.com (usarx003.arl.us.int.atosorigin.com [172.16.146.33]) by smtprelay-us1.aopn-na.com (Postfix) with ESMTP id 53E0E5FDAD; Mon, 2 May 2005 13:26:16 -0500 (CDT) Received: by usarx003.arl.us.int.atosorigin.com with Internet Mail Service (5.5.2448.0) id ; Mon, 2 May 2005 13:26:15 -0500 Message-ID: <5.1.0.14.0.20050502141922.00b1c318@172.16.146.192> From: "Kazin, Joel" To: key_mgmt@nist.gov Cc: ietf-pkix@imc.org Subject: SP 800 57 Part II Date: Mon, 2 May 2005 13:27:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C54F44.6CDCAB7E" Sender: owner-ietf-pkix@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C54F44.6CDCAB7E Content-Type: text/plain; charset="iso-8859-1" The draft document beginning in section 3.2.1.1 makes several references to the RFC 2527 framework. While I agree with the general approach in the draft, RFC 2527 is obsolete having been superceded by RFC 3647 in November of 2003. While the content of the framework of RFC 2527 was not greatly changed by RFC 3647, the organization was. There is a useful set of cross-references between the two frameworks at the back of RFC 3647. Joel S. Kazin CPA, CISA, CISSP, CISM Senior Consultant Atos Origin 40 Old Sleepy Hollow Road Pleasantville, New York 10570-3802 USA Phone +1 914-769-8780 Mobile +1 914-564-1484 email joel.kazin@atosorigin.com www.atosorigin.com ------_=_NextPart_001_01C54F44.6CDCAB7E Content-Type: text/html; charset="iso-8859-1" SP 800 57 Part II

The draft document beginning in section 3.2.1.1 makes several references to
the RFC 2527 framework. While I agree with the general approach in the
draft, RFC 2527 is obsolete having been superceded by RFC 3647 in November
of 2003.  While the content of the framework of RFC 2527 was not greatly
changed by RFC 3647, the organization was. There is a useful set of
cross-references between the two frameworks at the back of RFC 3647.


Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    joel.kazin@atosorigin.com
www.atosorigin.com

------_=_NextPart_001_01C54F44.6CDCAB7E--