rfc5743.Definition of an Internet Research Task Force (IRTF) Document Stream

Network Working Group R. Housley Request for Comments: 5652 Vigil Security Obsoletes: 3852 September 2009 Category: Standards TrackCryptographic Message Syntax (CMS)AbstractThis document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encryptarbitrary message content.Status of This MemoThis document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited. Copyright and License NoticeCopyright (c) 2009 IETF Trust and the persons identified as thedocument authors. All rights reserved.This document is subject to BCP 78 and the IETF Trust’s LegalProvisions Relating to IETF Documents(/license-info) in effect on the date ofpublication of this document. Please review these documentscarefully, 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 ofthe Trust Legal Provisions and are provided without warranty asdescribed in the BSD License.This document may contain material from IETF Documents or IETFContributions published or made publicly available before November10, 2008. The person(s) controlling the copyright in some of thismaterial may not have granted the IETF Trust the right to allowmodifications 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 modifiedoutside the IETF Standards Process, and derivative works of it maynot be created outside the IETF Standards Process, except to formatit for publication as an RFC or to translate it into languages other than English.Housley Standards Track [Page 1]Table of Contents1. Introduction (3)1.1. Evolution of the CMS (4)1.1.1. Changes Since PKCS #7 Version 1.5 (4)1.1.2. Changes Since RFC 2630 (4)1.1.3. Changes Since RFC 3369 (5)1.1.4. Changes Since RFC 3852 (5)1.2. Terminology (5)1.3. Version Numbers (6)2. General Overview (6)3. General Syntax (7)4. Data Content Type (7)5. Signed-data Content Type (8)5.1. SignedData Type (9)5.2. EncapsulatedContentInfo Type (11)5.2.1. Compatibility with PKCS #7 (12)5.3. SignerInfo Type (13)5.4. Message Digest Calculation Process (16)5.5. Signature Generation Process (16)5.6. Signature Verification Process (17)6. Enveloped-Data Content Type (17)6.1. EnvelopedData Type (18)6.2. RecipientInfo Type (21)6.2.1. KeyTransRecipientInfo Type (22)6.2.2. KeyAgreeRecipientInfo Type (23)6.2.3. KEKRecipientInfo Type (25)6.2.4. PasswordRecipientInfo Type (26)6.2.5. OtherRecipientInfo Type (27)6.3. Content-encryption Process (27)6.4. Key-Encryption Process (28)7. Digested-Data Content Type (28)8. Encrypted-Data Content Type (29)9. Authenticated-Data Content Type (30)9.1. AuthenticatedData Type (31)9.2. MAC Generation (33)9.3. MAC Verification (34)10. Useful Types (34)10.1. Algorithm Identifier Types (35)10.1.1. DigestAlgorithmIdentifier (35)10.1.2. SignatureAlgorithmIdentifier (35)10.1.3. KeyEncryptionAlgorithmIdentifier (35)10.1.4. ContentEncryptionAlgorithmIdentifier (36)10.1.5. MessageAuthenticationCodeAlgorithm (36)10.1.6. KeyDerivationAlgorithmIdentifier (36)10.2. Other Useful Types (36)10.2.1. RevocationInfoChoices (36)10.2.2. CertificateChoices (37)Housley Standards Track [Page 2]10.2.3. CertificateSet (38)10.2.4. IssuerAndSerialNumber (38)10.2.5. CMSVersion (39)10.2.6. UserKeyingMaterial (39)10.2.7. OtherKeyAttribute (39)11. Useful Attributes (39)11.1. Content Type (40)11.2. Message Digest (40)11.3. Signing Time (41)11.4. Countersignature (42)12. ASN.1 Modules (43)12.1. CMS ASN.1 Module (44)12.2. Version 1 Attribute Certificate ASN.1 Module (51)13. References (52)13.1. Normative References (52)13.2. Informative References (53)14. Security Considerations (54)15. Acknowledgments (56)1. IntroductionThis document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encryptarbitrary message content.The CMS describes an encapsulation syntax for data protection. Itsupports digital signatures and encryption. The syntax allowsmultiple encapsulations; one encapsulation envelope can be nestedinside another. Likewise, one party can digitally sign somepreviously encapsulated data. It also allows arbitrary attributes,such as signing time, to be signed along with the message content,and it provides for other attributes such as countersignatures to be associated with a signature.The CMS can support a variety of architectures for certificate-based key management, such as the one defined by the PKIX (Public KeyInfrastructure using X.509) working group [PROFILE].The CMS values are generated using ASN.1 [X.208-88], using BER-encoding (Basic Encoding Rules) [X.209-88]. Values are typicallyrepresented as octet strings. While many systems are capable oftransmitting arbitrary octet strings reliably, it is well known that many electronic mail systems are not. This document does not address mechanisms for encoding octet strings for reliable transmission insuch environments.Housley Standards Track [Page 3]1.1. Evolution of the CMSThe CMS is derived from PKCS #7 version 1.5, which is documented inRFC 2315 [PKCS#7]. PKCS #7 version 1.5 was developed outside of the IETF; it was originally published as an RSA Laboratories TechnicalNote in November 1993. Since that time, the IETF has takenresponsibility for the development and maintenance of the CMS.Today, several important IETF Standards-Track protocols make use ofthe CMS.This section describes that changes that the IETF has made to the CMS in each of the published versions.1.1.1. Changes Since PKCS #7 Version 1.5RFC 2630 [CMS1] was the first version of the CMS on the IETFStandards Track. Wherever possible, backward compatibility with PKCS #7 version 1.5 is preserved; however, changes were made toaccommodate version 1 attribute certificate transfer and to supportalgorithm-independent key management. PKCS #7 version 1.5 includedsupport only for key transport. RFC 2630 adds support for keyagreement and previously distributed symmetric key-encryption keytechniques.1.1.2. Changes Since RFC 2630RFC 3369 [CMS2] obsoletes RFC 2630 [CMS1] and RFC 3211 [PWRI].Password-based key management is included in the CMS specification,and an extension mechanism to support new key management schemeswithout further changes to the CMS is specified. Backwardcompatibility with RFC 2630 and RFC 3211 is preserved; however,version 2 attribute certificate transfer is added, and the use ofversion 1 attribute certificates is deprecated.Secure/Multipurpose Internet Mail Extensions (S/MIME) v2 signatures[MSG2], which are based on PKCS #7 version 1.5, are compatible withS/MIME v3 signatures [MSG3]and S/MIME v3.1 signatures [MSG3.1].However, there are some subtle compatibility issues with signaturesbased on PKCS #7 version 1.5. These issues are discussed in Section 5.2.1. These issues remain with the current version of the CMS.Specific cryptographic algorithms are not discussed in this document, but they were discussed in RFC 2630. The discussion of specificcryptographic algorithms has been moved to a separate document[CMSALG]. Separation of the protocol and algorithm specificationsallows the IETF to update each document independently. Thisspecification does not require the implementation of any particular Housley Standards Track [Page 4]algorithms. Rather, protocols that rely on the CMS are expected tochoose appropriate algorithms for their environment. The algorithms may be selected from [CMSALG] or elsewhere.1.1.3. Changes Since RFC 3369RFC 3852 [CMS3] obsoletes RFC 3369 [CMS2]. As discussed in theprevious section, RFC 3369 introduced an extension mechanism tosupport new key management schemes without further changes to theCMS. RFC 3852 introduces a similar extension mechanism to supportadditional certificate formats and revocation status informationformats without further changes to the CMS. These extensions areprimarily documented in Sections 10.2.1 and 10.2.2. Backwardcompatibility with earlier versions of the CMS is preserved.The use of version numbers is described in Section 1.3.Since the publication of RFC 3369, a few errata have been noted.These errata are posted on the RFC Editor web site. These errorshave been corrected in this document.The text in Section 11.4 that describes the counter signatureunsigned attribute is clarified. Hopefully, the revised text isclearer about the portion of the SignerInfo signature that is covered by a countersignature.1.1.4. Changes Since RFC 3852This document obsoletes RFC 3852 [CMS3]. The primary reason for the publication of this document is to advance the CMS along thestandards maturity ladder.This document includes the clarifications that were originallypublished in RFC 4853 [CMSMSIG] regarding the proper handling of the SignedData protected content type when more than one digitalsignature is present.Since the publication of RFC 3852, a few errata have been noted.These errata are posted on the RFC Editor web site. These errorshave been corrected in this document.1.2. TerminologyIn this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted asdescribed in [STDWORDS].Housley Standards Track [Page 5]1.3. Version NumbersEach of the major data structures includes a version number as thefirst item in the data structure. The version numbers are intendedto avoid ASN.1 decode errors. Some implementations do not check the version number prior to attempting a decode, and if a decode erroroccurs, then the version number is checked as part of the errorhandling routine. This is a reasonable approach; it places errorprocessing outside of the fast path. This approach is also forgiving when an incorrect version number is used by the sender.Most of the initial version numbers were assigned in PKCS #7 version 1.5. Others were assigned when the structure was initially created. Whenever a structure is updated, a higher version number is assigned. However, to ensure maximum interoperability, the higher versionnumber is only used when the new syntax feature is employed. Thatis, the lowest version number that supports the generated syntax isused.2. General OverviewThe CMS is general enough to support many different content types.This document defines one protection content, ContentInfo.ContentInfo encapsulates a single identified content type, and theidentified type may provide further encapsulation. This documentdefines six content types: data, signed-data, enveloped-data,digested-data, encrypted-data, and authenticated-data. Additionalcontent types can be defined outside this document.An implementation that conforms to this specification MUST implement the protection content, ContentInfo, and MUST implement the data,signed-data, and enveloped-data content types. The other contenttypes MAY be implemented.As a general design philosophy, each content type permits single pass processing using indefinite-length Basic Encoding Rules (BER)encoding. Single-pass operation is especially helpful if content is large, stored on tapes, or is "piped" from another process. Single- pass operation has one significant drawback: it is difficult toperform encode operations using the Distinguished Encoding Rules(DER) [X.509-88] encoding in a single pass since the lengths of thevarious components may not be known in advance. However, signedattributes within the signed-data content type and authenticatedattributes within the authenticated-data content type need to betransmitted in DER form to ensure that recipients can verify acontent that contains one or more unrecognized attributes. Signedattributes and authenticated attributes are the only data types used in the CMS that require DER encoding.Housley Standards Track [Page 6]3. General SyntaxThe following object identifier identifies the content informationtype:id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }The CMS associates a content type identifier with a content. Thesyntax MUST have ASN.1 type ContentInfo:ContentInfo ::= SEQUENCE {contentType ContentType,content [0] EXPLICIT ANY DEFINED BY contentType }ContentType ::= OBJECT IDENTIFIERThe fields of ContentInfo have the following meanings:contentType indicates the type of the associated content. It isan object identifier; it is a unique string of integers assignedby an authority that defines the content type.content is the associated content. The type of content can bedetermined uniquely by contentType. Content types for data,signed-data, enveloped-data, digested-data, encrypted-data, andauthenticated-data are defined in this document. If additionalcontent types are defined in other documents, the ASN.1 typedefined SHOULD NOT be a CHOICE type.4. Data Content TypeThe following object identifier identifies the data content type:id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }The data content type is intended to refer to arbitrary octetstrings, such as ASCII text files; the interpretation is left to the application. Such strings need not have any internal structure(although they could have their own ASN.1 definition or otherstructure).S/MIME uses id-data to identify MIME-encoded content. The use ofthis content identifier is specified in RFC 2311 for S/MIME v2[MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1[MSG3.1].Housley Standards Track [Page 7]The data content type is generally encapsulated in the signed-data,enveloped-data, digested-data, encrypted-data, or authenticated-data content type.5. Signed-data Content TypeThe signed-data content type consists of a content of any type andzero or more signature values. Any number of signers in parallel can sign any type of content.The typical application of the signed-data content type representsone signer’s digital signature on content of the data content type.Another typical application disseminates certificates and certificate revocation lists (CRLs).The process by which signed-data is constructed involves thefollowing steps:1. For each signer, a message digest, or hash value, is computed on the content with a signer-specific message-digest algorithm. If the signer is signing any information other than the content, the message digest of the content and the other information aredigested with the signer’s message digest algorithm (see Section 5.4), and the result becomes the "message digest."2. For each signer, the message digest is digitally signed using the signer’s private key.3. For each signer, the signature value and other signer-specificinformation are collected into a SignerInfo value, as defined in Section 5.3. Certificates and CRLs for each signer, and thosenot corresponding to any signer, are collected in this step.4. The message digest algorithms for all the signers and theSignerInfo values for all the signers are collected together with the content into a SignedData value, as defined in Section 5.1.A recipient independently computes the message digest. This message digest and the signer’s public key are used to verify the signaturevalue. The signer’s public key is referenced in one of two ways. It can be referenced by an issuer distinguished name along with anissuer-specific serial number to uniquely identify the certificatethat contains the public key. Alternatively, it can be referenced by a subject key identifier, which accommodates both certified anduncertified public keys. While not required, the signer’scertificate can be included in the SignedData certificates field. Housley Standards Track [Page 8]When more than one signature is present, the successful validation of one signature associated with a given signer is usually treated as a successful signature by that signer. However, there are someapplication environments where other rules are needed. Anapplication that employs a rule other than one valid signature foreach signer must specify those rules. Also, where simple matching of the signer identifier is not sufficient to determine whether thesignatures were generated by the same signer, the applicationspecification must describe how to determine which signatures weregenerated by the same signer. Support of different communities ofrecipients is the primary reason that signers choose to include more than one signature. For example, the signed-data content type might include signatures generated with the RSA signature algorithm andwith the Elliptic Curve Digital Signature Algorithm (ECDSA) signature algorithm. This allows recipients to verify the signature associated with one algorithm or the other.This section is divided into six parts. The first part describes the top-level type SignedData, the second part describesEncapsulatedContentInfo, the third part describes the per-signerinformation type SignerInfo, and the fourth, fifth, and sixth partsdescribe the message digest calculation, signature generation, andsignature verification processes, respectively.5.1. SignedData TypeThe following object identifier identifies the signed-data contenttype:id-signedData OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }The signed-data content type shall have ASN.1 type SignedData:SignedData ::= SEQUENCE {version CMSVersion,digestAlgorithms DigestAlgorithmIdentifiers,encapContentInfo EncapsulatedContentInfo,certificates [0] IMPLICIT CertificateSet OPTIONAL,crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,signerInfos SignerInfos }DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifierSignerInfos ::= SET OF SignerInfoHousley Standards Track [Page 9]The fields of type SignedData have the following meanings:version is the syntax version number. The appropriate valuedepends on certificates, eContentType, and SignerInfo. Theversion MUST be assigned as follows:IF ((certificates is present) AND(any certificates with a type of other are present)) OR((crls is present) AND(any crls with a type of other are present))THEN version MUST be 5ELSEIF (certificates is present) AND(any version 2 attribute certificates are present)THEN version MUST be 4ELSEIF ((certificates is present) AND(any version 1 attribute certificates are present)) OR (any SignerInfo structures are version 3) OR(encapContentInfo eContentType is other than id-data) THEN version MUST be 3ELSE version MUST be 1digestAlgorithms is a collection of message digest algorithmidentifiers. There MAY be any number of elements in thecollection, including zero. Each element identifies the messagedigest algorithm, along with any associated parameters, used byone or more signer. The collection is intended to list themessage digest algorithms employed by all of the signers, in anyorder, to facilitate one-pass signature verification.Implementations MAY fail to validate signatures that use a digest algorithm that is not included in this set. The message digesting process is described in Section 5.4.encapContentInfo is the signed content, consisting of a contenttype identifier and the content itself. Details of theEncapsulatedContentInfo type are discussed in Section 5.2.certificates is a collection of certificates. It is intended that the set of certificates be sufficient to contain certificationpaths from a recognized "root" or "top-level certificationauthority" to all of the signers in the signerInfos field. There may be more certificates than necessary, and there may becertificates sufficient to contain certification paths from two or more independent top-level certification authorities. There mayalso be fewer certificates than necessary, if it is expected that recipients have an alternate means of obtaining necessaryHousley Standards Track [Page 10]certificates (e.g., from a previous set of certificates). Thesigner’s certificate MAY be included. The use of version 1attribute certificates is strongly discouraged.crls is a collection of revocation status information. It isintended that the collection contain information sufficient todetermine whether the certificates in the certificates field arevalid, but such correspondence is not necessary. Certificaterevocation lists (CRLs) are the primary source of revocationstatus information. There MAY be more CRLs than necessary, andthere MAY also be fewer CRLs than necessary.signerInfos is a collection of per-signer information. There MAY be any number of elements in the collection, including zero. When the collection represents more than one signature, the successful validation of one of signature from a given signer ought to betreated as a successful signature by that signer. However, there are some application environments where other rules are needed.The details of the SignerInfo type are discussed in Section 5.3.Since each signer can employ a different digital signaturetechnique, and future specifications could update the syntax, all implementations MUST gracefully handle unimplemented versions ofSignerInfo. Further, since all implementations will not supportevery possible signature algorithm, all implementations MUSTgracefully handle unimplemented signature algorithms when they are encountered.5.2. EncapsulatedContentInfo TypeThe content is represented in the type EncapsulatedContentInfo:EncapsulatedContentInfo ::= SEQUENCE {eContentType ContentType,eContent [0] EXPLICIT OCTET STRING OPTIONAL }ContentType ::= OBJECT IDENTIFIERThe fields of type EncapsulatedContentInfo have the followingmeanings:eContentType is an object identifier. The object identifieruniquely specifies the content type.eContent is the content itself, carried as an octet string. TheeContent need not be DER encoded.Housley Standards Track [Page 11]The optional omission of the eContent within theEncapsulatedContentInfo field makes it possible to construct"external signatures". In the case of external signatures, thecontent being signed is absent from the EncapsulatedContentInfo value included in the signed-data content type. If the eContent valuewithin EncapsulatedContentInfo is absent, then the signatureValue is calculated and the eContentType is assigned as though the eContentvalue was present.In the degenerate case where there are no signers, theEncapsulatedContentInfo value being "signed" is irrelevant. In this case, the content type within the EncapsulatedContentInfo value being "signed" MUST be id-data (as defined in Section 4), and the contentfield of the EncapsulatedContentInfo value MUST be omitted.5.2.1. Compatibility with PKCS #7This section contains a word of warning to implementers that wish to support both the CMS and PKCS #7 [PKCS#7] SignedData content types.Both the CMS and PKCS #7 identify the type of the encapsulatedcontent with an object identifier, but the ASN.1 type of the content itself is variable in PKCS #7 SignedData content type.PKCS #7 defines content as:content [0] EXPLICIT ANY DEFINED BY contentType OPTIONALThe CMS defines eContent as:eContent [0] EXPLICIT OCTET STRING OPTIONALThe CMS definition is much easier to use in most applications, and it is compatible with both S/MIME v2 and S/MIME v3. S/MIME signedmessages using the CMS and PKCS #7 are compatible because identicalsigned message formats are specified in RFC 2311 for S/MIME v2[MSG2], RFC 2633 for S/MIME v3 [MSG3], and RFC 3851 for S/MIME v3.1[MSG3.1]. S/MIME v2 encapsulates the MIME content in a Data type(that is, an OCTET STRING) carried in the SignedData contentInfocontent ANY field, and S/MIME v3 carries the MIME content in theSignedData encapContentInfo eContent OCTET STRING. Therefore, inS/MIME v2, S/MIME v3, and S/MIME v3.1, the MIME content is placed in an OCTET STRING and the message digest is computed over the identical portions of the content. That is, the message digest is computedover the octets comprising the value of the OCTET STRING, neither the tag nor length octets are included.Housley Standards Track [Page 12]There are incompatibilities between the CMS and PKCS #7 SignedDatatypes when the encapsulated content is not formatted using the Datatype. For example, when an RFC 2634 signed receipt [ESS] isencapsulated in the CMS SignedData type, then the Receipt SEQUENCE is encoded in the SignedData encapContentInfo eContent OCTET STRING and the message digest is computed using the entire Receipt SEQUENCEencoding (including tag, length and value octets). However, if anRFC 2634 signed receipt is encapsulated in the PKCS #7 SignedDatatype, then the Receipt SEQUENCE is DER encoded [X.509-88] in theSignedData contentInfo content ANY field (a SEQUENCE, not an OCTETSTRING). Therefore, the message digest is computed using only thevalue octets of the Receipt SEQUENCE encoding.The following strategy can be used to achieve backward compatibility with PKCS #7 when processing SignedData content types. If theimplementation is unable to ASN.1 decode the SignedData type usingthe CMS SignedData encapContentInfo eContent OCTET STRING syntax,then the implementation MAY attempt to decode the SignedData typeusing the PKCS #7 SignedData contentInfo content ANY syntax andcompute the message digest accordingly.The following strategy can be used to achieve backward compatibility with PKCS #7 when creating a SignedData content type in which theencapsulated content is not formatted using the Data type.Implementations MAY examine the value of the eContentType, and thenadjust the expected DER encoding of eContent based on the objectidentifier value. For example, to support Microsoft Authenticode[MSAC], the following information MAY be included:eContentType Object Identifier is set to { 1 3 6 1 4 1 311 2 1 4 } eContent contains DER-encoded Authenticode signing information5.3. SignerInfo TypePer-signer information is represented in the type SignerInfo:SignerInfo ::= SEQUENCE {version CMSVersion,sid SignerIdentifier,digestAlgorithm DigestAlgorithmIdentifier,signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,signatureAlgorithm SignatureAlgorithmIdentifier,signature SignatureValue,unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }Housley Standards Track [Page 13]。

Internet Message Access Protocol (IMAP) is an email retrieval protocol. It stores email messages on a mail server and enables the recipient to view and manipulate them as though they were stored locally on their device. IMAP was developed in the late 1980s and has since become one of the most widely used email retrieval protocols.The IMAP standard is defined in RFC 3501, which was published in 2003. This document provides a detailed description of the protocol's functionality, including its data formats, commands, and responses. The standard specifies how IMAP clients and servers should communicate with each other to enable the retrieval and manipulation of email messages.One of the key features of IMAP is its support for multiple clients accessing the same mailbox simultaneously. This is achieved through the use of a "shared" storage model, where all clients see the same set of messages and folders stored on the server. This allows users to access their email from different devices without having to worry about synchronizing their messages manually.Another important aspect of IMAP is its support for message organization and management. Clients can create, delete, and rename folders, as well as move messages between folders. They can also search for specific messages based on various criteria, such as sender, subject, or date.IMAP also provides a range of features for managing individual messages. Clients can mark messages as read or unread, flag them for follow-up, and even move them to a specific folder. They can also reply to messages, forward them to others, and generate replies or forwards with attachments.Overall, the IMAP standard provides a powerful and flexible framework for managing email messages. Its support for shared storage, message organization, and advanced message management features make it a popular choice for both personal and business email users.。

组织：中国互动出版网（/）RFC文档中文翻译计划(/compters/emook/aboutemook.htm)E-mail：ouyang@译者：党红梅（snowlily danghongmei@）译文发布时间：2001－4－27版权：本中文翻译文档版权归中国互动出版网所有。

可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。

Network Working Group R. Hinden Request for Comments: 2373 Nokia Obsoletes: 1884 S. Deering Category: Standards Track Cisco Systems July 1998IPv6寻址体系结构（RFC2373: IP Version 6 Addressing Architecture）本备忘录的状态本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。

请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。

本备忘录的发布不受任何限制。

版权声明Copyright (C) The Internet Society (1998). All Rights Reserved.摘要本技术规范定义I P v 6的寻址体系结构。

本文件包括I P v 6 寻址模型、I P v 6 地址的文字表示、I P v 6 单播地址、任意点播地址和组播地址的定义以及I P v 6 节点需要的地址。

目录摘要 11．简介 22. IPv6 寻址 22.1 寻址模型 32.2 地址的文本表示 32.3 地址前缀的文本表示 42.4 地址类型表示 52.5 单播地址 52.5.1 接口标识符 62.5.2 未指定地址72.5.3 回返地址72.5.4 嵌有IPv4 地址的IPv6 地址72.5.5 NSAP 地址72.5.6 IPX 地址82.5.7 可集聚全球单播地址82.5.8 本地用IPv6 单播地址82.6 任意点播地址92．6．1要求的任意点播地址92.7 组播地址102.7.1 预定义的组播地址112.7.2 新IPv6 组播地址的分配122.8 节点要求的地址123. 安全性考虑13附录A 创建EUI-64 接口标识符13A.1 具有EUI-64 标识符的链路或节点13A.2 具有IEEE 802 48 位MAC 地址的链路或节点13A.3 具有非全球标识符的链路14A.4 无标识符的链路14附录B 文本表示的ABNF 描述 15附录C 对RFC 1884 的修改15参考资料16作者联系方法17版权说明171．简介本技术规范定义了I P v 6 的寻址体系结构。

AWAF知识点学习AWAF知识点Data GuardData Guard是在HTTP响应中防⽌铭感数据泄露的，⽐如在HTTP响应中包含了信⽤卡信息、U.S.Social Security number等，或者是⾃定义的信息。

有两种防护⽅式当Policy是Blocking的时候，如果响应中包含了敏感信息，AWAF会拦截这个响应AWAF也可以对敏感信息进⾏加密，只有在Policy是Transparent或者是Bolcking但是Data Guard是Alarm/Learn的时候才会加密，加密的形式是*，并且需要勾选Mask Data可以使⽤⾃定义的Patterns来本地化定义⾝份证信息或电话号4[0-9]{3}-[0-9]{4}-[0-9]{4}-#表⽰以4开头的前⼗⼆位数为敏感数据，AWAF将对其进⾏隐藏#[]表⽰0-9的数字；{}表⽰数的位数Exception Patterns该选项表⽰指定系统认为那些不是铭感数据File Content Detection指定系统是否检查⽂件内容的响应，如果是，哪些类型的⽂件内容被视为敏感数据。

这可以防⽌服务器将您不希望返回给⽤户的⽂件内容传递给⽤户。

Enforcement Mode⽤于指定Data Guard对那些URL进⾏防护Ignore URLs---Data Guard会防护所有的URL，除了列表中的Enforce URLs---Data Guard会防护列表中的URL，即使该URL并不在Security Policy中AWAF将Cookie分为两种，分别是Allowed和EnforcedAllowed类型的Cookie⼀般是Persistent Cookie、Single Sign On Cookie、或者是其他的合法的Cookie。

当这类Cookie背设置为Allow，AWAF会忽略并不会触发告警；Allowed Cookie可以设置Explicit和Wildcard两种Enforced类型的Cookie是在客户端侧不应该被修改的。

RFC2866 - RADIUS记账(1)RFC2866 - RADIUS Accounting摘要本文描述在网络访问服务器和记账服务器之间传递记账信息协议。

注意本文描述RADIUS记账协议。

早期的RADIUS记账报文使用UDP1646端口，这和“sa-msg-port”服务冲突。

RADIUS记账协议的正式端口是1813。

1.概述管理大量用户的分散的串行线路和modem池为管理支持创建了大量需求。

因为modem池定义和外界联系的方式，必须仔细关注安全，授权和记账问题。

通过管理一个用户数据库，允许用户认证（确认用户名和密码），同时配置为用户传递数据的服务类型，是一种最佳的实现方式。

RADIUS协议用来进行认证和授权。

本文扩展了RADIUS协议，将记账报文通过NAS传递到RADIUS记账服务器。

本文废弃了RFC 2139。

RADIUS记账的特点如下：●C/S模式网络访问服务器（NAS）作为客户端与RADIUS记账服务器进行交互。

客户端需要将记账报文发向指定的记账服务器。

RADIUS记账服务器的职责是接收记账请求，并且向客户端应答报文表示记账成功。

RADIUS记账服务器可以作为代理将请求转发到其他记账服务器。

●网络安全客户端和RADIUS记账服务器之间的事务使用一个从来不在网络中传递的共享密钥进行认证。

●可扩展协议所有的事务都由（属性，长度，值）三部分组成。

实现时添加新的属性不会影响已有属性。

1.1. 需求描述以下关键字在RFC 2119中描述。

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"。

rfc相关设置及使用RFC（Request for Comments）是一种用于定义互联网协议、标准和相关问题的文档。

RFC的格式由互联网工程任务组（IETF）统一规定，它们记录了网络技术的发展和演进过程。

在本文中，我们将介绍RFC相关的设置和使用。

1. 了解RFC的作用和历史：RFC是由IETF组织制定的一种标准化文档，它记录了互联网协议的设计、开发和演化过程。

RFC起源于20世纪60年代的ARPANET，是一种社区驱动的文档，通过共享和讨论来推动互联网技术的发展。

RFC文档旨在提供指南、建议和最佳实践，帮助网络技术人员解决问题。

2. 寻找和阅读RFC文档：RFC文档可以在互联网上免费获取，IETF的官方网站和其他资源库都有存档。

这些文档按照顺序编号，并且以RFC开头，比如RFC 791定义了IPv4协议。

通过搜索引擎或在IETF网站上使用关键词搜索，可以找到特定主题的RFC文档。

阅读RFC文档时，应该注意文档的状态，有一些可能已经被更新或废弃。

3. 使用RFC文档：RFC文档在网络技术的发展过程中起着重要的指导作用。

它们提供了协议规范、算法实现、安全性和隐私等方面的建议。

网络管理员、网络工程师和开发人员可以使用RFC文档来了解和理解特定协议或标准的设计原理和要求。

此外，RFC文档还常用于进行互联网协议的实现、编程和配置。

4. 参与RFC的制定过程：RFC并不是静止的文件，而是一个持续演进的过程。

任何人都可以参与到RFC的制定过程中。

要参与RFC的制定，可以加入IETF并参与相关的工作组或邮件列表。

通过这种方式，个人可以提出改进建议，参与讨论和标准化的制定。

5. 遵循RFC的指导原则：在网络技术领域，遵循RFC的指导原则是至关重要的。

这些指导原则包括设计原则、协议分层、安全性和互操作性等要求。

遵循RFC的指导原则可以确保网络协议的正确性、稳定性和可靠性，同时也可以促进网络技术的发展和创新。

总结起来，RFC在互联网技术领域起着重要的作用，它们记录了互联网协议的发展历程和指导原则。

Network Working Group P. Koch Request for Comments: 3123 Universitaet Bielefeld Category: Experimental June 2001 A DNS RR Type for Lists of Address Prefixes (APL RR)Status of this MemoThis memo defines an Experimental Protocol for the Internetcommunity. It does not specify an Internet standard of any kind.Discussion and suggestions for improvement are requested.Distribution of this memo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2001). All Rights Reserved. AbstractThe Domain Name System (DNS) is primarily used to translate domainnames into IPv4 addresses using A RRs (Resource Records). Severalapproaches exist to describe networks or address ranges. Thisdocument specifies a new DNS RR type "APL" for address prefix lists.1. Conventions used in this documentThe 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].Domain names herein are for explanatory purposes only and should not be expected to lead to useful information in real life [RFC2606].2. BackgroundThe Domain Name System [RFC1034], [RFC1035] provides a mechanism toassociate addresses and other Internet infrastructure elements withhierarchically built domain names. Various types of resource records have been defined, especially those for IPv4 and IPv6 [RFC2874]addresses. In [RFC1101] a method is described to publish information about the address space allocated to an organisation. In older BIND versions, a weak form of controlling access to zone data wasimplemented using TXT RRs describing address ranges.This document specifies a new RR type for address prefix lists.Koch Experimental [Page 1]3. APL RR TypeAn APL record has the DNS type of "APL" and a numeric value of 42[IANA]. The APL RR is defined in the IN class only. APL RRs causeno additional section processing.4. APL RDATA formatThe RDATA section consists of zero or more items (<apitem>) of theform+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | ADDRESSFAMILY | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | PREFIX | N | AFDLENGTH | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ / AFDPART / | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ ADDRESSFAMILY 16 bit unsigned value as assigned by IANA(see IANA Considerations)PREFIX 8 bit unsigned binary coded prefix length.Upper and lower bounds and interpretation ofthis value are address family specific.N negation flag, indicates the presence of the"!" character in the textual format. It hasthe value "1" if the "!" was given, "0" else.AFDLENGTH length in octets of the following addressfamily dependent part (7 bit unsigned).AFDPART address family dependent part. See below.This document defines the AFDPARTs for address families 1 (IPv4) and 2 (IPv6). Future revisions may deal with additional addressfamilies.4.1. AFDPART for IPv4The encoding of an IPv4 address (address family 1) follows theencoding specified for the A RR by [RFC1035], section 3.4.1.PREFIX specifies the number of bits of the IPv4 address starting atthe most significant bit. Legal values range from 0 to 32.Trailing zero octets do not bear any information (e.g., there is nosemantic difference between 10.0.0.0/16 and 10/16) in an addressprefix, so the shortest possible AFDLENGTH can be used to encode it. However, for DNSSEC [RFC2535] a single wire encoding must be used by Koch Experimental [Page 2]all. Therefore the sender MUST NOT include trailing zero octets inthe AFDPART regardless of the value of PREFIX. This includes casesin which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits to match a full octet boundary.An IPv4 AFDPART has a variable length of 0 to 4 octets.4.2. AFDPART for IPv6The 128 bit IPv6 address (address family 2) is encoded in networkbyte order (high-order byte first).PREFIX specifies the number of bits of the IPv6 address starting atthe most significant bit. Legal values range from 0 to 128.With the same reasoning as in 4.1 above, the sender MUST NOT include trailing zero octets in the AFDPART regardless of the value ofPREFIX. This includes cases in which AFDLENGTH times 8 results in a value less than PREFIX. The AFDPART is padded with zero bits tomatch a full octet boundary.An IPv6 AFDPART has a variable length of 0 to 16 octets.5. Zone File SyntaxThe textual representation of an APL RR in a DNS zone file is asfollows:<owner> IN <TTL> APL {[!]afi:address/prefix}*The data consists of zero or more strings of the address familyindicator <afi>, immediately followed by a colon ":", an address,immediately followed by the "/" character, immediately followed by a decimal numeric value for the prefix length. Any such string may be preceded by a "!" character. The strings are separated bywhitespace. The <afi> is the decimal numeric value of thatparticular address family.5.1. Textual Representation of IPv4 AddressesAn IPv4 address in the <address> part of an <apitem> is in dottedquad notation, just as in an A RR. The <prefix> has values from the interval 0..32 (decimal).Koch Experimental [Page 3]5.2. Textual Representation of IPv6 AddressesThe representation of an IPv6 address in the <address> part of an<apitem> follows [RFC2373], section 2.2. Legal values for <prefix>are from the interval 0..128 (decimal).6. APL RR usageAn APL RR with empty RDATA is valid and implements an empty list.Multiple occurrences of the same <apitem> in a single APL RR areallowed and MUST NOT be merged by a DNS server or resolver.<apitems> MUST be kept in order and MUST NOT be rearranged oraggregated.A single APL RR may contain <apitems> belonging to different address families. The maximum number of <apitems> is upper bounded by theavailable RDATA space.RRSets consisting of more than one APL RR are legal but theinterpretation is left to the particular application.7. Applicability StatementThe APL RR defines a framework without specifying any particularmeaning for the list of prefixes. It is expected that APL RRs willbe used in different application scenarios which have to bedocumented separately. Those scenarios may be distinguished bycharacteristic prefixes placed in front of the DNS owner name.An APL application specification MUST include information ono the characteristic prefix, if anyo how to interpret APL RRSets consisting of more than one RRo how to interpret an empty APL RRo which address families are expected to appear in the APL RRs forthat applicationo how to deal with APL RR list elements which belong to otheraddress families, including those not yet definedo the exact semantics of list elements negated by the "!" character Koch Experimental [Page 4]Possible applications include the publication of address rangessimilar to [RFC1101], description of zones built following [RFC2317] and in-band access control to limit general access or zone transfer(AXFR) availability for zone data held in DNS servers.The specification of particular application scenarios is out of thescope of this document.8. ExamplesThe following examples only illustrate some of the possible usagesoutlined in the previous section. None of those applications arehereby specified nor is it implied that any particular APL RR basedapplication does exist now or will exist in the future.; RFC 1101-like announcement of address ranges for foo.examplefoo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28; CIDR blocks covered by classless delegation42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26 1:192.168.42.128/25 ); Zone transfer restriction_axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22; List of address ranges for multicastmulticast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8 Note that since trailing zeroes are ignored in the first APL RR theAFDLENGTH of both <apitems> is three.9. Security ConsiderationsAny information obtained from the DNS should be regarded as unsafeunless techniques specified in [RFC2535] or [RFC2845] were used. The definition of a new RR type does not introduce security problems into the DNS, but usage of information made available by APL RRs maycompromise security. This includes disclosure of network topologyinformation and in particular the use of APL RRs to construct access control lists.Koch Experimental [Page 5]10. IANA ConsiderationsThis section is to be interpreted as following [RFC2434].This document does not define any new namespaces. It uses the 16 bit identifiers for address families maintained by IANA in/numbers.html.The IANA assigned numeric RR type value 42 for APL [IANA].11. AcknowledgementsThe author would like to thank Mark Andrews, Olafur Gudmundsson, EdLewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review and constructive comments.12. References[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.[RFC1035] Mockapetris, P., "Domain Names - Implementation andSpecification", STD 13, RFC 1035, November 1987.[RFC1101] Mockapetris, P., "DNS Encoding of Network Names and OtherTypes", RFC 1101, April 1989.[RFC2119] Bradner, S., "Key words for use in RFCs to IndicateRequirement Levels", BCP 14, RFC 2119, March 1997.[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNSSpecification", RFC 2181, July 1997.[RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.[RFC2373] Hinden, R. and S. Deering, "IP Version 6 AddressingArchitecture", RFC 2373, July 1998.[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing anIANA Considerations Section in RFCs", BCP 26, RFC 2434,October 1998.[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.Koch Experimental [Page 6][RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to SupportIPv6 Address Aggregation and Renumbering", RFC 2874, July2000.[IANA] /assignments/dns-parameters13. Author’s AddressPeter KochUniversitaet BielefeldTechnische FakultaetD-33594 BielefeldGermanyPhone: +49 521 106 2902EMail: pk@TechFak.Uni-Bielefeld.DEKoch Experimental [Page 7]14. Full Copyright StatementCopyright (C) The Internet Society (2001). All Rights Reserved.This document and translations of it may be copied and furnished toothers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removingthe copyright notice or references to the Internet Society or otherInternet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not berevoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERINGTASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Koch Experimental [Page 8]。

HTTP常见状态码详细解析HTTP状态码（英语：HTTP Status Code）是⽤以表⽰⽹页服务器超⽂本传输协议响应状态的3位数字代码。

它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。

HTTP状态码负责表⽰客户端HTTP请求的返回结果、标记服务端的处理是否正常、通知出现的错误等⼯作。

状态码的类别的由三位数字和原因短语组成，数字的第⼀位数字表⽰响应的类别，后⾯两位⽆类别。

以下有五种类别。

另外只要遵循状态码类别的定义，即使改变RFC2616中定义的状态码，或者服务端⾃⾏创建状态码都可以。

1XX类别：informational 信息性状态码原因短语：接收的请求正在处理2XX类别：success 成功状态码原因短语：请求正常处理完毕3XX类别：redirection 重定向状态码原因短语：需要进⾏附加操作以完成请求4XX类别：client error 客户端错误状态码原因短语：服务器⽆法处理请求5XX类别：server error 服务器错误状态码原因短语：服务器处理请求出错在RFC2616上的http状态码达到40多种，在加上WEBDAV和附加HTTP状态码（RFC6585）等扩展，就有60多种，但常⽤的有以下这些，接下来让我们分别来学习下。

（注：以下的使⽤场景只是举例，不包括所有使⽤场景）1xx Informational 信息响应1XX 是信息响应，表⽰接收的请求正在被处理。

100 Continue （继续）响应结果：信息型状态响应码表⽰⽬前为⽌⼀切正常, 客户端应该继续请求, 如果已完成请求则忽略.使⽤场景：为了让服务器检查请求的⾸部, 客户端必须在发送请求实体前, 在初始化请求中发送 Expect: 100-continue ⾸部并接收 100 Continue 响应状态码.101 Switching Protocols （协议切换）响应结果：表⽰服务器应客户端升级协议的请求（Upgrade请求头）正在进⾏协议切换。

rfc中常用的测试协议引言在计算机网络领域中，为了确保网络协议的正确性和稳定性，测试协议起到了至关重要的作用。

RFC（Request for Comments）是一系列文件，用于描述互联网相关协议、过程和技术。

在RFC中，也包含了一些常用的测试协议，用于验证和评估网络协议的功能和性能。

本文将介绍RFC中常用的测试协议，并深入探讨其原理和应用。

二级标题1：PING协议三级标题1.1：概述PING协议是一种常用的网络测试协议，用于测试主机之间的连通性。

它基于ICMP （Internet Control Message Protocol）协议，通过发送ICMP Echo Request报文并等待目标主机的ICMP Echo Reply报文来判断目标主机是否可达。

三级标题1.2：工作原理PING协议的工作原理如下： 1. 发送方主机生成一个ICMP Echo Request报文，并将目标主机的IP地址作为目的地。

2. 发送方主机将报文发送到网络中。

3.中间路由器收到报文后，将报文转发到下一跳路由器。

4. 目标主机收到ICMP Echo Request报文后，生成一个ICMP Echo Reply报文，并将其发送回发送方主机。

5. 发送方主机收到ICMP Echo Reply报文后，通过比较报文中的标识符和序列号等字段，判断目标主机是否可达。

三级标题1.3：应用场景PING协议在网络中的应用非常广泛，常用于以下场景： - 测试主机之间的连通性，判断网络是否正常工作。

- 测试网络延迟，通过计算ICMP Echo Request报文的往返时间来评估网络质量。

- 排查网络故障，通过检查ICMP Echo Reply报文中的错误码来定位故障原因。

二级标题2：Traceroute协议三级标题2.1：概述Traceroute协议用于跟踪数据包从源主机到目标主机经过的路径。

它通过发送一系列的UDP报文，并在每个报文中设置不同的TTL（Time to Live）值来实现。

Session Initiation Protocol (SIP):SIP服务器定位本文档状态本文档为Internet 团体定义了一个Internet standards track协议。

并且请求对这个文档进行讨论以便改进。

请参阅当前版本的”InternetOfficalProtocol Stands”(STD1)来确认本文档的标准化状态以及本协议的状态。

对本文档的发布是没有限制的。

版本信息Copyright （C）The Internet Society(2002). All Rights Reserved.概述SIP协议使用了DNS步骤来使得客户端能够把一个标准的SIP格式的资源（SIP URI）解析成为IP地址，端口，以及使用的协议。

同样SIP也支持服务端在客户端的主机失效的情况下使用DNS来向备份的客户端发送应答。

本文档描述了这些DNS的详细过程。

1．介绍SIP（RFC3261）是一个客户端/服务端的协议，它用来创建用户之间的通讯会话和管理用户之间的通讯会话的。

SIP 的终端系统叫做UA（用户代理），中间的结点叫做proxy 服务器。

一个典型的SIP配置，叫做一个SIP”梯形”,就像在图1中表示的一样。

在这个图中，呼叫方在domain A(UA1),希望呼叫在domain B的用户Joe(Joe@b)。

为了完成这个呼叫，他首先和在自己域内部的proxy1（domain A中的proxy 1）。

Proxy1向被叫方域的proxy 服务器（proxy2）转发这个请求。

Proxy2转发这个请求到被叫方，UA2。

作为呼叫流的一部分，proxy1需要确定domain B的SIP服务器。

为了能够确定这个，proxy1 使用DNS的步骤，使用SRV[2]和NAPTR[3]记录来确定这个地址。

本文档描述了SIP使用DNS的相关问题，并且提供了解决方法。

2．DNS需要解决的相关问题为了能够解决上边介绍的一般呼叫流所需要确定的呼叫双方两方面的问题，我们需要使用DNS。