Internet DRAFT - draft-harkins-application-csrattrs-media-type

draft-harkins-application-csrattrs-media-type






Internet Engineering Task Force                          D. Harkins, Ed.
Internet-Draft                                            Aruba Networks
Intended status: Informational                            S. Turner, Ed.
Expires: December 23, 2012                                     IECA, Inc
                                                           June 21, 2012


                  The application/csrattrs Media Type
            draft-harkins-application-csrattrs-media-type-00

Abstract

   This document specifies a media type used by Certification
   Authorities (CAs) to indicate which attributes a client should
   include in their Certification Request-- a PKCS#10 Certificate
   Signing Request (CSR)-- when using Enrollment over Secure Transport
   (EST).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on December 23, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Harkins & Turner        Expires December 23, 2012               [Page 1]

Internet-Draft     The application/csrattrs Media Type         June 2012


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Distribution of Attributes  . . . . . . . . . . . . . . . . . . 3
   3.  Format of the application/csrattrs Body . . . . . . . . . . . . 4
   4.  Receipt of the application/csrattrs Body  . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8































Harkins & Turner        Expires December 23, 2012               [Page 2]

Internet-Draft     The application/csrattrs Media Type         June 2012


1.  Introduction

   Enrollment over Secure Transport [EST] defines a Certificate
   enrollment protocol that allows client to generate certification
   request and transmit it to a server acting as a Certification
   Authority (CA) or Registration Authority (RA).  The CA then issues a
   Certificate based on the certification request.

   In some cases, the CA may want to include client-provided attributes
   in certificates it issues.  These attributes may describe information
   that is not available to the CA, for instance the MAC address of a
   client's wireless interface might be needed in a certificate used to
   gain access to a wireless medium.  The media type described here
   allows the server to inform the client of a (set of) attribute(s) to
   include, if possible, in its certification request.

   This document defines a URI [RFC3986] that can be used with
   Enrollment over Secure Transport (EST) protocol [EST].

1.1.  Requirements Language

   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 [RFC2119].

1.2.  Terminology

   The reader is assumed to be familiar with the terms and concepts of
   [EST] and [RFC2986].

   Attribute
       Any kind of identifying information that can be added to a
       certification request.


2.  Distribution of Attributes

   Attribute request messages MUST be sent through the TLS-protected
   channel [RFC5246] established as part of the [EST] protocol.

   The request MUST be made with an HTTPS GET message to the common path
   to the EST server-- referred to as BASEPATH-- with an OPERATIONPATH
   extension of '/csrattrs'.  For example, if BASEPATH had the value
   arbitary/base then an example URI would be:

       https://example.org/arbitrary/base/csrattrs

   The server MUST reply to the client's HTTPS message with a (set of)



Harkins & Turner        Expires December 23, 2012               [Page 3]

Internet-Draft     The application/csrattrs Media Type         June 2012


   attribute(s).  Responses to attribute request messsages MUST be
   encoded as content type "application/csrattrs".


3.  Format of the application/csrattrs Body

   The syntax for application/csrattrs body is as follows:

       Csrattrs ::= SEQUENCE SIZE (0..MAX) OF OBJECT IDENTIFIER { }

   A robust application SHOULD output Distinguished Encoding Rules (DER)
   ([X.690]) but MAY use Basic Encoding Rules (BER) ([X.680]).  Data
   produced by DER or BER is 8-bit.  When the transport for the
   application/csrattrs is limited to 7-bit data, a suitable transfer
   encoding MUST be applied in MIME-compatible transports, the base64
   encoding (section 4 of [RFC4648]) SHOULD be used with application/
   csrattrs, although any 7-bit transfer encoding may work.

   Clients MUST encode csrattrs as an empty SEQUENCE OF.  That is, no
   object identifiers are included when the client creates an
   application/csrattrs media type.  For example, it would produce an
   ASN.1 SEQUENCE:

       30 00

   and then base64 encode that ASN.1 SEQUENCE OF nothing to produce:

       MA==

   The resulting request would look like this:


            Content-Type: application/csrattrs; name=attributes
            Content-Transfer-Encoding: base64
            Content-Disposition: attachment; filename=attributes

            MA==

   Servers include zero or more object identifiers that they wish the
   client to include in their certification request.  When the server
   encodes csrattrs as an empty SEQUENCE OF it means that the server has
   no attributes it wants in client certification requests.

   For example, if a CA wishes to have a certification request contain
   the MAC address [RFC2397] of a device and the pseudonym [X.520] and
   friendly name [RFC2925] of the holder of the private analog to the
   public key in the certification request, it takes the following
   object identifiers:



Harkins & Turner        Expires December 23, 2012               [Page 4]

Internet-Draft     The application/csrattrs Media Type         June 2012


   o   macAddress: 1.3.6.1.1.1.1.22

   o   pseudonym: 2.5.4.65

   o   friendlyName: 1.2.840.113549.1.9.20

   and encodes them into an ASN.1 SEQUENCE to produce:

       30 19 06 07 2b 06 01 01 01 01 16 06 03 55 04 41 06 09 2a 86 48 86
       f7 0d 01 09 14

   and then base64 encodes the resulting ASN.1 SEQUENCE to produce:

       MBkGBysGAQEBARYGA1UEQQYJKoZIhvcNAQkU

   The resulting response would look like this:


            Content-Type: application/csrattrs; name=attributes
            Content-Transfer-Encoding: base64
            Content-Disposition: attachment; filename=attributes

            MBkGBysGAQEBARYGA1UEQQYJKoZIhvcNAQkU


4.  Receipt of the application/csrattrs Body

   A server that obtains a non-empty SEQUENCE OF SHALL ignore the OBJECT
   IDENTIFIERS in the application/csrattrs media type.

   A client that obtains data using the application/csrattrs media type
   SHALL decode the body of the data, as necessary, and parse the result
   as an ASN.1 SEQUENCE of OBJECT IDENTIFIERS.  An unknown OBJECT
   IDENTIFIER MUST be ignored by the client and SHALL NOT be a reason to
   not produce a certification request.  A client SHOULD include every
   known OBJECT IDENTIFIER it receives in an application/csrattrs media
   type in its certification request with the appropriate value.


5.  IANA Considerations

   IANA SHALL update the Application Media Types registry with the
   following filled-in template from [RFC4288].








Harkins & Turner        Expires December 23, 2012               [Page 5]

Internet-Draft     The application/csrattrs Media Type         June 2012


   The media subtype for Attributes in a CertificationRequest is
   application/csrattrs.

     Type name: application

     Subtype name: csrattrs

     Required parameters: None

     Optional parameters: None

     Encoding considerations: binary;

     Security Considerations:

       Clients request a list of attributes that servers wish to be
       in certification requests. The request/response SHOULD be done
       in a TLS-protected tunnel.

     Interoperability considerations: None

     Published specification: This memo.

     Applications which use this media type:

       Enrollment over Secure Transport (EST)

     Additional information:

       Magic number(s): None
       File extension: None
       Macintosh File Type Code(s):

     Person & email address to contact for further information:

       Dan Harkins <dharkins@arubanetworks.com>

     Restrictions on usage: None

     Author: Dan Harkins <dharkins@arubanetworks.com>

     Intentded usage: COMMON

     Change controller: The IESG







Harkins & Turner        Expires December 23, 2012               [Page 6]

Internet-Draft     The application/csrattrs Media Type         June 2012


6.  Security Considerations

   There are no real inherent security issues with the content being
   conveyed but an adversary who is able to interpose herself into the
   conversation could exclude attributes that a server may want, include
   attributes that a server may not want, and render meaningless other
   attributes that a server may want.

   For this reason, this mime-type is used over a TLS-protected channel
   established as part of the [EST] protocol. certification request
   protocol whose Security Considerations would apply to the use of this
   mime-type.

   The Security Considerations of [RFC2986] and [EST] apply.


7.  References

7.1.  Normative References

   [EST]      Pritikin, M. and P. Yee, "Enrollment over Secure
              Transport", draft-ietf-ipsec-pkix-est-01.txt (a work in
              progress), March 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [X.680]    "ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002",
              Information technology - Abstract Syntax Notation One
              (ASN.1) Specification of basic notation..

   [X.690]    "ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002",
              Information technology - ASN.1 encoding rules:
               Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER).





Harkins & Turner        Expires December 23, 2012               [Page 7]

Internet-Draft     The application/csrattrs Media Type         June 2012


7.2.  Informative References

   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
              August 1998.

   [RFC2925]  White, K., "Definitions of Managed Objects for Remote
              Ping, Traceroute, and Lookup Operations", RFC 2925,
              September 2000.

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              November 2000.

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [X.520]    "ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005",
              Information technology - Open Systems Interconnection The
              Directory: Selected attribute types..


Authors' Addresses

   Dan Harkins (editor)
   Aruba Networks
   1322 Crossman Avenue
   Sunnyvale, CA  94089-1113
   United States of America

   Email: dharkins@arubanetworks.com


   Sean Turner (editor)
   IECA, Inc
   3057 Nutley Street, Suite 106
   Fairfax, VA  22031
   United States of America

   Email: turners@ieca.com












Harkins & Turner        Expires December 23, 2012               [Page 8]