Internet Architecture Board R. Housley
Internet-Draft Vigil Security
Intended status: Informational K. O'Donoghue
Expires: January 7, 2016 Internet Society
July 6, 2015
Problems with the Public Key Infrastructure (PKI) for the World Wide Web
draft-housley-web-pki-problems-00.txt
Abstract
This document describes the technical and non-technical problems with
the current Public Key Infrastructure (PKI) used for the World Wide
Web. Some potential technical improvements are considered, and some
non-technical approaches to improvements are discussed.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2016.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, 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 of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Housley & O'Donoghue Expires January 7, 2016 [Page 1]
Internet-Draft Web PKI Problems July 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Very Brief Description of the Web PKI . . . . . . . . . . . . 3
3. Technical Problems with the Web PKI . . . . . . . . . . . . . 3
3.1. No certificate status checking . . . . . . . . . . . . . 3
3.2. Unexpected certificates . . . . . . . . . . . . . . . . . 3
3.3. All domain names are at risk from the failure of any CA . 4
3.4. CAs issue 'full powers' to subordinate CAs . . . . . . . 4
3.5. No automation for server operators . . . . . . . . . . . 4
3.6. Attacks are not reported when they are detected . . . . . 4
3.7. Weak cryptographic algorithms or short keys . . . . . . . 5
4. Non-technical Problems with the Web PKI . . . . . . . . . . . 5
4.1. Determination of the Trusted Certificate Authorities . . 5
4.2. Dominate Certificate Authorities . . . . . . . . . . . . 6
4.3. Cost and Complexity of Deployment . . . . . . . . . . . . 6
5. Emerging Technical Improvements . . . . . . . . . . . . . . . 6
5.1. Certificate Status Checking . . . . . . . . . . . . . . . 6
5.1.1. CRL Distribution Points . . . . . . . . . . . . . . . 7
5.1.2. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 7
5.2. Leveraging the DNS . . . . . . . . . . . . . . . . . . . 8
5.2.1. DNS-Based Authentication of Named Entities (DANE) . . 8
5.2.2. Certificate Authority Authorization (CAA) . . . . . . 8
5.3. Leveraging HTTP . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. HTTP Strict Transport Security (HSTS) . . . . . . . . 9
5.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 9
5.4. Certificate Transparency . . . . . . . . . . . . . . . . 10
6. Emerging Non-technical Improvements . . . . . . . . . . . . . 10
6.1. Open and Inclusive Web PKI Forum . . . . . . . . . . . . 10
6.2. Cost Effective and Simple Deployment . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Appendix B. IAB Members at the Time of Approval . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
There are many technical and non-technical problems with the current
Public Key Infrastructure (PKI) used for the World Wide Web. This
document describes these problems, considers some potential technical
improvements, and discusses some non-technical approaches to
improvements.
Housley & O'Donoghue Expires January 7, 2016 [Page 2]
Internet-Draft Web PKI Problems July 2015
The Web PKI makes use of certificates as described in RFC 5280
[RFC5280]. These certificates are primarily used with Transport
Layer Security (TLS) RFC 5246 [RFC5246].
2. Very Brief Description of the Web PKI
These topics are to be covered in this section:
o Certificate bind a name or names to a public key
o Enrollment process makes sure:
* it is the right name
* confirms that party actually holds the private key
o Explain the entities
3. Technical Problems with the Web PKI
There are many problems with the Web PKI, and this section discusses
many of them.
3.1. No certificate status checking
Many browsers do not perform certificate status checks by default.
That is they do not check whether the issuing CA has revoked the
certificate unless the user explicitly adjusts a setting that turns
on this feature. This check can be made by fetching the most recent
certificate revocation list (CRL) RFC 5280 [RFC5280], or this check
can use the Online Certificate Status Protocol (OCSP) RFC 6960
[RFC6960]. The location of the CRL or the OCSP responder is usually
found in the certificate itself. Either one of these approaches add
latency. The desire to provide a snappy user experience is the
reason that this feature is not turned on by default.
3.2. Unexpected certificates
All of the CAs in the trust store are equally trusted for the entire
domain name space, so any CA can issue for any domain name. In fact,
the legitimate owner of the domain name might be unaware that a CA
has issued a certificate that contains their domain name. Once the
unexpected certificate is discovered, it can be very difficult to get
it revoked. Further, browsers and other relying parties cannot
distinguish a certificate that the legitimate domain name owner
requested from an unexpected one.
Housley & O'Donoghue Expires January 7, 2016 [Page 3]
Internet-Draft Web PKI Problems July 2015
3.3. All domain names are at risk from the failure of any CA
Since all of the CAs in the trust store are equally trusted, any CA
can issue a certificate for any domain name. There are known cases
where attackers have thwarted the CA protections and issued
certificates that were used to mount attacks against users of the web
sites names in the certificate [FOXIT]. For this reason, all of the
CAs listed in the trust store must be very well protected.
3.4. CAs issue 'full powers' to subordinate CAs
When a CA issues a certificate to a subordinate CA, the inclusion of
widely supported certificate extensions can reduce set of privileges
given to the sub-CA. This aligns with the traditional security
practice of least privilege, where only the privileges needed to
perform the envisioned tasks are provided. However, many sub-CAs
have certificates that pass along the full powers of the CA, and
additional high-pay-off targets for attackers are created.
Some major implementations have not fully implemented the mechanisms
necessary to reduce sub-CA privileges. For example, RFC 5280
[RFC5280] includes the specification of name constraints, and the CA/
Browser Forum guidelines [CAB2014] encourage the use dNSNames in
permittedSubtrees within the name Constraints extension. Despite
this situation, at least one major browser does not support name
constraints, and as a result, CAs are reluctant to use name
constraints.
3.5. No automation for server operators
There are many manual steps involved in getting a certificate from a
CA. There are at least two ways that this impacts web security.
First, many sites do not have a certificate at all. The cost, time,
and effort are too great for the system administrator to go through
the effort, especially if the web site does not offer anything for
purchase. Second, once a certificate is obtained, a replacement is
not obtained until the current one expires. Automation can reduce
the amount of time that a system administrator needs to dedicate to
certificate management, and it can make certificate renewal timely
and automatic.
3.6. Attacks are not reported when they are detected
When browsers are able to detect a man-in-the-middle, they do not
report this situation to the user. Sometimes the man-in-the-middle
is an attacker, and other times a service provider purposefully
terminates the TLS at a location other than the web server. One
example became very public in February 2012 when Trustwave admitted
Housley & O'Donoghue Expires January 7, 2016 [Page 4]
Internet-Draft Web PKI Problems July 2015
that it had issued a subordinate CA certificate for use by a company
to inspect corporate network traffic [LC2012]. Regardless of the
reason for the man-in-the-middle browser users should be aware of
them every time that they are detected. If the man-in-the-middle is
an attacker, then they are thwarted. If the man-in-the-middle is the
service provider, then the browser user is aware that the traffic is
not protected to the ultimate destination.
3.7. Weak cryptographic algorithms or short keys
Many certificates contain weak cryptographic algorithms or contain
public keys that are too short. In many cases, this is because
algorithm and key size choices that were reasonable when they were
chosen and then put in a certificate with an extremely long lifetime.
As a result, valid certificates contain cryptographic algorithms
after weakness has been discovered and widely known. For example,
certificates that use the MD2 or MD5 one-way hash functions should be
replaced. Similarly, valid certificates contain public keys after
computational resources available to attackers has rendered them too
weak. For example, certificates that contain RSA public keys shorter
than 1024 bits should be replaced.
Today, the algorithms and key sizes used by a CA to sign certificates
with a traditional lifespan should offer at least 128 bits of
security. SHA-256 is a widely studied one-way hash function that
meets this requirement. RSA with a public key of 2048 bits or ECDSA
with a public key of 256 bits are widely studied digital signature
algorithms that meet this requirement.
4. Non-technical Problems with the Web PKI
While there are several technical issues that impact the widespread
usage of the Web PKI, there are also a number of non-technical or
process problems that have impeded adoption and deployment. This
section discusses the ways that business models and operational
processes are hindering the Web PKI.
4.1. Determination of the Trusted Certificate Authorities
The current system for determining which CAs are added to or removed
from the trusted store is perceived as opaque and not terribly
uniform across the industry. As mentioned earlier, the CAB Forum has
developed baseline requirements for the management and issuance of
certificates [CAB2014] for individual CAs. However, the process or
set of requirement by which an individual CA gets added to the trust
store for each of the major browsers is not clear or transparent.
The browser vendors and the CAs determine what should and should not
be trusted by default. There are options to make local modifications
Housley & O'Donoghue Expires January 7, 2016 [Page 5]
Internet-Draft Web PKI Problems July 2015
by educated users, but there is little understanding about the
implications of these choices. How does an individual, organization,
or enterprise really determine if a particular CA is trustworthy? Do
the default choices truly represent the organization's trust model?
What constitutes sufficiently bad behavior by a CA to cause removal
from the trust store?
One form of bad behavior by CAs is the mis-issuance of certificates.
This mis-issuance can be either an honest mistake by the CA,
malicious behavior by the CA, or a case where an external party has
duped the CA into the mis-issuance. When a CA has delegated
authority to a sub-CA, and then the sub-CA issued bad certificates
either unintentionally or maliciously, the CA is able to deny
responsibility for the actions of the sub-CA. However, the CA may be
the only party that can revoke the sub-CA certificate to protect the
overall Web PKI.
4.2. Dominate Certificate Authorities
The CA industry has evolved to the point where there may be a few
very large CAs that are critical to significant portions of Internet
infrastructure. The Internet ecosystem must support these CAs; they
have become so critical that they cannot be allowed to fail. As a
result these CAs are able to dominate the Web PKI. Some mechanism is
needed to ensure that these "too big to fail" CAs always act in the
best interest of the Internet ecosystem as a whole.
4.3. Cost and Complexity of Deployment
There are many tales about the cost associated with Web PKI
deployment and the difficulties that system administrators face to
enroll and renew their certificates. The steps required to acquire
and install a certificate are both costly and complex. Automation is
needed to make these tasks simple and straightforward. In addition,
automation should reduce the cost.
5. Emerging Technical Improvements
Many activities are underway to improve the Web PKI. Each of these
activities offers some improvement, and taken together, they offer
significant improvement.
5.1. Certificate Status Checking
To improve security, certificate status checking needs to be used at
all times, either by checking a fresh CRL or by checking an OCSP
response. There are ways to make these certificate status checks
more efficient.
Housley & O'Donoghue Expires January 7, 2016 [Page 6]
Internet-Draft Web PKI Problems July 2015
5.1.1. CRL Distribution Points
The certificate revocation list distribution point (CRLDP)
certificate extension RFC 5280 [RFC5280] allows a CA to control the
maximum size of the CRLs that they issue. This helps in two ways.
First, the amount of storage needed by the browser to cache CRLs is
reduced. Second, and more importantly, the amount of time it takes
to download a CRL can be scoped, which can reduce the latency
associated with certificate status checking. Sadly, few CAs take
advantage of the CRLDP certificate extension.
5.1.2. OCSP Stapling
Browsers can avoid transmission of CRLs altogether by using the
Online Certificate Status Protocol (OCSP) RFC 6960 [RFC6960] to check
the validity of web server certificates. The TLS Certificate Status
Request extension is defined in Section 8 of RFC 6066 [RFC6066]. In
addition, RFC 6961 [RFC6961] defines the TLS Multiple Certificate
Status Request extension, which allows the web server to provide
status information about its own certificate and also the status of
intermediate certificates in the certification path. By including
this extension in the TLS handshake, the browser asks the web server
to provide an OCSP response in addition to its certificate. This
reduces the number of round trips by the browser to set up the TLS
session. The web server can cache the OCSP response for a period of
time, avoiding additional latency. Even in the cases where the web
server needs to contact the OCSP responder, the web server usually
has a higher bandwidth connection than the browser to do so. The
provision of the time-stamped OCSP response in the TLS handshake is
referred to as "stapling" the OCSP response to the TLS handshake.
If the browser does not receive a stapled OCSP response, it can
simply contact the OCSP responder directly.
When every browser that connects to a high volume website performs
its own OCSP lookup, the OCSP responder must handle a real-time
response to every browser. OCSP stapling can avoid enormous volumes
of OCSP requests for certificates of popular websites, so stapling
can significantly reduce the cost of providing an OCSP service.
OCSP stapling can also improve user privacy, since the web server,
not the browser, contacts the OCSP responder. In this way, the OCSP
responder is not able to determine which browsers are checking the
validity of certificate for websites.
Housley & O'Donoghue Expires January 7, 2016 [Page 7]
Internet-Draft Web PKI Problems July 2015
5.2. Leveraging the DNS
Two mechanisms leverage the DNS to improve the Web PKI. The first
one, DNS-Based Authentication of Named Entities (DANE), provides a
verification control that is performed by the browser after the
certificate is issued. The second one, Certificate Authority
Authorization (CAA), provides an authorization control to be
performed by the CA before it issues a certificate.
5.2.1. DNS-Based Authentication of Named Entities (DANE)
The DNS-Based Authentication of Named Entities (DANE) [RFC6698]
allows domain administrators to specify the raw public keys or
certificates that are used by web servers in their domain. DANE
leverages the DNS Security Extensions (DNSSEC) [RFC4034][RFC4035],
which provides digital signatures over DNS zones that are validated
with keys that are bound to the domain name of the signed zone. The
keys associated with a domain name can only be signed by a key
associated with the parent of that domain name. For example, the
DNSSEC keys for "mysite.example.com" can only be signed by the DNSSEC
keys for "example.com". Therefore, a malicious actor can only
compromise the keys of their own subdomains. Like the Web PKI,
DNSSEC relies on public keys used to validate chains of signatures,
but DNSSEC has a single root domain as opposed to a multiplicity of
trusted CAs.
DANE binds raw public keys or certificates to DNS names. The domain
administrator is the one that vouches for the binding of the public
key or the certificate to the domain name by adding the TSLA records
to the zone and then signing the zone. In this way, the same
administrator is responsible for managing the DNS names themselves
and associated public keys or certificates with those names. DANE
restricts the scope of assertions that can be made, forcing them to
be consistent with the DNS naming hierarchy.
In addition, DNSSEC reduces opportunities for redirection attacks by
binding the domain name to the public key or certificate.
5.2.2. Certificate Authority Authorization (CAA)
The Certificate Authority Authorization (CAA) [RFC6844] DNS resource
record allows a domain administrator to specify one or more CA that
is authorized to issue certificates that include the domain name.
Then, a trustworthy CA will refuse to issue a certificate for a
domain name that has a CAA resource record that does not explicitly
name the CA.
Housley & O'Donoghue Expires January 7, 2016 [Page 8]
Internet-Draft Web PKI Problems July 2015
5.3. Leveraging HTTP
Two mechanisms leverage headers carried in HTTP. The first one, HTTP
Strict Transport Security (HSTS), provides notice that all
communication with that web server should be TLS-protected. The
second one, HTTP Public Key Pinning (HPKP), ensures that the same
public keys are used to protect communications with the same server
in the future.
5.3.1. HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) [RFC6797] is a security policy
mechanism that protects secure websites against downgrade attacks,
and it greatly simplifies protection against cookie hijacking. The
presence of the Strict-Transport-Security header tells browsers that
all interactions with this web server should never use HTTP without
TLS, which helps protect against eavesdropping and active network
attacks. For example, an attacker trying to become a man-in-the-
middle has little opportunity to intercept traffic between the
browser and the web server.
When a web server includes theStrict-Transport-Security header, the
browser is expected to do two things. First, the browser
automatically turns any insecure links into secure ones. For
instance, "http://mysite.example.com/mypage/" will be changed to
"https://mysite.example.com/mypage/". Second, if the TLS Handshake
results in some failure, such as the certificate cannot be validated,
then an error message is displayed and the user is denied access the
web application.
5.3.2. HTTP Public Key Pinning (HPKP)
HTTP Public Key Pinning (HPKP) [RFC7469] allows a web server to
instruct browsers to remember the server's public key fingerprints
for a period of time. The fingerprint is a one-way hash of the
subject public key information in the certificate. The Public-Key-
Pins header provides a maximum retention period, fingerprints of the
web server certificate, and optionally fingerprints for backup
certificates. The act of saving of the fingerprints is referred to
as "pinning". During pin lifetime, browsers require that the same
web server present a certificate chain that includes a public key
that matches one of the retained fingerprints. This prevents
impersonation of the website with a fraudulent certificate issued by
a compromised CA.
A website can choose to pin the CA certificate so that the browser
will accept only valid certificates for the website domain that are
issued by that CA. Alternatively, the website can choose to pin
Housley & O'Donoghue Expires January 7, 2016 [Page 9]
Internet-Draft Web PKI Problems July 2015
their own certificate and at least one backup certificate in case the
current certificate needs to be replaced due to a compromised server.
Some browser vendors also pin certificates by hardcoding fingerprints
of very well known websites.
5.4. Certificate Transparency
Certificate Transparency [RFC6962] offers a mechanism to detect mis-
issued certificates, and once detected, administrators and CAs can
take the necessary actions to revoke the mis-issued certificates.
When requesting a certificate, the administrator can request the CA
to include an embedded Signed Certificate Timestamp (SCT) in the
certificate to ensure that their legitimate certificate is logged
with one or more Certificate Transparency (CT) log.
In the future, a browser may choose to reject certificates without an
SCT, and potentially notify the website administrator or CA when they
encounter such a certificate. This reporting will help detect mis-
issuance of certificates and lead to their revocation.
A administrator, or another party acting on behalf of the
administrator, is able to monitor one or more CT log to which a pre-
certificate or certificate is submitted, and detect the logging of a
pre-certificate or certificate that contains their domain name. When
such a pre-certificate or certificate is detected, the CA can be
contacted to to get the mis-issued certificate revoked.
6. Emerging Non-technical Improvements
As with the technical issues around the Web PKI, there are some
possible approaches to address the non-technical and process issues.
6.1. Open and Inclusive Web PKI Forum
Is it possible to evolve the CAB Forum or create another forum that
would create and manage the Web PKI in an open, inclusive, and
transparent manner? In the past, the CAB Forum has decided to remain
closed. The CAB Forum Bylaws limit membership to Issuing CAs, Root
CAs, and Browser vendors [CAB1.2].
Some organization to manage the Web PKI in an open, inclusive, and
transparent manner is needed. This would necessarily includes a
process to manage decisions about which CAs are trustworthy. It
would be important for this forum to also respond to computer
incidents that impact the infrastructure for the Web PKI.
Housley & O'Donoghue Expires January 7, 2016 [Page 10]
Internet-Draft Web PKI Problems July 2015
6.2. Cost Effective and Simple Deployment
The IETF ACME working group [ACMEWG] is working on protocols that
will provide system administrators an automated way to enroll and
renew their certificates. The expectation is that these
specifications will lead to widely available tools for system
administrators. The Let's Encrypt project [LE]is already moving in
this direction. The expectation is that these protocols and tools
will greatly reduce complexity and cost.
7. Security Considerations
TBD.
8. IANA Considerations
None.
{{{ RFC Editor: Please remove this section prior to publication. }}}
9. References
9.1. Normative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
9.2. Informative References
[ACMEWG] IETF, "Charter for Automated Certificate Management
Environment (acme) Working Group", June 2015,
<https://datatracker.ietf.org/doc/charter-ietf-acme/>.
[CAB1.2] CA/Browser Forum, "Bylaws of the CA/Browser Forum",
October 2014, <https://cabforum.org/wp-content/uploads/CA-
Browser-Forum-Bylaws-v.1.2.pdf>.
[CAB2014] CA/Browser Forum, "CA/Browser Forum Baseline Requirements
for the Issuance and Management of Publicly-Trusted
Certificates, v.1.2.2", October 2014,
<https://cabforum.org/wp-content/uploads/BRv1.2.2.pdf>.
Housley & O'Donoghue Expires January 7, 2016 [Page 11]
Internet-Draft Web PKI Problems July 2015
[FOXIT] Prins, J., "DigiNotar Certificate Authority breach:
"Operation Black Tulip"", September 2011,
<http://www.rijksoverheid.nl/bestanden/documenten-en-
publicaties/rapporten/2011/09/05/
diginotar-public-report-version-1/
rapport-fox-it-operation-black-tulip-v1-0.pdf>.
[LC2012] Constantin, L., "Trustwave admits issuing man-in-the-
middle digital certificate; Mozilla debates punishment",
February 2012,
<http://www.computerworld.com/article/2501291/internet/
trustwave-admits-issuing-man-in-the-middle-digital-
certificate--mozilla-debates-punishment.html>.
[LE] Internet Security Research Group, "Let's Encrypt", July
2015, <https://letsencrypt.org/>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844,
January 2013.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, June 2013.
Housley & O'Donoghue Expires January 7, 2016 [Page 12]
Internet-Draft Web PKI Problems July 2015
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
June 2013.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, June 2013.
[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, April 2015.
Appendix A. Acknowledgements
This document has been developed within the IAB Privacy and Security
Program. The authors greatly appreciate the review and suggestions
provided by Mary Barnes, Richard Barnes, Marc Blanchet, Alissa
Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted Hardie, Christian
Huitema, Eliot Lear, Xing Li, Lucy Lynch, Andrei Robachevsky, Thomas
Roessler, Christine Runnegar, Wendy Seltzer, Brian Trammell, and Juan
Carlos Zuniga.
Appendix B. IAB Members at the Time of Approval
{{{ RFC Editor: Please add the names to the IAB members at the time
that this document is put into the RFC Editor queue. }}}
Authors' Addresses
Russ Housley
Vigil Security
918 Spring Knoll Drive
Herndon, VA 20170
USA
Email: housley@vigilsec.com
Karen O'Donoghue
Internet Society
1775 Wiehle Ave #201
Reston, VA 20190
USA
Email: odonoghue@isoc.org
Housley & O'Donoghue Expires January 7, 2016 [Page 13]