idnits 2.17.1 draft-santesson-credsel-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 319. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 325. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2006) is 6372 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 95 -- Looks like a reference, but probably isn't: '1' on line 96 ** Obsolete normative reference: RFC 3280 (ref. 'N2') (Obsoleted by RFC 5280) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Santesson (Microsoft) 3 Intended Status: Proposed Standard 4 Expires May 2008 November 2006 6 Credential Selection Criteria Data Structure 7 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document defines a generic data structure for expression of 35 credential selection criteria. This data structure may be used by 36 multiple security protocols as a common model for credential 37 selection. 39 1. Introduction 41 This document defines a generic data structure for expression of 42 credential selection criteria. This data structure may be used by 43 multiple security protocols as a common model for credential 44 selection. 46 Selection of appropriate credentials can be a significant burden on 47 parties of a secure protocol exchange. This is the case in particular 48 when multiple credentials are available for each party and where the 49 preferences of the opponent are un-known or inadequately exchanged. 51 An example of this is when a client has many X.509 certificates 52 matching the list of Certification Authorities allowed by the server 53 in the initialization of a TLS session. 55 In general, this is a problem for many security protocols. As 56 expression of credential selection preferences is complex, 57 implementations would benefit from a common method for credential 58 selection that can be exchanged in multiple protocols through their 59 extensibility mechanisms. 61 Other documents will specify how the data structures defined in this 62 document can be carried inside specific security protocols. 64 1.1 Terminology 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [N1]. 70 2. Selection Criteria 72 This section defines the SelectionCriteria data structure. This data 73 structure holds criteria for selecting a credential among a set of 74 multiple credentials. 76 Each protocol that makes use of this data structure MUST define its 77 own conventions for how it is carried in the protocol. 79 SelectionCriteria ::= SEQUENCE OF Criteria 81 Criteria ::= { 82 credentialType OBJECT IDENTIFIER --identifier for 83 --credential type 84 selectData SelectData } 86 SelectData ::= SEQUENCE { 87 basicSelectData [0] BasicSelectData OPTIONAL 88 advancedSelectData [1] AdvancedSelectData OPTIONAL} 90 AdvancedSelectData ::= { 91 selectSyntaxID OBJECT IDENTIFIER 92 selectData ANY DEFINED BY selectSyntaxID ] 94 BasicSelectData ::= SEQUENCE { 95 includeStrings [0] SelectStrings OPTIONAL 96 excludeStrings [1] SelectStrings OPTIONAL } 98 SelectStrings ::= SEQUENCE OF AltValues 100 AltValues ::= SEQUENCE OF OCTET STRING 102 cretentialType 103 credentialType contains an Object Identifier (OID) defining the 104 type of credential that is selected using the provided selectData. 105 A credentialType OID defines both the type of credential as well 106 as any preparation requirements, such as encoding format, state of 107 decrypting and decoding credential data etc, which is required 108 before the credential is processed against the slectData. 109 credentialType OIDs are defined in section 3. 111 SelectData 112 The selectData element MUST include either basicSelectData or 113 advancedSelectData or both. The basicSelectData is defined in this 114 document while advancedSelectData is extensible to allow future 115 definition of alternative or complementary selectData. Each 116 advancedSelectData type is identified by an OID. 118 includeStrings 119 includeStrings is used to store strings that are matched against 120 the normalized credential. Any string that matches any part of a 121 credential is a positive match for that credential. Each search 122 string can have several alternative values that are considered a 123 positive match. 125 excludeStrings 126 excludeStrings is used to store strings that are matched against 127 the normalized credential. Any string that matches any part of a 128 credential is a negative match for that credential. Each search 129 string can have several alternative values that are considered a 130 negative match. 132 Scoring match results 133 A match is scored when at least one of the AltValues of a 134 SelectStrings matches any part of the normalized credential. 136 Local policy or the protocol being used MAY further specify these 137 rules, such as if it is allowed to try the best matching 138 credential even if it has scored one or more negative matches. 140 3 credentialType ObjectIdentifiers 142 The following credentialType object identifiers are defined: 144 -- Service Name Object Identifier and Syntax 145 -- id-pkix OBJECT IDENTIFIER ::= {1 3 6 1 5 5 7} 147 id-ct OBJECT IDENTIFIER ::= { id-pkix n } 149 id-on-x509 OBJECT IDENTIFIER ::= { id-ct n } 150 -- Other identifiers TBD 152 Other Object Identifiers can be defined in other documents. 154 5 Security Considerations 156 TBD 158 6 IANA Considerations 160 TBD 162 7 Normative References 164 [N1] S. Bradner, "Key words for use in RFCs to Indicate 165 Requirement Levels", BCP 14, RFC 2119, March 1997. 167 [N2] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet 168 X.509 Public Key Infrastructure: Certificate and 169 Certificate Revocation List (CRL) Profile", RFC 3280, 170 April 2002. 172 Appendix A. ASN.1 Syntax 174 As in RFC 2459, ASN.1 modules are supplied in two different 175 variants of the ASN.1 syntax. 177 This section describes data objects used by conforming PKI 178 components in an "ASN.1-like" syntax. This syntax is a hybrid of 179 the 1988 and 1993 ASN.1 syntaxes. The 1988 ASN.1 syntax is 180 augmented with the 1993 UNIVERSAL Type UTF8String. 182 The ASN.1 syntax does not permit the inclusion of type statements 183 in the ASN.1 module, and the 1993 ASN.1 standard does not permit 184 use of the new UNIVERSAL types in modules using the 1988 syntax. 185 As a result, this module does not conform to either version of the 186 ASN.1 standard. 188 Appendix A.1 may be parsed by an 1988 ASN.1-parser by replacing 189 the definitions for the UNIVERSAL Types with the 1988 catch-all 190 "ANY". 192 Appendix A.2 may be parsed "as is" by an 1997-compliant ASN.1 193 parser. 195 In case of discrepancies between these modules, the 1988 module is 196 the normative one. 198 Appendix A.1. 1988 ASN.1 Module 200 PKIXServiceNameSAN88 {iso(1) identified-organization(3) dod(6) 201 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 202 id-mod-xxxxxx-88(nn) } 204 DEFINITIONS EXPLICIT TAGS ::= 206 BEGIN 208 -- EXPORTS ALL -- 210 IMPORTS 212 -- UTF8String, / move hyphens before slash if UTF8String does not 213 -- resolve with your compiler 215 id-pkix 216 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 217 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 218 id-mod(0) id-pkix1-explicit(18) } ; 219 -- from RFC3280 [N2] 221 -- Syntax TBD 222 END 224 Appendix A.2. 1993 ASN.1 Module 226 PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) 227 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 228 id-mod-xxxxxxxxxx-93(nn) } 230 DEFINITIONS EXPLICIT TAGS ::= 232 BEGIN 234 -- EXPORTS ALL -- 236 IMPORTS 238 id-pkix 239 FROM PKIX1Explicit88 { iso(1) identified-organization(3) 240 dod(6) internet(1) security(5) mechanisms(5) pkix(7) 241 id-mod(0) id-pkix1-explicit(18) } ; 242 -- from RFC 3280 [N2] 244 -- Syntax TBD 246 END 248 Appendix B. Examples 250 This example illustrates the principle use of BasicSelectData when 251 applied to X.509 certificate selection. 253 BasicSelectData (SEQUENCE) 254 Include strings (SEQUENCE) 255 - Altvalues (SEQUENCE) 256 - Certificate policy 1 OID 257 - Certificate policy 2 OID 258 - Altvalues (SEQUENCE) 259 - Key usage extension (with only digital signature 260 bit set) 261 Exclude strings 262 - Altvalues (SEQUENCE) 263 - EKU A OID 264 - EKU B OID 266 A certificate matches these selectData if the certificate meets 267 all of following conditions: 268 - includes certificate policy 1 or certificate policy 2 (or both) 269 - includes a key usage extension with only the digital signature 270 bit set 271 - does not contain EKU OID A 272 - does not contain EKU OID B 274 Coded examples (b64 and DER encoded) TBD 276 Authors' Addresses 278 Stefan Santesson 279 Microsoft 280 Finlandsg. 30 281 16493 KISTA 282 Sweden 284 EMail: stefans@microsoft.com 286 Full Copyright Statement 288 Copyright (C) The IETF Trust (2007). 290 This document is subject to the rights, licenses and restrictions 291 contained in BCP 78, and except as set forth therein, the authors 292 retain all their rights. 294 This document and the information contained herein are provided on 295 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 296 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 297 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 298 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 299 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 300 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 301 FOR A PARTICULAR PURPOSE. 303 Intellectual Property 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed 307 to pertain to the implementation or use of the technology 308 described in this document or the extent to which any license 309 under such rights might or might not be available; nor does it 310 represent that it has made any independent effort to identify any 311 such rights. Information on the procedures with respect to rights 312 in RFC documents can be found in BCP 78 and BCP 79. 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use 317 of such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository 319 at http://www.ietf.org/ipr. 321 The IETF invites any interested party to bring to its attention 322 any copyrights, patents or patent applications, or other 323 proprietary rights that may cover technology that may be required 324 to implement this standard. Please address the information to the 325 IETF at ietf-ipr@ietf.org. 327 Expires May 2008