Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 5911 VPN Consortium
Category: Informational J. Schaad
ISSN: 2070-1721 Soaring Hawk Consulting
June 2010
New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME
Abstract
The Cryptographic Message Syntax (CMS) format, and many associated
formats, are expressed using ASN.1. The current ASN.1 modules
conform to the 1988 version of ASN.1. This document updates those
ASN.1 modules to conform to the 2002 version of ASN.1. There are no
bits-on-the-wire changes to any of the formats; this is simply a
change to the syntax.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5911.
Copyright Notice
Copyright (c) 2010 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
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Design Notes . . . . . . . . . . . . . . . . . . . . . . . 4
2. ASN.1 Module AlgorithmInformation . . . . . . . . . . . . . . 4
3. ASN.1 Module for RFC 3370 . . . . . . . . . . . . . . . . . . 14
4. ASN.1 Module for RFC 3565 . . . . . . . . . . . . . . . . . . 20
5. ASN.1 Module for RFC 3851 . . . . . . . . . . . . . . . . . . 22
6. ASN.1 Module for RFC 3852 . . . . . . . . . . . . . . . . . . 24
7. ASN.1 Module for RFC 4108 . . . . . . . . . . . . . . . . . . 34
8. ASN.1 Module for RFC 4998 . . . . . . . . . . . . . . . . . . 40
9. ASN.1 Module for RFC 5035 . . . . . . . . . . . . . . . . . . 41
10. ASN.1 Module for RFC 5083 . . . . . . . . . . . . . . . . . . 47
11. ASN.1 Module for RFC 5084 . . . . . . . . . . . . . . . . . . 48
12. ASN.1 Module for RFC 5275 . . . . . . . . . . . . . . . . . . 50
13. Security Considerations . . . . . . . . . . . . . . . . . . . 57
14. Normative References . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction
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
protocols still use ASN.1 from the 1988 standard, which has been
deprecated. This is particularly true for the standards that relate
to PKIX, CMS, and S/MIME.
This document updates the following RFCs to use ASN.1 modules that
conform to the 2002 version of ASN.1 [ASN1-2002]. Note that not all
the modules are updated; some are included to simply make the set
complete.
o RFC 3370, CMS Algorithms [RFC3370]
o RFC 3565, Use of AES in CMS [RFC3565]
o RFC 3851, S/MIME Version 3.1 Message Specification [RFC3851]
o RFC 3852, CMS main [RFC3852]
o RFC 4108, Using CMS to Protect Firmware Packages [RFC4108]
o RFC 4998, Evidence Record Syntax (ERS) [RFC4998]
o RFC 5035, Enhanced Security Services (ESS) [RFC5035]
o RFC 5083, CMS Authenticated-Enveloped-Data Content Type [RFC5083]
o RFC 5084, Using AES-CCM and AES-GCM Authenticated Encryption in
CMS [RFC5084]
o RFC 5275, CMS Symmetric Key Management and Distribution [RFC5275]
Note that some of the modules in this document get some of their
definitions from places different than the modules in the original
RFCs. The idea is that these modules, when combined with the modules
in [RFC5912] can stand on their own and do not need to import
definitions from anywhere else. Also note that the ASN.1 modules in
this document have references in their text comments that need to be
looked up in original RFCs, and that some of those references may
have already been superseded by later RFCs.
The document also includes a module of common definitions called
"AlgorithmInformation". These definitions are used here and in
[RFC5912].
Note that some of the modules here import definitions from the common
definitions module, "PKIX-CommonTypes", in [RFC5912].
1.1. Design Notes
The modules in this document use the object model available in the
2002 ASN.1 documents to a great extent. Objects for each of the
different algorithm types are defined. Also, all of the places where
the 1988 ASN.1 syntax had ANY holes to allow for variable syntax now
use objects.
Much like the way that the PKIX and S/MIME working groups use the
prefix of id- for object identifiers, this document has also adopted
a set of two-, three-, and four-letter prefixes to allow for quick
identification of the type of an object based on its name. This
allows, for example, the same back half of the name to be used for
the different objects. Thus, "id-sha1" is the object identifier,
while "mda-sha1" is the message digest object for "sha1".
One or more object sets for the different types of algorithms are
defined. A single consistent name for each different algorithm type
is used. For example, an object set named PublicKeys contains the
public keys defined in that module. If no public keys are defined,
then the object set is not created. When importing these object sets
into an ASN.1 module, one needs to be able to distinguish between the
different object sets with the same name. This is done by using both
the module name (as specified in the IMPORT statement) and the object
set name. For example, in the module for RFC 5280:
PublicKeys FROM PKIXAlgs-2008 { 1 3 6 1 5 5 7 0 995 }
PublicKeys FROM PKIX1-PSS-OAEP-Algorithms { 1 3 6 1 5 5 7 33 }
PublicKeyAlgorithms PUBLIC-KEY ::= { PKIXAlgs-2008.PublicKeys, ...,
PKIX1-PSS-OAEP-Algorithms.PublicKeys }
2. ASN.1 Module AlgorithmInformation
This section contains a module that is imported by many other modules
in this document. Note that this module is also given in [RFC5912].
This module does not come from any existing RFC.
AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
EXPORTS ALL;
IMPORTS
KeyUsage
FROM PKIX1Implicit-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59)} ;
-- Suggested prefixes for algorithm objects are:
--
-- mda- Message Digest Algorithms
-- sa- Signature Algorithms
-- kta- Key Transport Algorithms (Asymmetric)
-- kaa- Key Agreement Algorithms (Asymmetric)
-- kwa- Key Wrap Algorithms (Symmetric)
-- kda- Key Derivation Algorithms
-- maca- Message Authentication Code Algorithms
-- pk- Public Key
-- cea- Content (symmetric) Encryption Algorithms
-- cap- S/MIME Capabilities
ParamOptions ::= ENUMERATED {
required, -- Parameters MUST be encoded in structure
preferredPresent, -- Parameters SHOULD be encoded in structure
preferredAbsent, -- Parameters SHOULD NOT be encoded in structure
absent, -- Parameters MUST NOT be encoded in structure
inheritable, -- Parameters are inherited if not present
optional, -- Parameters MAY be encoded in the structure
...
}
-- DIGEST-ALGORITHM
--
-- Describes the basic information for ASN.1 and a digest
-- algorithm.
--
-- &id - contains the OID identifying the digest algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
--
-- Additional information such as the length of the hash could have
-- been encoded. Without a clear understanding of what information
-- is needed by applications, such extraneous information was not
-- considered to be of sufficient importance.
--
-- Example:
-- mda-sha1 DIGEST-ALGORITHM ::= {
-- IDENTIFIER id-sha1
-- PARAMS TYPE NULL ARE preferredAbsent
-- }
DIGEST-ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence ]
}
-- SIGNATURE-ALGORITHM
--
-- Describes the basic properties of a signature algorithm
--
-- &id - contains the OID identifying the signature algorithm
-- &Value - contains a type definition for the value structure of
-- the signature; if absent, implies that no ASN.1
-- encoding is performed on the value
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &HashSet - The set of hash algorithms used with this
-- signature algorithm
-- &PublicKeySet - the set of public key algorithms for this
-- signature algorithm
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- Example:
-- sig-RSA-PSS SIGNATURE-ALGORITHM ::= {
-- IDENTIFIER id-RSASSA-PSS
-- PARAMS TYPE RSASSA-PSS-params ARE required
-- HASHES { mda-sha1 | mda-md5, ... }
-- PUBLIC-KEYS { pk-rsa | pk-rsa-pss }
-- }
SIGNATURE-ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Value OPTIONAL,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&HashSet DIGEST-ALGORITHM OPTIONAL,
&PublicKeySet PUBLIC-KEY OPTIONAL,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[VALUE &Value]
[PARAMS [TYPE &Params] ARE ¶mPresence ]
[HASHES &HashSet]
[PUBLIC-KEYS &PublicKeySet]
[SMIME-CAPS &smimeCaps]
}
-- PUBLIC-KEY
--
-- Describes the basic properties of a public key
--
-- &id - contains the OID identifying the public key
-- &KeyValue - contains the type for the key value
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &keyUsage - contains the set of bits that are legal for this
-- key type. Note that it does not make any statement
-- about how bits may be paired.
-- &PrivateKey - contains a type structure for encoding the private
-- key information.
--
-- Example:
-- pk-rsa-pss PUBLIC-KEY ::= {
-- IDENTIFIER id-RSASSA-PSS
-- KEY RSAPublicKey
-- PARAMS TYPE RSASSA-PSS-params ARE optional
-- CERT-KEY-USAGE { .... }
-- }
PUBLIC-KEY ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&KeyValue OPTIONAL,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&keyUsage KeyUsage OPTIONAL,
&PrivateKey OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[KEY &KeyValue]
[PARAMS [TYPE &Params] ARE ¶mPresence]
[CERT-KEY-USAGE &keyUsage]
[PRIVATE-KEY &PrivateKey]
}
-- KEY-TRANSPORT
--
-- Describes the basic properties of a key transport algorithm
--
-- &id - contains the OID identifying the key transport algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &PublicKeySet - specifies which public keys are used with
-- this algorithm
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- Example:
-- kta-rsaTransport KEY-TRANSPORT ::= {
-- IDENTIFIER &id
-- PARAMS TYPE NULL ARE required
-- PUBLIC-KEYS { pk-rsa | pk-rsa-pss }
-- }
KEY-TRANSPORT ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&PublicKeySet PUBLIC-KEY OPTIONAL,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence]
[PUBLIC-KEYS &PublicKeySet]
[SMIME-CAPS &smimeCaps]
}
-- KEY-AGREE
--
-- Describes the basic properties of a key agreement algorithm
--
-- &id - contains the OID identifying the key agreement algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &PublicKeySet - specifies which public keys are used with
-- this algorithm
-- &Ukm - type of user keying material used
-- &ukmPresence - specifies the requirements to define the UKM field
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- Example:
-- kaa-dh-static-ephemeral KEY-AGREE ::= {
-- IDENTIFIER id-alg-ESDH
-- PARAMS TYPE KeyWrapAlgorithm ARE required
-- PUBLIC-KEYS {
-- {IDENTIFIER dh-public-number KEY DHPublicKey
-- PARAMS TYPE DHDomainParameters ARE inheritable }
-- }
-- - - UKM should be present but is not separately ASN.1-encoded
-- UKM ARE preferredPresent
-- }
KEY-AGREE ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&PublicKeySet PUBLIC-KEY OPTIONAL,
&Ukm OPTIONAL,
&ukmPresence ParamOptions DEFAULT absent,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence]
[PUBLIC-KEYS &PublicKeySet]
[UKM [TYPE &Ukm] ARE &ukmPresence]
[SMIME-CAPS &smimeCaps]
}
-- KEY-WRAP
--
-- Describes the basic properties of a key wrap algorithm
--
-- &id - contains the OID identifying the key wrap algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- Example:
-- kwa-cms3DESwrap KEY-WRAP ::= {
-- IDENTIFIER id-alg-CMS3DESwrap
-- PARAMS TYPE NULL ARE required
-- }
KEY-WRAP ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence]
[SMIME-CAPS &smimeCaps]
}
-- KEY-DERIVATION
--
-- Describes the basic properties of a key derivation algorithm
--
-- &id - contains the OID identifying the key derivation algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- Example:
-- kda-pbkdf2 KEY-DERIVATION ::= {
-- IDENTIFIER id-PBKDF2
-- PARAMS TYPE PBKDF2-params ARE required
-- }
KEY-DERIVATION ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence]
[SMIME-CAPS &smimeCaps]
}
-- MAC-ALGORITHM
--
-- Describes the basic properties of a message
-- authentication code (MAC) algorithm
--
-- &id - contains the OID identifying the MAC algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &keyed - MAC algorithm is a keyed MAC algorithm
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- Some parameters that perhaps should have been added would be
-- fields with the minimum and maximum MAC lengths for
-- those MAC algorithms that allow truncations.
--
-- Example:
-- maca-hmac-sha1 MAC-ALGORITHM ::= {
-- IDENTIFIER hMAC-SHA1
-- PARAMS TYPE NULL ARE preferredAbsent
-- IS KEYED MAC TRUE
-- SMIME-CAPS {IDENTIFIED BY hMAC-SHA1}
-- }
MAC-ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&keyed BOOLEAN,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence]
IS-KEYED-MAC &keyed
[SMIME-CAPS &smimeCaps]
}
-- CONTENT-ENCRYPTION
--
-- Describes the basic properties of a content encryption
-- algorithm
--
-- &id - contains the OID identifying the content
-- encryption algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- Example:
-- cea-3DES-cbc CONTENT-ENCRYPTION ::= {
-- IDENTIFIER des-ede3-cbc
-- PARAMS TYPE IV ARE required
-- SMIME-CAPS { IDENTIFIED BY des-ede3-cbc }
-- }
CONTENT-ENCRYPTION ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence]
[SMIME-CAPS &smimeCaps]
}
-- ALGORITHM
--
-- Describes a generic algorithm identifier
--
-- &id - contains the OID identifying the algorithm
-- &Params - if present, contains the type for the algorithm
-- parameters; if absent, implies no parameters
-- ¶mPresence - parameter presence requirement
-- &smimeCaps - contains the object describing how the S/MIME
-- capabilities are presented.
--
-- This would be used for cases where an algorithm of an unknown
-- type is used. In general however, one should either define
-- a more complete algorithm structure (such as the one above)
-- or use the TYPE-IDENTIFIER class.
ALGORITHM ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Params OPTIONAL,
¶mPresence ParamOptions DEFAULT absent,
&smimeCaps SMIME-CAPS OPTIONAL
} WITH SYNTAX {
IDENTIFIER &id
[PARAMS [TYPE &Params] ARE ¶mPresence]
[SMIME-CAPS &smimeCaps]
}
-- AlgorithmIdentifier
--
-- Provides the generic structure that is used to encode algorithm
-- identification and the parameters associated with the
-- algorithm.
--
-- The first parameter represents the type of the algorithm being
-- used.
-- The second parameter represents an object set containing the
-- algorithms that may occur in this situation.
-- The initial list of required algorithms should occur to the
-- left of an extension marker; all other algorithms should
-- occur to the right of an extension marker.
--
-- The object class ALGORITHM can be used for generic unspecified
-- items.
-- If new ALGORITHM classes are defined, the fields &id and &Params
-- need to be present as fields in the object in order to use
-- this parameterized type.
--
-- Example:
-- SignatureAlgorithmIdentifier ::=
-- AlgorithmIdentifier{SIGNATURE-ALGORITHM, {SignatureAlgSet}}
AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::=
SEQUENCE {
algorithm ALGORITHM-TYPE.&id({AlgorithmSet}),
parameters ALGORITHM-TYPE.
&Params({AlgorithmSet}{@algorithm}) OPTIONAL
}
-- S/MIME Capabilities
--
-- We have moved the SMIME-CAPS from the module for RFC 3851 to here
-- because it is used in RFC 4262 (X.509 Certificate Extension for
-- S/MIME Capabilities)
--
--
-- This class is used to represent an S/MIME capability. S/MIME
-- capabilities are used to represent what algorithm capabilities
-- an individual has. The classic example was the content encryption
-- algorithm RC2 where the algorithm id and the RC2 key lengths
-- supported needed to be advertised, but the IV used is not fixed.
-- Thus, for RC2 we used
--
-- cap-RC2CBC SMIME-CAPS ::= {
-- TYPE INTEGER ( 40 | 128 ) IDENTIFIED BY rc2-cbc }
--
-- where 40 and 128 represent the RC2 key length in number of bits.
--
-- Another example where information needs to be shown is for
-- RSA-OAEP where only specific hash functions or mask generation
-- functions are supported, but the saltLength is specified by the
-- sender and not the recipient. In this case, one can either
-- generate a number of capability items,
-- or a new S/MIME capability type could be generated where
-- multiple hash functions could be specified.
--
--
-- SMIME-CAP
--
-- This class is used to associate the type that describes the
-- capabilities with the object identifier.
--
SMIME-CAPS ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Type OPTIONAL
}
WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id }
--
-- Generic type - this is used for defining values.
--
-- Define a single S/MIME capability encoding
SMIMECapability{SMIME-CAPS:CapabilitySet} ::= SEQUENCE {
capabilityID SMIME-CAPS.&id({CapabilitySet}),
parameters SMIME-CAPS.&Type({CapabilitySet}
{@capabilityID}) OPTIONAL
}
-- Define a sequence of S/MIME capability values
SMIMECapabilities { SMIME-CAPS:CapabilitySet } ::=
SEQUENCE SIZE (1..MAX) OF SMIMECapability{{CapabilitySet} }
END
3. ASN.1 Module for RFC 3370
CryptographicMessageSyntaxAlgorithms-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
ParamOptions, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM,
PUBLIC-KEY, KEY-DERIVATION, KEY-WRAP, MAC-ALGORITHM,
KEY-AGREE, KEY-TRANSPORT, CONTENT-ENCRYPTION, ALGORITHM,
AlgorithmIdentifier{}, SMIME-CAPS
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
pk-rsa, pk-dh, pk-dsa, rsaEncryption, DHPublicKey, dhpublicnumber
FROM PKIXAlgs-2009
{iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56)}
cap-RC2CBC
FROM SecureMimeMessageV3dot1-2009
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-msg-v3dot1-02(39)};
-- 2. Hash algorithms in this document
MessageDigestAlgs DIGEST-ALGORITHM ::= {
-- mda-md5 | mda-sha1,
... }
-- 3. Signature algorithms in this document
SignatureAlgs SIGNATURE-ALGORITHM ::= {
-- See RFC 3279
-- sa-dsaWithSHA1 | sa-rsaWithMD5 | sa-rsaWithSHA1,
... }
-- 4. Key Management Algorithms
-- 4.1 Key Agreement Algorithms
KeyAgreementAlgs KEY-AGREE ::= { kaa-esdh | kaa-ssdh, ...}
KeyAgreePublicKeys PUBLIC-KEY ::= { pk-dh, ...}
-- 4.2 Key Transport Algorithms
KeyTransportAlgs KEY-TRANSPORT ::= { kt-rsa, ... }
-- 4.3 Symmetric Key-Encryption Key Algorithms
KeyWrapAlgs KEY-WRAP ::= { kwa-3DESWrap | kwa-RC2Wrap, ... }
-- 4.4 Key Derivation Algorithms
KeyDerivationAlgs KEY-DERIVATION ::= { kda-PBKDF2, ... }
-- 5. Content Encryption Algorithms
ContentEncryptionAlgs CONTENT-ENCRYPTION ::=
{ cea-3DES-cbc | cea-RC2-cbc, ... }
-- 6. Message Authentication Code Algorithms
MessageAuthAlgs MAC-ALGORITHM ::= { maca-hMAC-SHA1, ... }
-- S/MIME Capabilities for these items
SMimeCaps SMIME-CAPS ::= {
kaa-esdh.&smimeCaps |
kaa-ssdh.&smimeCaps |
kt-rsa.&smimeCaps |
kwa-3DESWrap.&smimeCaps |
kwa-RC2Wrap.&smimeCaps |
cea-3DES-cbc.&smimeCaps |
cea-RC2-cbc.&smimeCaps |
maca-hMAC-SHA1.&smimeCaps,
...}
--
--
--
-- Algorithm Identifiers
-- rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
-- us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 }
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 }
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
des-ede3-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) encryptionAlgorithm(3) 7 }
rc2-cbc OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) encryptionAlgorithm(3) 2 }
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
id-PBKDF2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
-- Algorithm Identifier Parameter Types
KeyWrapAlgorithm ::=
AlgorithmIdentifier {KEY-WRAP, {KeyWrapAlgs }}
RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER
CBCParameter ::= IV
IV ::= OCTET STRING -- exactly 8 octets
RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER (1..256),
iv OCTET STRING } -- exactly 8 octets
maca-hMAC-SHA1 MAC-ALGORITHM ::= {
IDENTIFIER hMAC-SHA1
PARAMS TYPE NULL ARE preferredAbsent
IS-KEYED-MAC TRUE
SMIME-CAPS {IDENTIFIED BY hMAC-SHA1}
}
PBKDF2-PRFsAlgorithmIdentifier ::= AlgorithmIdentifier{ ALGORITHM,
{PBKDF2-PRFs} }
alg-hMAC-SHA1 ALGORITHM ::=
{ IDENTIFIER hMAC-SHA1 PARAMS TYPE NULL ARE required }
PBKDF2-PRFs ALGORITHM ::= { alg-hMAC-SHA1, ... }
PBKDF2-SaltSources ALGORITHM ::= { ... }
PBKDF2-SaltSourcesAlgorithmIdentifier ::=
AlgorithmIdentifier {ALGORITHM, {PBKDF2-SaltSources}}
defaultPBKDF2 PBKDF2-PRFsAlgorithmIdentifier ::=
{ algorithm alg-hMAC-SHA1.&id, parameters NULL:NULL }
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING,
otherSource PBKDF2-SaltSourcesAlgorithmIdentifier },
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL,
prf PBKDF2-PRFsAlgorithmIdentifier DEFAULT
defaultPBKDF2
}
--
-- This object is included for completeness. It should not be used
-- for encoding of signatures, but was sometimes used in older
-- versions of CMS for encoding of RSA signatures.
--
--
-- sa-rsa SIGNATURE-ALGORITHM ::= {
-- IDENTIFIER rsaEncryption
-- - - value is not ASN.1 encoded
-- PARAMS TYPE NULL ARE required
-- HASHES {mda-sha1 | mda-md5, ...}
-- PUBLIC-KEYS { pk-rsa}
-- }
--
-- No ASN.1 encoding is applied to the signature value
-- for these items
kaa-esdh KEY-AGREE ::= {
IDENTIFIER id-alg-ESDH
PARAMS TYPE KeyWrapAlgorithm ARE required
PUBLIC-KEYS { pk-dh }
-- UKM is not ASN.1 encoded
UKM ARE optional
SMIME-CAPS {TYPE KeyWrapAlgorithm IDENTIFIED BY id-alg-ESDH}
}
kaa-ssdh KEY-AGREE ::= {
IDENTIFIER id-alg-SSDH
PARAMS TYPE KeyWrapAlgorithm ARE required
PUBLIC-KEYS {pk-dh}
-- UKM is not ASN.1 encoded
UKM ARE optional
SMIME-CAPS {TYPE KeyWrapAlgorithm IDENTIFIED BY id-alg-SSDH}
}
dh-public-number OBJECT IDENTIFIER ::= dhpublicnumber
pk-originator-dh PUBLIC-KEY ::= {
IDENTIFIER dh-public-number
KEY DHPublicKey
PARAMS ARE absent
CERT-KEY-USAGE {keyAgreement, encipherOnly, decipherOnly}
}
kwa-3DESWrap KEY-WRAP ::= {
IDENTIFIER id-alg-CMS3DESwrap
PARAMS TYPE NULL ARE required
SMIME-CAPS {IDENTIFIED BY id-alg-CMS3DESwrap}
}
kwa-RC2Wrap KEY-WRAP ::= {
IDENTIFIER id-alg-CMSRC2wrap
PARAMS TYPE RC2wrapParameter ARE required
SMIME-CAPS { IDENTIFIED BY id-alg-CMSRC2wrap }
}
kda-PBKDF2 KEY-DERIVATION ::= {
IDENTIFIER id-PBKDF2
PARAMS TYPE PBKDF2-params ARE required
-- No S/MIME caps defined
}
cea-3DES-cbc CONTENT-ENCRYPTION ::= {
IDENTIFIER des-ede3-cbc
PARAMS TYPE IV ARE required
SMIME-CAPS { IDENTIFIED BY des-ede3-cbc }
}
cea-RC2-cbc CONTENT-ENCRYPTION ::= {
IDENTIFIER rc2-cbc
PARAMS TYPE RC2CBCParameter ARE required
SMIME-CAPS cap-RC2CBC
}
kt-rsa KEY-TRANSPORT ::= {
IDENTIFIER rsaEncryption
PARAMS TYPE NULL ARE required
PUBLIC-KEYS { pk-rsa }
SMIME-CAPS {IDENTIFIED BY rsaEncryption}
}
-- S/MIME Capabilities - most have no label.
cap-3DESwrap SMIME-CAPS ::= { IDENTIFIED BY id-alg-CMS3DESwrap }
END
4. ASN.1 Module for RFC 3565
CMSAesRsaesOaep-2009 {iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes-02(38)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
CONTENT-ENCRYPTION, KEY-WRAP, SMIME-CAPS
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)};
AES-ContentEncryption CONTENT-ENCRYPTION ::= {
cea-aes128-cbc | cea-aes192-cbc | cea-aes256-cbc, ...
}
AES-KeyWrap KEY-WRAP ::= {
kwa-aes128-wrap | kwa-aes192-wrap | kwa-aes256-wrap, ...
}
SMimeCaps SMIME-CAPS ::= {
cea-aes128-cbc.&smimeCaps |
cea-aes192-cbc.&smimeCaps |
cea-aes256-cbc.&smimeCaps |
kwa-aes128-wrap.&smimeCaps |
kwa-aes192-wrap.&smimeCaps |
kwa-aes256-wrap.&smimeCaps, ...
}
-- AES information object identifiers --
aes OBJECT IDENTIFIER ::=
{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
csor(3) nistAlgorithms(4) 1 }
-- AES using CBC mode for key sizes of 128, 192, 256
cea-aes128-cbc CONTENT-ENCRYPTION ::= {
IDENTIFIER id-aes128-CBC
PARAMS TYPE AES-IV ARE required
SMIME-CAPS { IDENTIFIED BY id-aes128-CBC }
}
id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
cea-aes192-cbc CONTENT-ENCRYPTION ::= {
IDENTIFIER id-aes192-CBC
PARAMS TYPE AES-IV ARE required
SMIME-CAPS { IDENTIFIED BY id-aes192-CBC }
}
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
cea-aes256-cbc CONTENT-ENCRYPTION ::= {
IDENTIFIER id-aes256-CBC
PARAMS TYPE AES-IV ARE required
SMIME-CAPS { IDENTIFIED BY id-aes256-CBC }
}
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }
-- AES-IV is the parameter for all the above object identifiers.
AES-IV ::= OCTET STRING (SIZE(16))
-- AES Key Wrap Algorithm Identifiers - Parameter is absent
kwa-aes128-wrap KEY-WRAP ::= {
IDENTIFIER id-aes128-wrap
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes128-wrap }
}
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
kwa-aes192-wrap KEY-WRAP ::= {
IDENTIFIER id-aes192-wrap
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes192-wrap }
}
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
kwa-aes256-wrap KEY-WRAP ::= {
IDENTIFIER id-aes256-wrap
PARAMS ARE absent
SMIME-CAPS { IDENTIFIED BY id-aes256-wrap }
}
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
END
5. ASN.1 Module for RFC 3851
SecureMimeMessageV3dot1-2009
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-msg-v3dot1-02(39)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
SMIME-CAPS, SMIMECapabilities{}
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
ATTRIBUTE
FROM PKIX-CommonTypes-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}
SubjectKeyIdentifier, IssuerAndSerialNumber, RecipientKeyIdentifier
FROM CryptographicMessageSyntax-2009
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cms-2004-02(41)}
rc2-cbc, SMimeCaps
FROM CryptographicMessageSyntaxAlgorithms-2009
{iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cmsalg-2001-02(37)}
SMimeCaps
FROM PKIXAlgs-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56)}
SMimeCaps
FROM PKIX1-PSS-OAEP-Algorithms-2009
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs-02(54)};
SMimeAttributeSet ATTRIBUTE ::=
{ aa-smimeCapabilities | aa-encrypKeyPref, ... }
-- id-aa is the arc with all new authenticated and unauthenticated
-- attributes produced by the S/MIME Working Group
id-aa OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) usa(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) attributes(2)}
-- The S/MIME Capabilities attribute provides a method of broadcasting
-- the symmetric capabilities understood. Algorithms SHOULD be ordered
-- by preference and grouped by type
aa-smimeCapabilities ATTRIBUTE ::=
{ TYPE SMIMECapabilities{{SMimeCapsSet}} IDENTIFIED BY
smimeCapabilities }
smimeCapabilities OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
15 }
SMimeCapsSet SMIME-CAPS ::=
{ cap-preferBinaryInside | cap-RC2CBC |
PKIXAlgs-2009.SMimeCaps |
CryptographicMessageSyntaxAlgorithms-2009.SMimeCaps |
PKIX1-PSS-OAEP-Algorithms-2009.SMimeCaps, ... }
-- Encryption Key Preference provides a method of broadcasting the
-- preferred encryption certificate.
aa-encrypKeyPref ATTRIBUTE ::=
{ TYPE SMIMEEncryptionKeyPreference
IDENTIFIED BY id-aa-encrypKeyPref }
id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
SMIMEEncryptionKeyPreference ::= CHOICE {
issuerAndSerialNumber [0] IssuerAndSerialNumber,
receipentKeyId [1] RecipientKeyIdentifier,
subjectAltKeyIdentifier [2] SubjectKeyIdentifier
}
-- receipentKeyId is spelt incorrectly, but kept for historical
-- reasons.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-cap OBJECT IDENTIFIER ::= { id-smime 11 }
-- The preferBinaryInside indicates an ability to receive messages
-- with binary encoding inside the CMS wrapper
cap-preferBinaryInside SMIME-CAPS ::=
{ -- No value -- IDENTIFIED BY id-cap-preferBinaryInside }
id-cap-preferBinaryInside OBJECT IDENTIFIER ::= { id-cap 1 }
-- The following list OIDs to be used with S/MIME V3
-- Signature Algorithms Not Found in [RFC3370]
--
-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
-- 2}
--
-- Other Signed Attributes
--
-- signingTime OBJECT IDENTIFIER ::=
-- {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
-- 5}
-- See [RFC5652] for a description of how to encode the attribute
-- value.
cap-RC2CBC SMIME-CAPS ::=
{ TYPE SMIMECapabilitiesParametersForRC2CBC
IDENTIFIED BY rc2-cbc}
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER (40 | 128, ...)
-- (RC2 Key Length (number of bits))
END
6. ASN.1 Module for RFC 3852
EID 2665 (Verified) is as follows:Section: Section 6
Original Text:
FROM AttributeCertificateVersion1-2009
{ iso(1) member-body(2) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;
Corrected Text:
FROM AttributeCertificateVersion1-2009
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;
Notes:
One incorrect node in the arc was noted from the last errata.
This module has an ASN.1 idiom for noting in which version of CMS
changes were made from the original PKCS #7; that idiom is "[[v:",
where "v" is an integer. For example:
RevocationInfoChoice ::= CHOICE {
crl CertificateList,
...,
[[5: other [1] IMPLICIT OtherRevocationInfoFormat ]] }
Similarly, this module adds the ASN.1 idiom for extensibility (the
"...,") in all places that have been extended in the past. See the
example above.
CryptographicMessageSyntax-2009
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
ParamOptions, DIGEST-ALGORITHM, SIGNATURE-ALGORITHM,
PUBLIC-KEY, KEY-DERIVATION, KEY-WRAP, MAC-ALGORITHM,
KEY-AGREE, KEY-TRANSPORT, CONTENT-ENCRYPTION, ALGORITHM,
AlgorithmIdentifier
FROM AlgorithmInformation-2009
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
SignatureAlgs, MessageDigestAlgs, KeyAgreementAlgs,
MessageAuthAlgs, KeyWrapAlgs, ContentEncryptionAlgs,
KeyTransportAlgs, KeyDerivationAlgs, KeyAgreePublicKeys
FROM CryptographicMessageSyntaxAlgorithms-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-cmsalg-2001-02(37) }
Certificate, CertificateList, CertificateSerialNumber,
Name, ATTRIBUTE
FROM PKIX1Explicit-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) }
AttributeCertificate
FROM PKIXAttributeCertificate-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-attribute-cert-02(47) }
AttributeCertificateV1
FROM AttributeCertificateVersion1-2009
{ iso(1) member-body(2) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;
EID 2648 (Verified) is as follows:Section: Section 6
Original Text:
FROM AttributeCertificateVersion1-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-v1AttrCert-02(49) } ;
Corrected Text:
FROM AttributeCertificateVersion1-2009
{ iso(1) member-body(2) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;
Notes:
The wrong oid arc was used for the module identification. A similar changes is also being reported for RFC 5912
EID 2612 (Verified) is as follows:Section: 6 and others
Original Text:
ct-Data CONTENT-TYPE ::= {OCTET STRING IDENTIFIED BY id-data}
Corrected Text:
ct-Data CONTENT-TYPE ::= {IDENTIFIED BY id-data}
Notes:
Due to a confusion in the part of the author's head that resulted from the difference the way that encapsulated content types are encoded between PKCS#7 and CMS, I put the type of OCTET STRING in this location. Since the OCTET STRING is explicitly included by the the encapulsated content type now, there should be an absence of a data type for the content type of id-data. Making this change however requires that some additional changes be made. It is not possible to just omit the type for a TYPE-IDENTIFIER type so a new class definition is required for CONTENT-TYPE. Unfortionately it is also not possible to simply omit the type from the syntax provided for the new content type as the parser is defined as being opertunistic rather than pessimistic by the ASN.1 syntax. Thus the tag IDENTIFIER would be consumed as a type and the rest of the parsing would fail. We there need to make the following changes:
1. Define a new object class of CONTENT-TYPE as CONTENT-TYPE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL } WITH SYNTAX { [TYPE &Type] IDENTIFIED BY &id }
2. We make the change to the defintion of ct-Data as above so that it no longer has an implied ASN.1 type associated with the object identifier
3. We then change all locations where a new content type is defined as follows: ct-Foo CONTENT-TYPE ::= {Foo IDENTIFIED BY id-Foo} becomes ct-Foo CONTENT-TYPE ::= {TYPE Foo IDENTIFIED BY id-Foo}
Changes 1 and 2 will occur in the module for RFC 3851 (now RFC 5281) Change 3 will occur in a number of different modules including modules that have been published independently since this document was released.