INTERNET-DRAFT S. Santesson (Microsoft) Intended Status: Proposed Standard Expires May 2008 November 2006 Credential Selection Criteria Data Structure Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines a generic data structure for expression of credential selection criteria. This data structure may be used by multiple security protocols as a common model for credential selection. Santesson [Page 1] INTERNET DRAFT DNS SRV RR otherName November 2007 1. Introduction This document defines a generic data structure for expression of credential selection criteria. This data structure may be used by multiple security protocols as a common model for credential selection. Selection of appropriate credentials can be a significant burden on parties of a secure protocol exchange. This is the case in particular when multiple credentials are available for each party and where the preferences of the opponent are un-known or inadequately exchanged. An example of this is when a client has many X.509 certificates matching the list of Certification Authorities allowed by the server in the initialization of a TLS session. In general, this is a problem for many security protocols. As expression of credential selection preferences is complex, implementations would benefit from a common method for credential selection that can be exchanged in multiple protocols through their extensibility mechanisms. Other documents will specify how the data structures defined in this document can be carried inside specific security protocols. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [N1]. 2. Selection Criteria This section defines the SelectionCriteria data structure. This data structure holds criteria for selecting a credential among a set of multiple credentials. Each protocol that makes use of this data structure MUST define its own conventions for how it is carried in the protocol. SelectionCriteria ::= SEQUENCE OF Criteria Criteria ::= { credentialType OBJECT IDENTIFIER --identifier for --credential type selectData SelectData } Santesson [Page 2] INTERNET DRAFT DNS SRV RR otherName November 2007 SelectData ::= SEQUENCE { basicSelectData [0] BasicSelectData OPTIONAL advancedSelectData [1] AdvancedSelectData OPTIONAL} AdvancedSelectData ::= { selectSyntaxID OBJECT IDENTIFIER selectData ANY DEFINED BY selectSyntaxID ] BasicSelectData ::= SEQUENCE { includeStrings [0] SelectStrings OPTIONAL excludeStrings [1] SelectStrings OPTIONAL } SelectStrings ::= SEQUENCE OF AltValues AltValues ::= SEQUENCE OF OCTET STRING cretentialType credentialType contains an Object Identifier (OID) defining the type of credential that is selected using the provided selectData. A credentialType OID defines both the type of credential as well as any preparation requirements, such as encoding format, state of decrypting and decoding credential data etc, which is required before the credential is processed against the slectData. credentialType OIDs are defined in section 3. SelectData The selectData element MUST include either basicSelectData or advancedSelectData or both. The basicSelectData is defined in this document while advancedSelectData is extensible to allow future definition of alternative or complementary selectData. Each advancedSelectData type is identified by an OID. includeStrings includeStrings is used to store strings that are matched against the normalized credential. Any string that matches any part of a credential is a positive match for that credential. Each search string can have several alternative values that are considered a positive match. excludeStrings excludeStrings is used to store strings that are matched against the normalized credential. Any string that matches any part of a credential is a negative match for that credential. Each search string can have several alternative values that are considered a negative match. Santesson [Page 3] INTERNET DRAFT DNS SRV RR otherName November 2007 Scoring match results A match is scored when at least one of the AltValues of a SelectStrings matches any part of the normalized credential. Local policy or the protocol being used MAY further specify these rules, such as if it is allowed to try the best matching credential even if it has scored one or more negative matches. 3 credentialType ObjectIdentifiers The following credentialType object identifiers are defined: -- Service Name Object Identifier and Syntax -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7} id-ct OBJECT IDENTIFIER ::= { id-pkix n } id-on-x509 OBJECT IDENTIFIER ::= { id-ct n } -- Other identifiers TBD Other Object Identifiers can be defined in other documents. Santesson [Page 4] INTERNET DRAFT DNS SRV RR otherName November 2007 5 Security Considerations TBD 6 IANA Considerations TBD 7 Normative References [N1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [N2] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. Santesson [Page 5] INTERNET DRAFT DNS SRV RR otherName November 2007 Appendix A. ASN.1 Syntax As in RFC 2459, ASN.1 modules are supplied in two different variants of the ASN.1 syntax. This section describes data objects used by conforming PKI components in an "ASN.1-like" syntax. This syntax is a hybrid of the 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is augmented with the 1993 UNIVERSAL Type UTF8String. The ASN.1 syntax does not permit the inclusion of type statements in the ASN.1 module, and the 1993 ASN.1 standard does not permit use of the new UNIVERSAL types in modules using the 1988 syntax. As a result, this module does not conform to either version of the ASN.1 standard. Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing the definitions for the UNIVERSAL Types with the 1988 catch-all "ANY". Appendix A.2 may be parsed "as is" by an 1997-compliant ASN.1 parser. In case of discrepancies between these modules, the 1988 module is the normative one. Appendix A.1. 1988 ASN.1 Module PKIXServiceNameSAN88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-xxxxxx-88(nn) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS -- UTF8String, / move hyphens before slash if UTF8String does not -- resolve with your compiler id-pkix FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) Santesson [Page 6] INTERNET DRAFT DNS SRV RR otherName November 2007 id-mod(0) id-pkix1-explicit(18) } ; -- from RFC3280 [N2] -- Syntax TBD END Appendix A.2. 1993 ASN.1 Module PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-xxxxxxxxxx-93(nn) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS id-pkix FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ; -- from RFC 3280 [N2] -- Syntax TBD END Santesson [Page 7] INTERNET DRAFT DNS SRV RR otherName November 2007 Appendix B. Examples This example illustrates the principle use of BasicSelectData when applied to X.509 certificate selection. BasicSelectData (SEQUENCE) Include strings (SEQUENCE) - Altvalues (SEQUENCE) - Certificate policy 1 OID - Certificate policy 2 OID - Altvalues (SEQUENCE) - Key usage extension (with only digital signature bit set) Exclude strings - Altvalues (SEQUENCE) - EKU A OID - EKU B OID A certificate matches these selectData if the certificate meets all of following conditions: - includes certificate policy 1 or certificate policy 2 (or both) - includes a key usage extension with only the digital signature bit set - does not contain EKU OID A - does not contain EKU OID B Coded examples (b64 and DER encoded) TBD Santesson [Page 8] INTERNET DRAFT DNS SRV RR otherName November 2007 Authors' Addresses Stefan Santesson Microsoft Finlandsg. 30 16493 KISTA Sweden EMail: stefans@microsoft.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention Santesson [Page 9] INTERNET DRAFT DNS SRV RR otherName November 2007 any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Expires May 2008 Santesson [Page 10]