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 helping 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 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.

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 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 document describes 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).

Internet Drafts

draft-ietf-pkix-cms-content-constraints    This document 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.

draft-ietf-pkix-tamp    This document describes 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.

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 ESPv3.

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.

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 5008    This Informational 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.

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 5430    The United States Government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This document defines a profile of TLS which is conformant with Suite B.

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 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.

Internet Drafts

draft-housley-saag-crypto-key-table This draft 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.

draft-polk-saag-rtg-auth-keytable This document describes the application of a database of long-lived cryptographic keys to establish session-specific cryptographic keys to support authentication services in routing protocols. Keys may be established between two peers for pair-wise communications, or between groups of peers for multicast traffic.

draft-turner-additional-cms-ri-choices 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).