|
1.
|
Clear description of the referenced document:
|
|
|
|
|
2.
|
Status of approval:
|
|
|
Normative
|
|
3.
|
Justification for the specific reference:
|
|
|
6.IETF RFC 3852 R. Housley, "Cryptographic Message Syntax (CMS)"
Location of generic justification document:
http://ties.itu.int/u/tsg16/sg16/a5-references/refinfo-rfc3852.doc
Justification for the specific reference in this draft recommendation (A.5 Appendix I item 3):
H.235.8 refers to the Cryptographic Message Syntax defined in IETF RFC 3852.
|
|
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=3852
|
|
5.
|
Other useful information describing the "Quality" of the document:
|
|
|
RFC 3852 has been in existence since 2004. Although new, it obsoletes RFC 3369 which has been in existence since August, 2002, which itself obsoletes RFC 2630, which has been existence since June 1999, and RFC 3211, which has been in existence since December 2001. These documents have been reviewed extensively in IETF.
|
|
6.
|
The degree of stability or maturity of the document:
|
|
|
RFC is a standards-track document and is currently in the "Proposed Standard" state. Current standards status of this document can be found at ftp://ftp.isi.edu/in-notes/std/std1.txt
|
|
7.
|
Relationship with other existing or emerging documents:
|
|
|
RFC 3852 defines the Cryptographic Message Syntax and is expected to be widely used.
|
|
8.
|
Any explicit references within that referenced document should also be listed:
|
|
|
Normative References/
[1] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002./
/
[2] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002./
/
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997./
/
[4] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988./
/
[5] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988./
/
[6] CCITT. Recommendation X.501: The Directory - Models.1988./
/
[7] CCITT. Recommendation X.509: The Directory - Authentication Framework. 1988./
/
[8] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 1997./
/
[9] ITU-T. Recommendation X.509: The Directory - Authentication Framework. 2000./
/
/
Informative References/
[10] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999./
/
[11] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002./
/
[12] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002./
/
[13] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999./
/
[14] Microsoft Development Network (MSDN) Library, "Authenticode", April 2004 Release./
/
[15] Ramsdell, B., "S/MIME Version 3.1 Message Specification", RFC 3851, July 2004./
/
[16] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June1999./
/
[17] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998./
/
[18] RSA Laboratories. PKCS #6: Extended-Certificate Syntax Standard, Version 1.5. November 1993./
/
[19] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998./
/
[20] RSA Laboratories. PKCS #9: Selected Attribute Types, Version 1.1. November 1993./
/
[21] Gutmann, P., "Password-based Encryption for CMS", RFC 3211, December 2001./
/
[22] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
|
|
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):
|
|
|
References should always be made to RFC numbers (and not by other designations such as STD, BCP, etc.). References not to 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.
|
|
