INTERNET-DRAFT S. Santesson (Microsoft)
Intended Status: Proposed Standard
Expires May 2008 November 2006
Credential Selection Criteria Data Structure
<draft-santesson-credsel-01.txt>
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]