< draft-turner-additional-new-asn-02.txt   draft-turner-additional-new-asn-03.txt >
Network Working Group J. Schaad Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting Internet-Draft Soaring Hawk Consulting
Intended status: Standards Track S. Turner Intended status: Standards Track S. Turner
Expires: May 12, 2011 IECA, Inc. Expires: May 13, 2011 IECA, Inc.
November 8, 2010 November 9, 2010
Additional New ASN.1 Modules Additional New ASN.1 Modules
draft-turner-additional-new-asn-02 draft-turner-additional-new-asn-03
Abstract Abstract
The Cryptographic Message Syntax (CMS) format, and many associated The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1. The current ASN.1 modules formats, are expressed using ASN.1. The current ASN.1 modules
conform to the 1988 version of ASN.1. This document updates some conform to the 1988 version of ASN.1. This document updates some
auxiliary ASN.1 modules to conform to the 2008 version of ASN.1. auxiliary ASN.1 modules to conform to the 2008 version of ASN.1.
There are no bits-on-the-wire changes to any of the formats; this is There are no bits-on-the-wire changes to any of the formats; this is
simply a change to the syntax. simply a change to the syntax.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 12, 2011. This Internet-Draft will expire on May 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. ASN.1 Updates (2002 to 2008) . . . . . . . . . . . . . . . 3 1.1. ASN.1 Updates (2002 to 2008) . . . . . . . . . . . . . . . 3
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4 1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4
2. ASN.1 Module RFC 3274 . . . . . . . . . . . . . . . . . . . . 5 2. ASN.1 Module RFC 3274 . . . . . . . . . . . . . . . . . . . . 5
3. ASN.1 Module RFC 3779 . . . . . . . . . . . . . . . . . . . . 8 3. ASN.1 Module RFC 3779 . . . . . . . . . . . . . . . . . . . . 8
4. ASN.1 Module RFC 4049 . . . . . . . . . . . . . . . . . . . . 11 4. ASN.1 Module RFC 6019 . . . . . . . . . . . . . . . . . . . . 11
5. ASN.1 Module RFC 4073 . . . . . . . . . . . . . . . . . . . . 13 5. ASN.1 Module RFC 4073 . . . . . . . . . . . . . . . . . . . . 13
6. ASN.1 Module RFC 4231 . . . . . . . . . . . . . . . . . . . . 15 6. ASN.1 Module RFC 4231 . . . . . . . . . . . . . . . . . . . . 15
7. ASN.1 Module RFC 4334 . . . . . . . . . . . . . . . . . . . . 18 7. ASN.1 Module RFC 4334 . . . . . . . . . . . . . . . . . . . . 18
8. ASN.1 Module RFC 5083 . . . . . . . . . . . . . . . . . . . . 20 8. ASN.1 Module RFC 5083 . . . . . . . . . . . . . . . . . . . . 20
9. ASN.1 Module RFC 5652 . . . . . . . . . . . . . . . . . . . . 22 9. ASN.1 Module RFC 5652 . . . . . . . . . . . . . . . . . . . . 22
10. ASN.1 Module RFC 5752 . . . . . . . . . . . . . . . . . . . . 33 10. ASN.1 Module RFC 5752 . . . . . . . . . . . . . . . . . . . . 33
11. Module Identifiers in ASN.1 . . . . . . . . . . . . . . . . . 35 11. Module Identifiers in ASN.1 . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 37 12. Security Considerations . . . . . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
14. Normative References . . . . . . . . . . . . . . . . . . . . . 39 14. Normative References . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Some developers would like the IETF to use the latest version of Some developers would like the IETF to use the latest version of
ASN.1 in its standards. Most of the RFCs that relate to security ASN.1 in its standards. Most of the RFCs that relate to security
protocols still use ASN.1 from the 1988 standard, which has been protocols still use ASN.1 from the 1988 standard, which has been
deprecated. This is particularly true for the standards that relate deprecated. This is particularly true for the standards that relate
to PKIX, CMS, and S/MIME. to PKIX, CMS, and S/MIME.
In this document we have either change the syntax to use the 2008 In this document we have either changed the syntax to use the 2008
ASN.1 standard, or done some updates from previous conversions: ASN.1 standard, or done some updates from previous conversions:
RFC 3274, Compressed Data Content Type for Cryptographic Message RFC 3274, Compressed Data Content Type for Cryptographic Message
Syntax (CMS) [RFC3274]. Syntax (CMS) [RFC3274].
RFC 3779, X.509 Extensions for IP Addresses and AS Identifiers RFC 3779, X.509 Extensions for IP Addresses and AS Identifiers
[RFC3779]. [RFC3779].
RFC 4049, BinaryTime: An Alternate Format for Representing Date RFC 6019, BinaryTime: An Alternate Format for Representing Date
and Time in ASN.1 [RFC4049]. and Time in ASN.1 [RFC6019].
RFC 4073, Protecting Multiple Contents with the Cryptographic RFC 4073, Protecting Multiple Contents with the Cryptographic
Message Syntax (CMS) [RFC4073]. Message Syntax (CMS) [RFC4073].
RFC 4231, Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA- RFC 4231, Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-
256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4231]. 256, HMAC-SHA-384, and HMAC-SHA-512 [RFC4231].
RFC 4334, Certificate Extensions and Attributes Supporting RFC 4334, Certificate Extensions and Attributes Supporting
Authentication in Point-to-Point Protocol (PPP) and Wireless Local Authentication in Point-to-Point Protocol (PPP) and Wireless Local
Area Networks (WLAN) [RFC4334]. Area Networks (WLAN) [RFC4334].
skipping to change at page 11, line 5 skipping to change at page 11, line 5
range ASRange } range ASRange }
ASRange ::= SEQUENCE { ASRange ::= SEQUENCE {
min ASId, min ASId,
max ASId } max ASId }
ASId ::= INTEGER ASId ::= INTEGER
END END
4. ASN.1 Module RFC 4049 4. ASN.1 Module RFC 6019
We have updated the ASN.1 module associated with this document to be We have updated the ASN.1 module associated with this document to be
2008 compliant and to use the set of classes previously defined in 2008 compliant and to use the set of classes previously defined in
[RFC5911]. [RFC5911].
BinarySigningTimeModule-2009 BinarySigningTimeModule-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) TBD6 } pkcs-9(9) smime(16) modules(0) TBD6 }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
skipping to change at page 15, line 11 skipping to change at page 15, line 11
ContentAttributeSet ATTRIBUTE ::= { ... } ContentAttributeSet ATTRIBUTE ::= { ... }
END END
6. ASN.1 Module RFC 4231 6. ASN.1 Module RFC 4231
RFC 4231 does not contain an ASN.1 module to be updated. We have RFC 4231 does not contain an ASN.1 module to be updated. We have
therefore created an ASN.1 module to represent the ASN.1 that is therefore created an ASN.1 module to represent the ASN.1 that is
present in the document. Note that the parameters are defined as present in the document. Note that the parameters are defined as
expecting a parameter for the algorithm identifiers in this module, expecting a parameter for the algorithm identifiers in this module,
this is different from most of the algorithms used in PKIX and this is different from most of the algorithms used in PKIX and
S/MIME. There is no concept of being able to truncate the MAC value S/MIME. There is no concept of being able to truncate the MAC
in the ASN.1 unlike the XML definitions. This is reflected by not (Message Authentication Code) value in the ASN.1 unlike the XML
having a minimum MAC length defined in the ASN.1. definitions. This is reflected by not having a minimum MAC length
defined in the ASN.1.
HMAC -- { TBD } -- HMAC -- { TBD } --
DEFINITIONS EXPLICIT TAGS ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
EXPORTS ALL; EXPORTS ALL;
IMPORTS IMPORTS
MAC-ALGORITHM, SMIME-CAPS MAC-ALGORITHM, SMIME-CAPS
FROM AlgorithmInformation-2009 FROM AlgorithmInformation-2009
skipping to change at page 20, line 21 skipping to change at page 20, line 21
used in EnvelopedData, EncryptedData and used in EnvelopedData, EncryptedData and
AuthenticatedEnvelopedData (RFC 5083). AuthenticatedEnvelopedData (RFC 5083).
2. Define a parameterized type EncryptedContentInfoType so that the 2. Define a parameterized type EncryptedContentInfoType so that the
basic type can be used with different algorithm sets (used for basic type can be used with different algorithm sets (used for
EnvelopedData, EncryptedData and AuthenticatedEnvelopedData (RFC EnvelopedData, EncryptedData and AuthenticatedEnvelopedData (RFC
5083)). The parameterized type is assigned to an unparameterized 5083)). The parameterized type is assigned to an unparameterized
type of EncryptedContentInfo to minimize the output changes from type of EncryptedContentInfo to minimize the output changes from
previous versions. previous versions.
The use of different attribute sets for EncryptedData and Protocol designers can make use of the '08 ASN.1 contraints to define
EnvelopedData as well as for AuthenticatedData and AuthEnvelopedData, different sets of attributes for EncryptedData and EnvelopedData and
protocol designers can make use of the '08 ASN.1 constraints to for AuthenticatedData and AuthEnvelopedData. Previously, attributes
define different sets of attributes for EncryptedData and could only be constrained based on whether they were in the clear or
EnvelopedData and for AuthenticatedData and AuthEnvelopedData. unauthenticated not on the encapsulating content type.
Previously, attributes could only be constrained based on whether
they were in the clear or unauthenticated not on the encapsulating
content type.
CMS-AuthEnvelopedData-2009 CMS-AuthEnvelopedData-2009
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) TBD2} smime(16) modules(0) TBD2}
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
CMSVersion, EncryptedContentInfoType{}, CMSVersion, EncryptedContentInfoType{},
MessageAuthenticationCode, OriginatorInfo, RecipientInfos, MessageAuthenticationCode, OriginatorInfo, RecipientInfos,
skipping to change at page 22, line 21 skipping to change at page 22, line 21
used in EnvelopedData, EncryptedData and used in EnvelopedData, EncryptedData and
AuthenticatedEnvelopedData (RFC 5083). AuthenticatedEnvelopedData (RFC 5083).
2. Define a parameterized type EncryptedContentInfoType so that the 2. Define a parameterized type EncryptedContentInfoType so that the
basic type can be used with algorithm sets (used for basic type can be used with algorithm sets (used for
EnvelopedData, EncryptedData and AuthenticatedEnvelopedData (RFC EnvelopedData, EncryptedData and AuthenticatedEnvelopedData (RFC
5083)). The parameterized type is assigned to an unparameterized 5083)). The parameterized type is assigned to an unparameterized
type of EncryptedContentInfo to minimize the output changes from type of EncryptedContentInfo to minimize the output changes from
previous versions. previous versions.
The use of different attribute sets for EncryptedData and We are anticipating the definition of attributes that are going to be
EnvelopedData as well as for AuthenticatedData and AuthEnvelopedData, resticted to the use of only EnvelopedData. We are therefore
protocol designers can make use of the '08 ASN.1 constraints to separating the different attribute sets so that protocol designers
define different sets of attributes for EncryptedData and that need to do this will be able to define attributes that are used
EnvelopedData and for AuthenticatedData and AuthEnvelopedData. for EnvelopedData but not for EncryptedData. The same separation is
Previously, attributes could only be constrained based on whether also being applied to AuthenticatedData and AuthEnvelopedData.
they were in the clear or unauthenticated not on the encapsulating
content type.
CryptographicMessageSyntax-2009 CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) TBD1 } pkcs(1) pkcs-9(9) smime(16) modules(0) TBD1 }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
ParamOptions, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM, ParamOptions, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM,
PUBLIC-KEY, KEY-DERIVATION, KEY-WRAP, MAC-ALGORITHM, PUBLIC-KEY, KEY-DERIVATION, KEY-WRAP, MAC-ALGORITHM,
skipping to change at page 35, line 31 skipping to change at page 35, line 31
need to match the module it is importing from). need to match the module it is importing from).
One can create a module that contains only the module number One can create a module that contains only the module number
assignments and import the module assignments from the new module. assignments and import the module assignments from the new module.
This means that when a module is replaced, one can replace the This means that when a module is replaced, one can replace the
previous module, update the module number assignment module and previous module, update the module number assignment module and
recompile without having to modify any other modules. recompile without having to modify any other modules.
A sample module assignment module would be: A sample module assignment module would be:
ModuleNumbersxs ModuleNumbers
DEFINITIONS TAGS ::= DEFINITIONS TAGS ::=
BEGIN BEGIN
id-mod-CMS ::= { iso(1) member-body(2) us(840) rsadsi(113549) id-mod-CMS ::= { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) TBD } pkcs(1) pkcs-9(9) smime(16) modules(0) TBD }
id-mod-AlgInfo ::= id-mod-AlgInfo ::=
{iso(1) identified-organization(3) dod(6) internet(1) {iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)} id-mod-algorithmInformation-02(58)}
END END
skipping to change at page 39, line 16 skipping to change at page 39, line 16
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3274] Gutmann, P., "Compressed Data Content Type for [RFC3274] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4049] Housley, R., "BinaryTime: An Alternate Format for [RFC6019] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 4049, Representing Date and Time in ASN.1", RFC 6019,
April 2005. September 2010.
[RFC4073] Housley, R., "Protecting Multiple Contents with the [RFC4073] Housley, R., "Protecting Multiple Contents with the
Cryptographic Message Syntax (CMS)", RFC 4073, May 2005. Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA- [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", 224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512",
RFC 4231, December 2005. RFC 4231, December 2005.
[RFC4334] Housley, R. and T. Moore, "Certificate Extensions and [RFC4334] Housley, R. and T. Moore, "Certificate Extensions and
Attributes Supporting Authentication in Point-to-Point Attributes Supporting Authentication in Point-to-Point
 End of changes. 12 change blocks. 
32 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/