NAT64 Deployment Guidelines in Operator and Enterprise Networks
draft-palet-v6ops-nat64-deployment-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Jordi Palet Martinez | ||
| Last updated | 2018-03-05 | ||
| Replaced by | draft-ietf-v6ops-nat64-deployment, draft-ietf-v6ops-nat64-deployment, RFC 8683 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-palet-v6ops-nat64-deployment-00
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 7193 IECA
Category: Informational R. Housley
ISSN: 2070-1721 Vigil Security
J. Schaad
Soaring Hawk Consulting
April 2014
The application/cms Media Type
Abstract
This document registers the application/cms media type for use with
the corresponding CMS (Cryptographic Message Syntax) content types.
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/rfc7193.
Copyright Notice
Copyright (c) 2014 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.
Turner, et al. Informational [Page 1]
RFC 7193 application/cms Media Type April 2014
1. Introduction
[RFC5751] registered the application/pkc7-mime media type. That
document defined five optional smime-type parameters. The smime-type
parameter originally conveyed details about the security applied to
the data content type, indicating whether it was signed or enveloped,
as well as the name of the data content; it was later expanded to
indicate whether the data content is compressed and whether the data
content contained a certs-only message. This document does not
affect those registrations as this document places no requirements on
S/MIME (Secure Multipurpose Internet Mail Extensions) agents.
The registration done by the S/MIME documents was done assuming that
there would be a MIME (Multipurpose Internet Mail Extensions)
wrapping layer around each of the different enveloping contents;
thus, there was no need to include more than one item in each smime-
type. This is no longer the case with some of the more advanced
enveloping types. Some protocols such as the CMC (Certificate
Management over Cryptographic Message Syntax) [RFC5273] have defined
additional S/MIME types. New protocols that intend to wrap MIME
content should continue to define a smime-type string; however, new
protocols that intend to wrap non-MIME types should use this
mechanism instead.
CMS (Cryptographic Message Syntax) [RFC5652] associates a content
type identifier (OID) with specific content; CMS content types have
been widely used to define contents that can be enveloped using other
CMS content types and to define enveloping content types some of
which provide security services. CMS protecting content types, those
that provide security services, include: Signed-Data [RFC5652],
Enveloped-Data [RFC5652], Digested-Data [RFC5652], Encrypted-Data
[RFC5652], Authenticated-Data [RFC5652], Authenticated-Enveloped-Data
[RFC5083], and Encrypted Key Package [RFC6032]. CMS non-protecting
content types, those that provide no security services but
encapsulate other CMS content types, include: Content Information
[RFC5652], Compressed Data [RFC3274], Content Collection [RFC4073],
and Content With Attributes [RFC4073]. Then, there are the innermost
content types that include: Data [RFC5652], Asymmetric Key Package
[RFC5958], Symmetric Key Package [RFC6031], Firmware Package
[RFC4108], Firmware Package Load Receipt [RFC4108], Firmware Package
Load Error [RFC4108], Trust Anchor List [RFC5914], TAMP Status Query,
TAMP Status Response, TAMP Update, TAMP Update Confirm, TAMP Apex
Update, TAMP Apex Update Confirmation, TAMP Community Update, TAMP
Community Update Confirm, TAMP Sequence Adjust, TAMP Sequence Adjust
Confirmation, TAMP Error [RFC5934], Key Package Error, and Key
Package Receipt [RFC7191].
Turner, et al. Informational [Page 2]
RFC 7193 application/cms Media Type April 2014
To support conveying CMS content types, this document defines a media
type and parameters that indicate the enveloping and embedded CMS
content types.
New CMS content types should be affirmative in defining the string
that identifies the new content type and should additionally define
if the new content type is expected to appear in the
encapsulatedContent or innerContent parameter.
1.1. Requirements 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 [RFC2119].
2. CMS Media Type Registration Applications
This section provides the media type registration application for the
application/cms media type (see [RFC6838], Section 5.6).
Type name: application
Subtype name: cms
Required parameters: None.
Optional parameters:
encapsulatingContent=y; where y is one or more CMS ECT
(Encapsulating Content Type) identifiers; multiple values are
encapsulated in quotes and separated by a folding-whitespace, a
comma, and folding-whitespace. ECT values are based on content
types found in [RFC3274], [RFC4073], [RFC5083], [RFC5652], and
[RFC6032]. This list can later be extended; see Section 4.
authData
compressedData
contentCollection
contentInfo
contentWithAttrs
authEnvelopedData
encryptedKeyPkg
digestData
encryptedData
envelopedData
signedData
Turner, et al. Informational [Page 3]
RFC 7193 application/cms Media Type April 2014
innerContent=x; where x is one or more CMS ICT (Inner Content Type)
identifiers; multiple values encapsulated in quotes and are separated
by a folding-whitespace, a comma, and folding-whitespace. ICT values
are based on content types found in [RFC4108], [RFC5914], [RFC5934],
[RFC5958], [RFC6031], and [RFC7191]. This list can later be
extended; see Section 4.
firmwarePackage
firmwareLoadReceipt
firmwareLoadError
aKeyPackage
sKeyPackage
trustAnchorList
TAMP-statusQuery
TAMP-statusResponse
TAMP-update
TAMP-updateConfirm
TAMP-apexUpdate
TAMP-apexUpdateConfirm
TAMP-communityUpdate
TAMP-communityUpdateConfirm
TAMP-seqNumAdjust
TAMP-seqNumAdjustConfirm
TAMP-error
keyPackageReceipt
keyPackageError
The optional parameters are case sensitive.
Encoding considerations:
Binary.
[RFC5652] requires that the outermost encapsulation be
ContentInfo.
Turner, et al. Informational [Page 4]
RFC 7193 application/cms Media Type April 2014
Palet Martinez Expires September 5, 2018 [Page 14]
Internet-Draft NAT64 Deployment March 2018
able to obtain a shorter prefix by means of DHCPv6-PD ([RFC3633]), so
the CE can use a /64 for that.
The above recommendation is often not posible for cellular networks,
when connecting UEs (some broadband cellular use DHCPv6-PD
([RFC3633]), but smartphones, in general, not), as they provide a
single /64 for each PDP context and use /64 prefix sharing
([RFC6877]). So in this case, the UEs typically have a build-in CLAT
client, which is doing a stateful NAT44 before the stateless NAT46.
11. Summary of Deployment Recommendations for NAT64
Service providers willing to deploy NAT64, need to take into account
the considerations of this document to avoid the issues depicted in
this document.
In the case it is a non-cellular network and the operator is
providing the CEs to the customers, or suggesting them some specific
models, they MUST support the customer-side translator (CLAT), in
order to fully support the actual user needs (IPv4-only devices and
applications, usage of literals and old APIs).
If the operator offers DNS services, in order to increase performance
by reducing the double translation for all the IPv4 traffic, and
avoid breaking DNSSEC, they MAY support DNS64. In this case, if the
DNS service is offering DNSSEC validation, then it MUST be in such
way that it is aware of the DNS64. This is considered de simpler and
safer approach, and MAY be combined as well with the other possible
solutions described in this document:
o Devices running CLAT SHOULD follow the indications in the "Stub
validator" section recommendation. However, most of the time,
this is out of the control of the operator.
o CEs SHOULD include a DNS proxy and validador. This is relevant if
the operator is providing the CE or suggesting it to customers.
o ACL of clients and Mapping-out IPv4 addresses MAY be considered by
each operator, depending on their own infrastructure.
This "increased performance" approach has the disadvantage of
potentially breaking DNSSEC for a small percentage of validating end-
hosts.
If CE performance is not an issue, then a much safer approach is to
not use DNS64 at all, and consequently ensure that all the IPv4
traffic is translated at the CLAT.
Palet Martinez Expires September 5, 2018 [Page 15]
Internet-Draft NAT64 Deployment March 2018
If DNS64 is not used, one of the alternatives described in
Section 4.1, MUST be followed.
The ideal configuration for CEs supporting CLAT, is that they support
DHCPv6-PD ([RFC3633]) and internally reserve one /64 for the
stateless NAT46 translation. The operator MUST ensure that the
customers get allocated prefixes shorter than /64 in order to support
this optimization. One way or the other, this is not impacting the
performance of the operator network.
As indicated in Section 7 of [RFC6877] (Deployment Considerations),
operators MAY follow those suggestions in order to take advantage of
traffic engineering.
In the case of cellular networks, the considerations regarding DNSSEC
may appear as out-of-scope, because UEs OSs, commonly don't support
DNSSEC, however applications running on them may do, or it may be an
OS "built-in" support in the future. Moreover, if those devices
offer tethering, other client devices may be doing the validation,
hence the relevance of a proper DNSSEC support by the operator
network.
Furthermore, cellular networks supporting 464XLAT ([RFC6877]) and
"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"
([RFC7050]), allow a progressive IPv6 deployment, with a single APN
supporting all types of PDP context (IPv4, IPv6, IPv4v6), in such way
that the network is able to automatically serve all the possible
combinations of UEs.
Finally, if the operator choose to secure the NAT64 prefix, it MUST
follow the advise indicated in Section 3.1.1. of [RFC7050]
(Validation of Discovered Pref64::/n).
12. Deployment of NAT64 in Enterprise Networks
The recommendations of this documents can be used as well in
enterprise networks, campus and other similar scenarios, when the
NAT64 is under the control of that network, and for whatever reasons,
there is a need to provide "IPv6-only access" to any part of that
network or it is IPv6-only connected to third party networks.
An example of that is the IETF meetings network itself, where a NAT64
and DNS64 are provided, presenting in this case the same issues as
per Section 3.2. If there is a CLAT in the IETF network, then there
is no need to use DNS64 and it falls under the considerations of
Section 3.5. Both scenarios have been tested and verified already in
the IETF network itself.
Palet Martinez Expires September 5, 2018 [Page 16]
Internet-Draft NAT64 Deployment March 2018
13. Security Considerations
This document does not have any new specific security considerations.
14. IANA Considerations
This document does not have any new specific IANA considerations.
Note: This section is assuming that https://www.rfc-
editor.org/errata/eid5152 is resolved, otherwise, this section may
include the required text to resolve the issue.
15. Acknowledgements
The author would like to acknowledge the inputs of TBD ...
Conversations with Marcelo Bagnulo, one of the co-authors of DNS64,
as well as several emails in public mailing lists from Mark Andrews,
have been very useful for this work.
Christian Huitema inspired working in this document by suggesting
that DNS64 should never be used, during a discussion regarding the
deployment of CLAT in the IETF network.
16. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
DOI 10.17487/RFC3633, December 2003,
<https://www.rfc-editor.org/info/rfc3633>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
Palet Martinez Expires September 5, 2018 [Page 17]
Internet-Draft NAT64 Deployment March 2018
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
DOI 10.17487/RFC6147, April 2011,
<https://www.rfc-editor.org/info/rfc6147>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", RFC 6535,
DOI 10.17487/RFC6535, February 2012,
<https://www.rfc-editor.org/info/rfc6535>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis",
RFC 7050, DOI 10.17487/RFC7050, November 2013,
<https://www.rfc-editor.org/info/rfc7050>.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", RFC 7225,
DOI 10.17487/RFC7225, May 2014,
<https://www.rfc-editor.org/info/rfc7225>.
[RFC7278] Byrne, C., Drown, D., and A. Vizdal, "Extending an IPv6
/64 Prefix from a Third Generation Partnership Project
(3GPP) Mobile Interface to a LAN Link", RFC 7278,
DOI 10.17487/RFC7278, June 2014,
<https://www.rfc-editor.org/info/rfc7278>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
Palet Martinez Expires September 5, 2018 [Page 18]
Internet-Draft NAT64 Deployment March 2018
Author's Address
Jordi Palet Martinez
The IPv6 Company
Molino de la Navata, 75
La Navata - Galapagar, Madrid 28420
Spain
Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/
Palet Martinez Expires September 5, 2018 [Page 19]Security considerations:
The following security considerations apply:
RFC | CMS Protecting Content Type and Algorithms
----------+-------------------------------------------
[RFC3370] | signedData, envelopedData,
[RFC5652] | digestedData, encryptedData, and
[RFC5753] | authData
[RFC5754] |
----------+-------------------------------------------
[RFC5958] | aKeyPackage
[RFC5959] |
[RFC6162] |
----------+-------------------------------------------
[RFC6031] | sKeyPackage
[RFC6160] |
----------+-------------------------------------------
[RFC6032] | encryptedKeyPkg
[RFC6033] |
[RFC6161] |
----------+-------------------------------------------
[RFC5914] | trustAnchorList
----------+-------------------------------------------
[RFC3274] | compressedData
----------+-------------------------------------------
[RFC5083] | authEnvelopedData
[RFC5084] |
----------+-------------------------------------------
[RFC4073] | contentCollection and
| contentWithAttrs
----------+-------------------------------------------
[RFC4108] | firmwarePackage,
| firmwareLoadReceipt, and
| firmwareLoadError
----------+-------------------------------------------
[RFC5934] | TAMP-statusQuery, TAMP-statusResponse,
| TAMP-update, TAMP-updateConfirm,
| TAMP-apexUpdate,
| TAMP-apexUpdateConfirm,
| TAMP-communityUpdate,
| TAMP-communityUpdateConfirm,
| TAMP-seqNumAdjust,
| TAMP-seqNumAdjustConfirm, and
| TAMP-error
----------+-------------------------------------------
[RFC7191] |keyPackageReceipt and keyPackageError
----------+-------------------------------------------
Turner, et al. Informational [Page 5]
RFC 7193 application/cms Media Type April 2014
In some circumstances, significant information can be leaked by
disclosing what the innermost ASN.1 structure is. In these cases,
it is acceptable to disclose the wrappers without disclosing the
inner content type.
ASN.1 encoding rules (e.g., DER and BER) have a type-length-value
structure, and it is easy to construct malicious content with
invalid length fields that can cause buffer overrun conditions.
ASN.1 encoding rules allows for arbitrary levels of nesting, which
may make it possible to construct malicious content that will
cause a stack overflow. Interpreters of ASN.1 structures should
be aware of these issues and should take appropriate measures to
guard against buffer overflows and stack overruns in particular
and malicious content in general.
Interoperability considerations:
See [RFC3274], [RFC4073], [RFC4108], [RFC5083], [RFC5652],
[RFC5914], [RFC5934], [RFC5958], [RFC6031], [RFC6032], and
[RFC7191].
In all cases, CMS content types are encapsulated within
ContentInfo structures [RFC5652]; that is the outermost enveloping
structure is ContentInfo.
CMS [RFC5652] defines slightly different processing rules for
SignedData than does PKCS #7 [RFC2315]. This media type employs
the CMS processing rules.
The Content-Type header field of all application/cms objects
SHOULD include the optional "encapsulatingContent" and
"innerContent" parameters.
The Content-Disposition header field [RFC4021] can also be
included along with Content-Type's optional name parameter.
Published specification: This specification.
Applications that use this media type:
Applications that support CMS (Cryptographic Message Syntax)
content types.
Fragment identifier considerations: N/A
Turner, et al. Informational [Page 6]
RFC 7193 application/cms Media Type April 2014
Additional information:
Magic number(s): None
File extension(s): .cmsc
Macintosh File Type Code(s):
Person & email address to contact for further information:
Sean Turner <turners@ieca.com>
Intended usage: COMMON
Restrictions on usage: none
Author: Sean Turner <turners@ieca.com>
Change controller: The IESG <iesg@ietf.org>
Turner, et al. Informational [Page 7]
RFC 7193 application/cms Media Type April 2014
3. Example
The following is an example encrypted status response message:
MIME-Version: 1.0
Content-Type: application/cms; encapsulatingContent=encryptedData;
innerContent=TAMP-statusResponse; name=status.cmsc
Content-Transfer-Encoding: base64
MIIFLQYJKoZIhvcNAQcDoIIFHjCCBRoCAQAxggFhMIIBXQIBADBFMEAxC
zAJBgNVBAYTAlVTMR8wHQYDVQQKExZUZXN0IENlcnRpZmljYXRlcyAyMD
ExMRAwDgYDVQQDEwdHb29kIENBAgEBMA0GCSqGSIb3DQEBAQUABIIBAEa
uaXQeVsOyZ7gz0pJikRQ6Jqr64k2dbHBE4SDZL/uErP9FJUIja9LaJrc5
S83EZ7wf3mODUBaDhGfQVKoPrNTsLmw98fE/O+wcdpI2XKaILOR62xDJR
emQQST+EPfMwZmCwgsImmY3AxefAgzp8hVgK7SDiXGXfa9ux9PMdCSjHP
IgcAUFHmTiqxYd72Gl08kLCMIXmn3g5RsYUggxooeFNHiFNR28TV5HctG
i6Ay5++iKUGrUQyXD+GlwakFToGFmFj3FMyZi7+kYV/X00BiBP3kpIgVJ
4jCj+nYtKWh6JXPoEqEsa39GmDEFGq4/58GEu70amWvW1DA++7kDP4gwg
gOuBgkqhkiG9w0BBwEwHQYJYIZIAWUDBAECBBCH5yTQqZ4KYiTTeYdjoY
4sgIIDgArSpOcengKnZS4SCjfuQkMxB5wfSaud1thlZ+gUFCgzbFtkfYM
Qx/T7gnkneniyj2rwOmZxCQXpPlCDXH6mS83ngfrNN8ay3HrMPpVkEOmW
UMc5jI6oNObwqi8a3ezzhYRxF06jzdD2R/6SAPALz3Q4NU8eX+PnuekgR
oxo/INzhT4iGvokn9xVah6piSbjhPA+QZp1HgQrlWyyM3lG9jn4thchKl
FQqZEy/EBaCWq+sJG7LLxqS5k29CiAVx0JSItqAPvX1ZvLMY2aq//MQMw
0VFEx7Kt5aWNvKHTor9RUuuzwiZ5kwXt2vJt6bFiV7yS+EXofpFEmqyJP
VJzyAFIXJRTv4k007n0M1UpXQpGjywECI6DbIhfBL8CsNskTCjrsfU+Tw
RRkRKAbtJYughs9bDYkDu9UsKd/AE4zXk4prwo8/f1chpmzpHKOXiWzt+
xaCj648I4rOjdI9s4JP8J0qwVKoLEMGeiZlf2UlaiyMzZYzTOxI03PHp1
Whk6TXhnmMVPWGYjjelvE38gq/XynobbQRGEJdnnHzH7SrS27FmgRcnBO
3QQUPJChVn7iBHmdui++GAxpHoGdS6nSo4kQ6d5u5rL/Ctcnwu0k+s0Xi
ZMzOqp7L31xl1jvYUWIswLQYsIFoiejU3UTKzq/Cpd5MK+I8cwCM3aQ2c
D08URTPgu+U92pnYqm3auptywyjGAU/hkZ13XN7YRhLk/kuX8QXo3tZdj
dKA4f/uNf1DURpJK9004uCkxuAtu5HemMv7YPTTx9Ua2pZFW5O+k2Mf2Z
F/geOvtNw7UV8wOT1nokXu9lnIZ9Xcs1cGGmRYE7jW15F07uGnMi1s2Gt
LAST7t/PlTNZU6h0rVExErVa7T+VNidrgwGIke0YqYIwvTINRs+9VeJE3
AJeatDlQs+01jrqqFWWmGmmsEBTTRuoDQHK7YBFFy4xIwQqZGW0EVre39
OU5CL5LHIYiAVoV16YwiGd5WvFF8P1ZJK4ki8GFgYiMcPKmjQgP7DumqG
n7eQtMD5tezTQeC07ntV3bi5pdznZHVcF2Kqg+qHjJQlhUdK7Pew3kq7k
mfCdQV0BmQSYyjEAaTijaw4fAMxAbiw4OU0eNeU//zcpp04AuTFfJorIg
oZ+iCTYei8HMUA9/ysLFXA64wdsuCj0zXmNiYwosisuNg3TXfoBOzohKq
fkeXt
4. IANA Considerations
IANA has registered the media type application/cms in the Standards
tree using the applications provided in Section 2 of this document.
Turner, et al. Informational [Page 8]
RFC 7193 application/cms Media Type April 2014
IANA has established two subtype registries called "CMS Encapsulating
Content Types" and "CMS Inner Content Types". Entries in these
registries are allocated by Expert Review [RFC5226]. The Expert will
determine whether the content is an ECT or an ICT, where the rule is
that an ICT does not encapsulate another content type while an ECT
does encapsulate another content type.
Initial values are as follows:
CMS Encapsulating Content Types
Name | Document | Object Identifier
----------------------------+----------+---------------------------
authData |[RFC5652] | 1.2.840.113549.1.9.16.1.2
compressedData |[RFC3274] | 1.2.840.113549.1.9.16.1.9
contentCollection |[RFC4073] | 1.2.840.113549.1.9.16.1.19
contentInfo |[RFC5652] | 1.2.840.113549.1.9.16.1.6
contentWithAttrs |[RFC4073] | 1.2.840.113549.1.9.16.1.20
authEnvelopedData |[RFC5083] | 1.2.840.113549.1.9.16.1.23
encryptedKeyPkg |[RFC6032] | 2.16.840.1.101.2.1.2.78.2
digestData |[RFC5652] | 1.2.840.113549.1.9.16.1.5
encryptedData |[RFC5652] | 1.2.840.113549.1.9.16.1.6
envelopedData |[RFC5652] | 1.2.840.113549.1.9.16.1.3
signedData |[RFC5652] | 1.2.840.113549.1.9.16.1.2
CMS Inner Content Types
Name | Document | Object Identifier
----------------------------+----------+---------------------------
firmwarePackage |[RFC4108] | 1.2.840.113549.1.9.16.1.16
firmwareLoadReceipt |[RFC4108] | 1.2.840.113549.1.9.16.1.17
firmwareLoadError |[RFC4108] | 1.2.840.113549.1.9.16.1.18
aKeyPackage |[RFC5958] | 2.16.840.1.101.2.1.2.78.5
sKeyPackage |[RFC6031] | 1.2.840.113549.1.9.16.1.25
trustAnchorList |[RFC5914] | 1.2.840.113549.1.9.16.1.34
TAMP-statusQuery |[RFC5934] | 2.16.840.1.101.2.1.2.77.1
TAMP-statusResponse |[RFC5934] | 2.16.840.1.101.2.1.2.77.2
TAMP-update |[RFC5934] | 2.16.840.1.101.2.1.2.77.3
TAMP-updateConfirm |[RFC5934] | 2.16.840.1.101.2.1.2.77.4
TAMP-apexUpdate |[RFC5934] | 2.16.840.1.101.2.1.2.77.5
TAMP-apexUpdateConfirm |[RFC5934] | 2.16.840.1.101.2.1.2.77.6
TAMP-communityUpdate |[RFC5934] | 2.16.840.1.101.2.1.2.77.7
TAMP-communityUpdateConfirm |[RFC5934] | 2.16.840.1.101.2.1.2.77.8
TAMP-seqNumAdjust |[RFC5934] | 2.16.840.1.101.2.1.2.77.10
TAMP-seqNumAdjustConfirm |[RFC5934] | 2.16.840.1.101.2.1.2.77.11
TAMP-error |[RFC5934] | 2.16.840.1.101.2.1.2.77.9
keyPackageReceipt |[RFC7191] | 2.16.840.1.101.2.1.2.78.3
keyPackageError |[RFC7191] | 2.16.840.1.101.2.1.2.78.6
Turner, et al. Informational [Page 9]
RFC 7193 application/cms Media Type April 2014
5. Security Considerations
See the answer to the Security Considerations template questions in
Section 2.
6. Acknowledgments
Special thanks to Carl Wallace for generating the example in
Section 3.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3274] Gutmann, P., "Compressed Data Content Type for
Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[RFC4021] Klyne, G. and J. Palme, "Registration of Mail and MIME
Header Fields", RFC 4021, March 2005.
[RFC4073] Housley, R., "Protecting Multiple Contents with the
Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
[RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to
Protect Firmware Packages", RFC 4108, August 2005.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083,
November 2007.
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)", RFC
5084, November 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC): Transport Protocols", RFC 5273, June 2008.
Turner, et al. Informational [Page 10]
RFC 7193 application/cms Media Type April 2014
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve
Cryptography (ECC) Algorithms in Cryptographic Message
Syntax (CMS)", RFC 5753, January 2010.
[RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", RFC 5754, January 2010.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, June 2010.
[RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Management Protocol (TAMP)", RFC 5934, August 2010.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August
2010.
[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content
Type", RFC 5959, August 2010.
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax
(CMS) Symmetric Key Package Content Type", RFC 6031,
December 2010.
[RFC6032] Turner, S. and R. Housley, "Cryptographic Message Syntax
(CMS) Encrypted Key Package Content Type", RFC 6032,
December 2010.
[RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax
(CMS) Encrypted Key Package Content Type", RFC 6033,
December 2010.
[RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax
(CMS) Protection of Symmetric Key Package Content Types",
RFC 6160, April 2011.
[RFC6161] Turner, S., "Elliptic Curve Algorithms for Cryptographic
Message Syntax (CMS) Encrypted Key Package Content Type",
RFC 6161, April 2011.
[RFC6162] Turner, S., "Elliptic Curve Algorithms for Cryptographic
Message Syntax (CMS) Asymmetric Key Package Content Type",
RFC 6162, April 2011.
Turner, et al. Informational [Page 11]