I am active participant in the Internet Engineering Task Force (IETF), where I help develop security standards for the Internet. My work in the Internet community started in the mid-1980's as a member of the Privacy and Security Research Group (PSRG), which developed the Privacy Enhanced Mail (PEM) specifications, the first electronic mail security solution for Internet mail protocols. The PSRG also developed the first Internet Public Key Infrastructure (PKI) specifications, which were based on X.509 version 1.

I served as chair of the S/MIME Working Group from the time the working group was formed until March 2003. S/MIME is a set of electronic mail security standards. I continue to support the S/MIME effort as the editor of the Cryptographic Message Syntax (CMS) specification.

I served as editor and contributor in the Public Key Infrastructure using X.509 (PKIX) Working Group, which defined the Internet PKI based on X.509 version 3.

From March 2003 to March 2007, I served as the one of the IETF Security Area Directors. In this position, I was able to help improve the security of the Internet by helping many different working groups achieve their security objectives, but I had less time to contribute to individual standards.

From March 2007 to March 2013, I served as IETF Chair. In this position, I was able to help many different working groups throughout the IETF, and I am able to support incremental improvement of the IETF standards development process.

From March 2007 to March 2017, I served as a member of the Internet Architecture Board (IAB). In this position, I was able to provide architectural oversight for Internet protocols and procedures, provides liaison support on behalf of the IETF, review appeals of the Internet standards process, provide oversight of the RFC series and protocol parameter value assignment by IANA, and provide technical advice to the Internet Society. From March 2013 to March 2015, served as chair of the IAB.

From May 2013 to March 2017, I served on the Internet Research Steering Group (IRSG).

I am serving as STIR WG Chair since August 2013. The Working Group is specifying Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number. Confidence in the authenticity of the source of a telephone call in an important mechanism in combating RoboCalling.

I am serving as LAMPS WG Chair since July 2016. The Working Group is developing limited additional mechanisms for PKIX and S/MIME, with a focus on updates where there is a known constituency interested in real deployment.

I am serving as SUIT WG Chair since December 2017. The Working Group is defining a secure firmware update solution that will be usable on Class 1 devices (as defined in RFC 7228).

I am serving as SIDRops WG Chair since December 2022. The Working Group is responsible for encouraging deployment of the security technologies for Internet Domain Routing (IDR), and deployment of these security technologies must avoid the division of the Internet into separate networks.

The various IETF leadership positions leave less time to contribute to individual standards. However, these standards are very important to me, so I find time to work on them.

S/MIME

The S/MIME Working Group is closed. The S/MIME electronic mail security protocol is widely implemented in commercial mail agents. I authored several of the specifications. Maintenance work is happening in the CURDLE Working Group and the LAMPS Working Group.

RFCs

RFC 5652    This Standards-track RFC specifies the Cryptographic Message Syntax (CMS), which is used in S/MIME and other security protocols. It replaces three earlier versions: RFC 2630, RFC 3369, and RFC 3852.

RFC 3370    This Standards-track RFC specifies the conventions for using several popular cryptographic algorithms with CMS. The algorithm conventions are in a separate document so that they can be updated without making any changes to the CMS specification.

RFC 3217    This Informational RFC describes the encryption of one Triple-DES key with another Triple-DES key as well as the encryption of one RC2 key with another RC2 key. Key wrapping is needed when Diffie-Hellman key management is used to send the same encrypted message content to more than one recipient.

RFC 3394    This Informational RFC describes conventions for the encryption of one AES key with another AES key. The AES Key Wrap algorithm was originally published by NIST, and NIST will probably make it a standard soon. This document makes the algorithm readily available to the Internet community.

RFC 3537    This Standards-track RFC specifies the conventions for the encryption of an HMAC key with a Triple-DES key or an AES key.

RFC 3560    This Standards-track RFC specifies the conventions for using the RSAES-OAEP key transport algorithm in CMS. It supplements RFC 3370.

RFC 4073    This Standards-track RFC describes a convention for using the CMS to protect a content collection. If desired, attributes can be associated with the content.

RFC 4853    This Standards Track RFC updates the Cryptographic Message Syntax (CMS), which is published in RFC 3852. This document clarifies the proper handling of the SignedData protected content type when more than one digital signature is present.

RFC 5083    This Standards-track RFC describes an additional content type for the Cryptographic Message Syntax (CMS). The authenticated-enveloped-data content type is intended for use with authenticated encryption modes. All of the various key management techniques that are supported in the CMS enveloped-data content type are also supported by the CMS authenticated-enveloped-data content type.

RFC 5084    This Standards-track RFC specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the Cryptographic Message Syntax (CMS) authenticated-enveloped-data content type, which is specified in RFC 5083.

RFC 7107    This Informational RFC describes the object identifiers that were assigned for the S/MIME Mail Security Working Group. When the S/MIME Mail Security Working Group was chartered, an object identifier arc was donated by RSA Data Security for use by that working group. This document describes the object identifiers that were assigned in that donated arc, transfers control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc.

RFC 8103    This Standards Track RFC describes the conventions for using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic Message Syntax (CMS) (see RFC 5652). ChaCha20-Poly1305 is an authenticated encryption algorithm constructed of the ChaCha stream cipher and Poly1305 authenticator (see RFC 7539).

RFC 8418    This Standards Track RFC describes the conventions for using the Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm with curve25519 and curve448 in the Cryptographic Message Syntax (CMS) (see RFC 5652).

RFC 8419    This Standards Track RFC specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS) (see RFC 5652).

RFC 8591    This Standards Track RFC offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using S/MIME version 4.0 (see RFC 8550 and RFC 8551) for instant messages using the Session Initiation Protocol (SIP) MESSAGE method (see RFC 3428) and the Message Session Relay Protocol (MSRP) (see RFC 4975).

RFC 8619    This Standards Track RFC assigns algorithm identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) when used with three common one-way hash functions. (See RFC 5869 for the HKDF algorithm specification).

RFC 8696    The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) (see RFC 5652) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support them, if current syntax the does not accommodated them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key.

RFC 8708    This Standards Track RFC specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the Cryptographic Message Syntax (CMS) (see RFC 5652). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.

RFC 8933    This document updates the Cryptographic Message Syntax (CMS) specified in RFC 5652 to ensure that algorithm identifiers in signed-data and authenticated-data content types are adequately protected.

RFC 9044    This Standards Track RFC specifies the conventions for using the AES-GMAC Message Authentication Code algorithm with the Cryptographic Message Syntax (CMS) (see RFC 5652).

PKIX

The PKIX Working Group is closed. It developed many standards for the Internet PKI. I was very active in this working group since it began, and I have co-authored several of the key documents. Maintenance work is happening in the CURDLE Working Group and the LAMPS Working Group.

RFCs

RFC 5280    This Standards-track RFC specifies Internet PKI profile for X.509 certificates and certificate revocation lists (CRLs). It replaces earlier versions that were published as RFC 2459 and RFC 3280.

RFC 3279    This Standards-track RFC specifies the conventions for using several popular cryptographic algorithms with the certificate and CRL profile. The algorithm conventions are in a separate document so that they can be updated without making any changes to the profile. It includes conventions that were previously published in RFC 2528.

RFC 5755    This Standards-track RFC specifies Internet PKI profile for X.509 attribute certificates. The use of attribute certificate chains is prohibited. The attribute certificates are always issued directly by a trusted attribute authority. It replaces an earlier version that was published as RFC 3281.

RFC 2585    This Standards-track RFC specifies Internet PKI conventions for fetching X.509 certificates and CRLs using HTTP and FTP.

RFC 3379    This Informational RFC specifies the PKIX Working Group requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) protocols. These requirements are being used as criteria to judge several competing proposals.

RFC 3709    This Standards-track RFC specifies a certificate extension for including logos in public key certificates and attribute certificates. It supplements RFC 3280.

RFC 3874    This Informational RFC specifies a 224-bit one-way hash function, called SHA-224. SHA-224 is based on SHA-256, but it uses a different initial value and the result is truncated to 224 bits.

RFC 4055    This Standards-track RFC supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm.

RFC 4325    This Standards-track RFC updates RFC 3280 by defining the Authority Information Access Certificate Revocation Lists (CRL) extension. RFC 3280 defines the Authority Information Access certificate extension using the same syntax. The CRL extension provides a means of discovering and retrieving CRL issuer certificates.

RFC 4334    This Standards-track RFC defines two EAP extended key usage values and a public key certificate extension to carry Wireless LAN (WLAN) System Service identifiers (SSIDs). It supplements RFC 3280, and it obsoletes RFC 3770.

RFC 4630    This Standards-track RFC updates the handling of DirectoryString in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding. The requirement for exclusive use of UTF8String after December 31, 2003 is removed.

RFC 5055    This Standards-track RFC specifies the Simple Certificate Validation Protocol (SCVP). It meets the Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) protocol requirements specified in RFC 3379.

RFC 5480    This Standards-track RFC specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates RFC 3279.

RFC 5756    This Standards-track RFC updates the conventions for using the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Specifically, it updates the conventions for algorithm parameters in an X.509 certificate's subjectPublicKeyInfo field. This document updates RFC 4055.

RFC 5877    This Informational RFC specifies the MIME media type used to carry a single attribute certificate. Attribute certificates are discussed in RFC 5755.

RFC 5914    This Standards Track RFC specifies a structure for representing trust anchor information. A trust anchor is an authoritative entity represented via a public key and associated data. The public key is used to verify digital signatures and the associated data is used to constrain the types of information or actions for which the trust anchor is authoritative. The structures defined in this document are intended to satisfy the format-related requirements defined in Trust Anchor Management Requirements and for use within the context of the Trust Anchor Management Protocol (TAMP).

RFC 5934    This Standards Track RFC specifies a transport independent protocol for the management of trust anchors and community identifiers stored in a trust anchor store. The protocol makes use of the Cryptographic Message Syntax (CMS), and a digital signature is used to provide integrity protection and data origin authentication. The protocol can be used to manage trust anchor stores containing trust anchors represented as Certificate, TBSCertificate, or TrustAnchorInfo objects.

RFC 6010    This Standards Track RFC specifies the syntax and semantics for the Cryptographic Message Syntax (CMS) content constraints X.509 certificate extension. This extension is used to determine whether the public key in an X.509 public key certificate is appropriate to use in the processing of a protected content. In particular, the CMS content constraints certificate extension is one part of the authorization decision; it is used when validating a digital signature on a CMS SignedData content or validating a message authentication code (MAC) on a CMS AuthenticatedData content or CMS AuthEnvelopedData content. The signed or authenticated content type is identified by an ASN.1 object identifier, and this certificate extension indicates the content types that the certified public key is authorized to validate. If the authorization check is successful, the CMS content constraints certificate extension also provides default values for absent attributes.

RFC 6170    This Standards Track RFC specifies a method to bind a visual representation of a certificate in the form of a certificate image to a public key certificate as defined in RFC 5280, by defining a new "otherLogos" image type according to RFC 3709.

RFC 7229    This Informational RFC provides several certificate policy identifiers for testing certificate handling software.

RFC 7299    When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, it returns control of that arc to IANA, and it establishes IANA allocation policies for any future assignments within that arc.

RFC 8649    This Informational RFC specifies the Hash Of Root Key certificate extension. This certificate extension is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate. This certificate extension unambiguously identifies the next public key that will be used at some point in the future as the next Root CA certificate, eventually replacing the current one.

RFC 9045    This Standards Track RFC provides updates to the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) (see RFC 4211). The algorithms specified in RFC 4211 were appropriate in 2005; however, these algorithms are no longer considered the best choices.

RFC 9158    This Informational RFC updates to RFC 7299, which describes the object identifiers that were assigned by the PKIX Working Group in an arc that was allocated by IANA (1.3.6.1.5.5.7). A small number of object identifiers that were assigned in RFC 4212 are omitted from RFC 7299, and this document updates RFC 7299 to correct that oversight.

RFC 9310    This Standards Track RFC specifies the certificate extension for including Network Function Types (NFTypes) for the 5G System in X.509 v3 public key certificates as profiled in RFC 5280.

RFC 9399    This Standards Track RFC specifies a certificate extension for including logotypes in public key certificates and attribute certificates. This document obsoletes RFC 3709 and RFC 6170.

RFC 9549    This Standards Track RFC provides updates to RFC 5280 for alignment with the 2008 specification for Internationalized Domain Names (IDNs) and add support for Internationalized Email Addresses in X.509 Certificates. IDNs in certificates must be in ACE-encoded form. That is, all U-labels within an IDN are converted to A-labels as specified in RFC 5891. It replaces an earlier version that was published as RFC 8399.

TLS

The Transport Layer Security (TLS) Working Group is developing standards for the session-oriented security with the TLS protocol and connectionless security with the DTLS protocol.

RFCs

RFC 5878    This Experimental RFC specifies authorization extensions to the Transport Layer Security (TLS) Handshake Protocol. Extensions are carried in the client and server hello messages to confirm that both parties support the desired authorization data types. Then, if supported by both the client and the server, authorization information, such as attribute certificates (ACs) or Security Assertion Markup Language (SAML) assertions, is exchanged in the supplemental data handshake message.

RFC 6460    The United States Government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This Historic RFC defines a profile of TLS which is conformant with Suite B. This RFC obsoletes RFC 5430.

RFC 8773    This Experimental RFC specifies a TLS 1.3 (see RFC 8446) extension that allows a server to authenticate with a combination of a certificate and an external pre-shared key (PSK).

RFC 9257    This Informational RFC provides usage guidance for external Pre-Shared Keys (PSKs) in TLS 1.3 (see RFC 8446). The document provides the security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. The document also discusses PSK use cases and provisioning processes. Finally, the document lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used.

IPsec

The IPsec Working Group has closed. It developed standards for Internet Protocol (IP) security. The IPsecME Working Group is developing further standards in this area.

RFCs

RFC 3686    This Standards-track RFC describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.

RFC 4309    This Standards-track RFC describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) version 3 confidentiality mechanism. CCM Mode uses a combination of AES Counter Mode and AES CBC-MAC to provide both confidentiality and integrity. RFC 3610 describes AES CCM Mode.

STIR

The Secure Telephone Identity Revisited (STIR) Working Group is developing standards for Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. RFC 7340 provides the Secure Telephone Identity problem statement, and it lists the requirements that a solution must provide.

RFCs

RFC 9118    This Standards-track RFC updates and earlier specification for the use of certificates for Secure Telephone Identity Credentials. RFC 8226 provides a certificate extension to constrain the JSON Web Token (JWT) claims that can be included in the Personal Assertion Token (PASSporT), as defined in RFC 8225. This update provides all of the capabilities available in the original certificate extension as well as an additional way to constrain the allowable JWT claims. The enhanced extension can also provide a list of claims that are not allowed to be included in the PASSporT.

COSE

The CBOR Object Signing and Encryption (COSE) Working Group is developing standards for digital signature and encryption for applications that make use of the Concise Binary Object Representation (CBOR), which is specified in RFC 7049.

RFCs

RFC 8778    This Standards-track RFC specifies the conventions for using the Hierarchical Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based signature algorithm with the CBOR Object Signing and Encryption (COSE) syntax. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554.

RFC 9459    This Standards-track RFC specifies the conventions for using the AES-CTR and AES-CBC encryption algorithms with the CBOR Object Signing and Encryption (COSE) syntax, which is specified in RFC 9052. In most use cases, COSE uses Authenticated Encryption with Associated Data (AEAD) algorithms, which provide both confidentiality and integrity protection. However, there are situations where another mechanism, such as a digital signature, is used to provide integrity. In these use cases, an AEAD algorithm is not needed, and AES-CTR or AES-CBC might be appropriate.

Other

I have published several other documents. These are not associated with the effort of any particular IETF working group.

RFCs

RFC 1457    This Informational RFC presents a security labeling framework for the Internet. The framework is intended to help protocol designers determine what, if any, security labeling should be supported by their protocols. The framework should also help network architects determine whether or not a particular collection of protocols fulfill their security labeling requirements.

RFC 2773    This Experimental RFC defines a method to encrypt a file transfer using FTP. This method uses the Key Exchange Algorithm (KEA) to give mutual authentication and establish the data encryption keys. SKIPJACK is used to encrypt file data and the FTP command channel.

RFC 2943    This Standards-track RFC defines a TELNET authentication mechanism using the Digital Signature Algorithm (DSA). It relies on the Telnet Authentication Option specified in RFC 2941.

RFC 2951    This Informational RFC defines a method to authenticate TELNET using the Key Exchange Algorithm (KEA), and encryption of the TELNET stream using SKIPJACK. Two encryption modes are specified; one provides data integrity and the other does not. It relies on the Telnet Authentication Option specified in RFC 2941.

RFC 3378    This Informational RFC describes the EtherIP protocol, an early tunneling protocol. It provides informational and historical context for the assignment of IP protocol 97. EtherIP tunnels Ethernet and IEEE 802.3 media access control frames in IP datagrams so that non-IP traffic can traverse an IP internet. The protocol is very lightweight, and it does not provide protection against infinite loops.

RFC 3610    This Informational RFC describes AES CCM Mode. This cryptographic mode provides both confidentiality and integrity. AES CCM Mode is used by IEEE 802.11i; it can also be used with IPsec ESPv3.

RFC 4073    This Standards-track RFC describes the use of the Cryptographic Message Syntax (CMS) to protect more than one content. It also describes a way to bind attributes to a particular content. When CMS is used with MIME, there is no need to use this specification. However, this specification is needed when CMS is used in a solely ASN.1 environment.

RFC 4107    This document is also known as BCP 107, and it provides guidance about key management. In most security systems, automated key management is necessary for interoperability, scalability, and security; however, there are some security systems where manual keying is sufficient. This document provides guidelines for selecting the appropriate key management approach.

RFC 4108    This Standards-track RFC describes the use of the Cryptographic Message Syntax (CMS) to protect firmware packages. A digital signature is used to protect the firmware package from undetected modification and provide data origin authentication. Encryption is optionally used to protect the firmware package from disclosure.

RFC 4705    This Informational RFC describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio link products. The security solution is documented in the hope that other wireless product development efforts will include comparable capabilities.

RFC 4962    This document is also known as BCP 132, and it provides guidance to designers of Authentication, Authorization, and Accounting (AAA) key management protocols. The guidance is also useful to designers of systems and solutions that include AAA key management protocols. Given the complexity and difficulty in designing secure, long-lasting key management algorithms and protocols by experts in the field, it is almost certainly inappropriate for IETF working groups without deep expertise in the area to be designing their own key management algorithms and protocols based on Authentication, Authorization, and Accounting (AAA) protocols. The guidelines in this document apply to documents requesting publication as IETF RFCs. Further, these guidelines will be useful to other standards development organizations (SDOs) that specify AAA key management.

RFC 5485    This Informational RFC specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature.

RFC 5649    This Informational RFC specifies a padding convention for use with the AES Key Wrap algorithm specified in RFC 3394. This convention eliminates the requirement that the length of the key to be wrapped is a multiple of 64 bits, allowing a key of any practical length to be wrapped.

RFC 5742    This Best Current Practice RFC describes the procedures used by the IESG for handling documents submitted for RFC publication on the Independent and IRTF streams. This document updates the procedures described in RFC 2026 and RFC 3710.

RFC 5781    This Informational RFC describes the URI (Uniform Resource Identifier) scheme for rsync utility, which provides fast incremental file transfer.

RFC 5940    The Cryptographic Message Syntax (CMS) allows revocation information to be conveyed as part of the SignedData, EnvelopedData, AuthenticatedData, and AuthEnvelopedData content types. The preferred format for revocation information is the Certificate Revocation List (CRL), but an extension mechanism supports other revocation information choices. This document defines two additional revocation information formats for Online Certificate Status Protocol (OCSP) responses and Server-Based Certificate Validation Protocol (SCVP).

RFC 6019    This Standards Track RFC specifies an ASN.1 type for representing time: BinaryTime. This document also specifies an alternate to the signing-time attribute for use with the Cryptographic Message Syntax (CMS) SignedData and AuthenticatedData content types; the binary-signing-time attribute uses BinaryTime. CMS and the signing-time attribute are defined in RFC 5652. This Standards Track RFC obsoletes the earlier Experimental RFC 4049, which contains essentially the same specification.

RFC 6031    This Standards Track RFC defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (CMS) can be used to digitally sign, digest, authenticate, or encrypt this content type. CMS is defined in RFC 5652.

RFC 6032    This Standards Track RFC defines the Cryptographic Message Syntax (CMS) encrypted key package content type, which can be used to encrypt a content that includes a key package, such as a symmetric key package or an asymmetric key package. It is transport independent. It is designed to be used with the CMS Content Constraints (CCC) extension as defined in RFC 6010, which does not constrain the EncryptedData, EnvelopedData, and AuthEnvelopedData. CMS can be used to digitally sign, digest, authenticate, or further encrypt this content type. CMS is defined in RFC 5652.

RFC 6318    This Historic RFC specifies the conventions for using the United States National Security Agency's Suite B algorithms in Secure/Multipurpose Internet Mail Extensions (S/MIME) as specified in RFC 3851. This document obsoletes RFC 5008.

RFC 6360    This Informational RFC concludes the For Your Information (FYI) sub-series of RFCs, established by RFC 1150 for use by the IETF User Services Area, which no longer exists. The IESG does not intend to make any further additions to this RFC sub-series, and this document provides a record of this decision.

RFC 6410    This RFC is part of BCP 9. This RFC updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two.

RFC 6852    On 29 August 2012, the leaders of the IEEE Standards Association, the IAB, the IETF, the Internet Society, and the W3C signed a statement affirming the importance of a jointly developed set of principles establishing a modern paradigm for global, open standards. These principles have become known as the "OpenStand" principles. This document contains the text of the affirmation that was signed.

RFC 7020    This Informational RFC replaces RFC 2050, and it provides information about the current Internet Numbers Registry System used in the distribution of globally unique Internet Protocol (IP) address space and autonomous system (AS) numbers. Note that this document does not propose any changes to the Internet Numbers Registry System.

RFC 7036    This Informational RFC describes the object identifiers that were assigned for the Long-Term Archive and Notary Services (LTANS) working group, and it establishes IANA allocation policies for any future assignments within the LTANS object identifier arc.

RFC 7191    This Standards Track RFC defines the syntax for two Cryptographic Message Syntax (CMS) (see RFC 5652) content types, one for key package receipts, and another for key package errors. The key package receipt content type is used to confirm receipt of an identified key package or collection of key packages. The key package error content type is used to indicate an error occurred during the processing of a key package. CMS can be used to digitally sign, digest, authenticate, or encrypt these content types.

RFC 7193    This Information RFC registers the the application/cms media type for use with the corresponding Cryptographic Message Syntax (CMS) (see RFC 5652) content types.

RFC 7210    This Standards Track RFC specifies the information contained in a conceptual database of long-lived cryptographic keys used by many different security protocols. The database design supports both manual key management and automated key management. In many instances, the security protocols do not directly use the long-lived key, but rather a key derivation function is used to derive a short-lived key from a long-lived key.

RFC 7249    This Informational RFC identifies the IANA registries that are part of the Internet Numbers Registry System at the time of its publication. RFC 7020 provides information about the Internet Numbers Registry System and how it is used in the distribution of autonomous system (AS) numbers and globally unique unicast Internet Protocol (IP) address space.

RFC 7696    This document is also known as BCP 201. Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This document provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.

RFC 7760    This Informational RFC contains the Statement of Work (SOW) for extensions to the IETF Datatracker to provide statistics about RFCs and Internet-Drafts and their authors.

RFC 7906    This Informational RFC defines key management attributes used by the National Security Agency (NSA). The attributes can appear in asymmetric and/or symmetric key packages as well as the Cryptographic Message Syntax (CMS) content types that subsequently envelope the key packages. Key packages described in RFC 5958 and RFC 6031 are examples of where these attributes can be used.

RFC 7979    This Informational RFC contains the proposal that was prepared by the IANAPLAN working group regarding the protocol parameter registries and submitted to the IANA Stewardship Transition Coordination Group (ICG). This proposal was combined with proposals from the numbers community and the names community to create the final proposal that was submitted to the U.S. National Telecommunications and Information Administration (NTIA).

RFC 8090    This Informational RFC outlines the procedures by which the IETF makes appointments to the Community Coordination Group (CCG), which provides advice and guidance to the IETF Trust in matters related to the IANA trademarks and the IANA domain names. The IANA IPR Community Agreement was one of the many documents that was part of the IANA Stewardship Transition, and it calls for the creation of the CCG.

RFC 8358    This Informational RFC updates RFC 5485. When the RFC Editor published the first RFC that includes non-ASCII characters, the conventions specified in RFC 7997 were followed. We assume that non-ASCII characters will soon start appearing in Internet-Drafts as well. This document updates the handling of digital signatures on Internet-Drafts that contain non-ASCII characters in a text file.

RFC 8423    This Informational RFC reclassifies the RFCs related to the United States National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven Informational RFCs to Historic status: RFC 5759, RFC 6239, RFC 6318, RFC 6379, RFC 6380, RFC 6403, and RFC 6460. In addition, it moves three obsolete Informational RFCs to Historic status: RFC 4869, RFC 5008, and RFC 5430.

RFC 8720    This Informational RFC provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries. This document obsoletes RFC 7500.

RFC 8729    This Informational RFC describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844.

RFC 8862    This RFC is also known as BCP 228. Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities.

RFC 9169    This Informational RFC offers alternative ASN.1 modules that conform to the 2002 version of ASN.1 for the Evidence Record Syntax (ERS) specified in RFC 4998 and the evidence records in the Server-based Certificate Validation Protocol (SCVP) defined in RFC 5055. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the ASN.1 syntax.

RFC 9321    This Informational RFC specifies the Signature Validation Token (SVT). Electronic signatures have a limited lifespan with respect to the time period that they can be validated and determined to be authentic. The SVT provides evidence by a trusted authority; it asserts that an electronic signature was successfully validated according to defined procedures at a certain time. Any future validation of that electronic signature can be satisfied by validating the SVT without needing to also validate the original electronic signature or the associated digital certificates. The SVT supports electronic signatures in CMS, XML, PDF, and JSON documents.