Russ Housley's Participation in the IETF
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 am an editor and contributor in the Public Key Infrastructure using X.509 (PKIX) Working Group, which is defining 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 help many different working groups achieve their security objectives, but I had less time to contribute to individual standards.
In March 2007, I accepted the position of IETF Chair. In this position, I am able to help many different working groups throughout the IETF, and I am able to support incremental improvement of the IETF standards development process. The IETF Chair position leaves even less time to contribute to individual standards.
S/MIME
The S/MIME Working Group is nearly finished with its work. The S/MIME electronic mail security protocol is widely implemented in commercial mail agents. I authored several of the specifications, and I am working on some supplements.
RFCs
RFC 3852 This Standards-track RFC specifies the Cryptographic Message Syntax (CMS), which is used in S/MIME and other security protocols. It replaces two earlier versions: RFC 2630 and RFC 3369.
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.
Internet Drafts
draft-ietf-smime-cms-auth-enveloped-03 This draft describes an additional content type for the 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.
draft-ietf-smime-cms-aes-ccm-and-gcm-01 This draft specifies the conventions for using the AES-CCM and the AES-GCM authenticated encryption algorithms with the CMS authenticated-enveloped-data content type.
PKIX
The PKIX Working Group is developing standards for the Internet PKI. I have been very active in this working group since it began, and I have co-authored several of the key documents. I am working on additional documents.
RFCs
RFC 3280 This Standards-track RFC specifies Internet PKI profile for X.509 certificates and certificate revocation lists (CRLs). It replaces an earlier version which was published as RFC 2459.
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 3281 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.
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.
Internet Drafts
draft-ietf-pkix-scvp-31 This draft specifies the Simple Certificate Validation Protocol (SCVP). It meets the DPV and DPD protocol requirements specified in RFC 3379.
IPsec
The IPsec Working Group developed standards for Internet Protocol (IP) security. The IPsec Working Group has completed its work, and it has been shut down.
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.
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 ESP v3.
RFC 4049 This Experimental RFC specifies a new 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 3852.
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.
Internet Drafts
draft-housley-aaa-key-mgmt-09 This draft provides guidance to designers of 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 RFCs, as well as to use of AAA key management by any other standards development organizations (SDOs). The goal is for this draft to become a BCP.