|
1.
|
Clear description of the referenced document:
|
|
|
|
Name:
|
IETF RFC 5084 (2007)
|
|
Title:
|
Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS).
|
|
|
2.
|
Status of approval:
|
|
|
Standard Track
|
|
3.
|
Justification for the specific reference:
|
|
|
Referenced by the base part of the document
|
|
4.
|
Current information, if any, about IPR issues:
|
|
|
Information on IPR issues regarding RFCs is available at: https://datatracker.ietf.org/ipr/search/. Specifically: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=2104
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
Proposed Standard
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
Proposed Standard
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
References within the referenced RFCs are listed under item (5.1).
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", November 2001./
/
[CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003./
/
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004./
/
[GCM] Dworkin, M., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC." , U.S. National Institute of Standards and Technology/
/
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997./
/
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988./
/
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988./
/
[X.509-88] CCITT. Recommendation X.509: The Directory-Authentication Framework. 1988.
|
|
9.
|
Qualification of
ISOC/IETF:
|
|
|
9.1-9.6 Decisions of ITU Council to admit ISOC to participate in the work of the Sector (June 1995 and June 1996).
9.7 The Internet Engineering Steering Group (IESG) is responsible for ongoing maintenance of the RFCs when the need arises. Comments on RFCs and corresponding changes are accommodated through the existing standardization process.
9.8 Each revision of a given RFC has a different RFC number, so no confusion is possible. All RFCs always remain available on-line. An index of RFCs and their status may be found in the IETF archives at http://www.rfc-editor.org/rfc.html.
|
|
10.
|
Other (for any supplementary information):
|
|
|
Other: If the study group decides to make the reference to the RFC, the reference should always be made by RFC number (and not by other designations such as STD, BCP, etc.). References should not be made to documents referred to as "Internet Drafts" or RFCs categorized as "Historic". Normative references should not be made to RFCs that are not standards, for example, "Informational" and "Experimental" RFCs.
|
