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.
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.
In March 2013, I was elected chair of the Internet Activities Board (IAB). This position comes along with a few other responsibilities. I am a non-voting member of the Internet Engineering Steering Group (IESG), a voting member of the IETF Administrative Oversight Committee (IAOC), and a Trustee for the IETF Trust.
In May 2013, I accepted the position on the Internet Research Steering Group (IRSG).
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.
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.
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 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.
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.
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 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 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.
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.
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.
I have published several other documents. These are not associated with the effort of any particular IETF working group.
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 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 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 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 3852. 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 3852.
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 3852.
RFC 6318 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. 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 6460 The United States Government has published guidelines for "NSA Suite B Cryptography", which defines cryptographic algorithm policy for national security applications. This Informational RFC defines a profile of TLS which is conformant with Suite B. This RFC obsoletes RFC 5430.
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.
draft-ietf-karp-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-housley-ct-keypackage-receipt-n-error This draft defines the syntax for two Cryptographic Message Syntax (CMS) (see RFC 3852) 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.