idnits 2.17.00 (12 Aug 2021) /tmp/idnits38192/draft-iab-web-pki-problems-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2016) is 2067 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) == Outdated reference: draft-hallambaker-tlsfeature has been published as RFC 7633 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board R. Housley 3 Internet-Draft Vigil Security 4 Intended status: Informational K. O'Donoghue 5 Expires: March 26, 2017 Internet Society 6 September 22, 2016 8 Problems with the Public Key Infrastructure (PKI) for the World Wide Web 9 draft-iab-web-pki-problems-03.txt 11 Abstract 13 The Public Key Infrastructure (PKI) used for the World Wide Web (Web 14 PKI) is a vital component of trust in the Internet. In recent years, 15 there have been a number of improvements made to this infrastructure, 16 including improved certificate status checking, automation, and 17 transparency of governance. However, additional improvements 18 necessary. This document identifies continuing areas of concerns and 19 provides recommendations to the Internet community for additional 20 improvements, moving toward a more robust and secure Web PKI. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 26, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Very Brief Description of the Web PKI . . . . . . . . . . . . 2 58 3. Improvements to the Web PKI . . . . . . . . . . . . . . . . . 3 59 3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 3 60 3.2. Support for Enterprise PKIs . . . . . . . . . . . . . . . 4 61 3.3. Web PKI in the Home . . . . . . . . . . . . . . . . . . . 6 62 3.4. Browser Error Messages . . . . . . . . . . . . . . . . . 8 63 3.5. Governance Improvements to the Web PKI . . . . . . . . . 8 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 6.2. Informative References . . . . . . . . . . . . . . . . . 11 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 70 Appendix B. IAB Members at the Time of Approval . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 There are many interrelated problems with the current Public Key 76 Infrastructure (PKI) used for the World Wide Web (Web PKI). The Web 77 PKI makes use of certificates as described in RFC 5280 [RFC5280]. 78 These certificates are primarily used with Transport Layer Security 79 (TLS) as described in RFC 5246 [RFC5246]. 81 The economics of the Web PKI value chain are discussed in [VFBH], 82 [AV], and [AVAV]. This document does not discuss the economic issues 83 further, but these economic issues provide motivation for correcting 84 the other problems that are discussed in this document. 86 Over the years, many technical improvements have been made to the Web 87 PKI, but several challenges remain. This document offers a general 88 set of recommendations to the Internet community that might be 89 helpful in addressing these remaining challenges. 91 2. Very Brief Description of the Web PKI 93 Certificates are specified in RFC 5280 [RFC5280]. Certificates 94 contain, among other things, a subject name, a public key, a limited 95 valid lifetime, and the digital signature of the Certification 96 Authority (CA). Certificate users require confidence that the 97 private key associated with the certified public key is owned by the 98 named subject. 100 The architectural model used in the Web PKI includes: 102 EE: End Entity -- the subject of a certificate -- certificates are 103 issued to end entities including Web servers and clients that 104 need mutual authentication. 106 CA: Certification Authority -- the issuer of a certificate -- 107 issues certificates for end entities including Web servers and 108 clients. 110 RA: Registration Authority -- an optional system to which a CA 111 delegates some management functions such as identity validation 112 or physical credential distribution. 114 A valid certificate may be revoked for any number of reasons. CAs 115 are responsible for indicating the revocation status of the 116 certificates that they issue throughout the lifetime of the 117 certificate. Revocation status information may be provided using the 118 Online Certificate Status Protocol (OCSP) [RFC6960], certificate 119 revocation lists (CRLs) [RFC5280], or some other mechanism. In 120 general, when revocation status information is provided using CRLs, 121 the CA is also the CRL issuer. However, a CA may delegate the 122 responsibility for issuing CRLs to a different entity. 124 The enrollment process used by a CA makes sure that the subject name 125 in the certificate is appropriate and that the subject actually holds 126 the private key. Proof of possession of the private key is often 127 accomplished through a challenge-response protocol. 129 3. Improvements to the Web PKI 131 Over the years, many technical improvements have been made to the Web 132 PKI. Despite this progress, several challenges remain. This section 133 discusses several unresolved problems, and it suggests general 134 directions for tackling them. 136 3.1. Weak Cryptographic Algorithms or Short Public Keys 138 Several digital signature algorithms, one-way hash functions, and 139 public key sizes that were once considered strong are no longer 140 considered adequate. This is not a surprise. Cryptographic 141 algorithms age; they become weaker over time. As new cryptanalysis 142 techniques are developed and computing capabilities increase, the 143 amount of time needed to break a particular cryptographic algorithm 144 will decrease. For this reason, the algorithms and key sizes used in 145 the Web PKI need to migrate over time. 147 Browser vendors have been trying to manage algorithm and key size 148 transitions. It is a significant challenge to maintain a very high 149 degree of interoperability across the world wide web while phasing 150 out aged cryptographic algorithm or too small key size. When these 151 appear in a long-lived trust anchor or intermediate CA certificate, 152 refusal to accept them can impact a very large certificate subtree. 153 In addition, if a certificate for a web site with a huge amount of 154 traffic is in that subtree, rejecting that certificate may impact too 155 many users. 157 Despite this situation, the MD5 and SHA-1 one-way hash functions have 158 been almost completely eliminated from the Web PKI, and 1024-bit RSA 159 public keys are essentially gone [MB2015] [MB2016]. It took a very 160 long time to make this happen, and trust anchors and certificates 161 that used these cryptographic algorithms were considered valid long 162 after they were widely known to be too weak. 164 Obviously, additional algorithm transitions will be needed in the 165 future. The algorithms and key sizes that are acceptable today will 166 become weaker with time. [RFC7696] offers some guidelines regarding 167 cryptographic algorithm agility. 169 The Web PKI can prepare for the next transition by: 171 1. Having experts periodically evaluate the current choices of 172 algorithm and key size. While it is not possible to predict when 173 a new cryptanalysis technique will be discovered, the end of the 174 useful lifetime of most algorithms and key sizes is known many 175 years in advance. 177 2. Planning for a smooth and orderly transition from a weak 178 algorithm or key size. Experience has shown that many years are 179 needed produce to specifications, develop implementations, and 180 then deploy replacements. 182 3. Reducing the lifetime of certificates, especially intermediate CA 183 certificates, to create frequent opportunities to change an 184 algorithm or key size. 186 3.2. Support for Enterprise PKIs 188 Many enterprises operate their own PKI. These enterprises do not 189 want to be part of the traditional Web PKI, but they face many 190 challenges in order to achieve a similar user experience and level of 191 security. 193 Users must install the trust anchor or trust anchors for the 194 enterprise PKI in their browser. There is not a standard way to 195 accomplish trust anchor installation, and users are often faced with 196 scary warnings in the process of the installation. 198 Enterprise PKI users often experience greater latency than tradition 199 Web PKI users. Some browser vendors provide a proprietary revocation 200 checking mechanism that obtains revocation status for the entire Web 201 PKI in a very compact form. This mechanism eliminates latency since 202 no network traffic is generated at the time that a certificate is 203 being validated. However, these mechanisms cover only the trust 204 anchor store for that browser vendor, excluding all enterprise PKIs. 205 In addition, measurements in 2015 [IMC2015] show that these 206 mechanisms do not currently provide adequate coverage of the Web PKI. 208 RFC 6961 [RFC6961] defines the TLS Multiple Certificate Status 209 Request extension, which allows the web server to provide status 210 information about its own certificate and also the status of 211 intermediate certificates in the certification path. By including 212 this extension in the TLS handshake, the browser asks the web server 213 to provide OCSP responses in addition to the server certificate. 214 This approach greatly reduces the latency since the browser does not 215 need to generate any OCSP requests or wait for any OCSP responses. 217 The provision of the time-stamped OCSP response in the TLS handshake 218 is referred to as "stapling" the OCSP response to the TLS handshake. 219 If the browser does not receive a stapled OCSP response, it can 220 contact the OCSP responder directly. In addition, the MUST_STAPLE 221 feature [TLSFEATURE] can be used to insist that OCSP stapling be 222 used. 224 When every browser that connects to a high volume website performs 225 its own OCSP lookup, the OCSP responder must handle a large volume of 226 OCSP requests in real-time. OCSP stapling can avoid enormous volumes 227 of OCSP requests for certificates of popular websites, so stapling 228 can significantly reduce the cost of providing an OCSP service. 230 OCSP stapling can also improve user privacy, since the web server, 231 not the browser, contacts the OCSP responder. In this way, the OCSP 232 responder is not able to determine which browsers are checking the 233 validity of certificate for particular websites. 235 Several enterprises issue certificates to all of their employees, and 236 among other uses, these certificates are used in TLS client 237 authentication. There is not a common way to import the private key 238 and the client certificate into browsers. In fact, the private key 239 can be stored in many different formats depending on the software 240 used to generate the public/private key pair. PKCS#12 [RFC7292] 241 seems to be the most popular format at the moment. A standard way to 242 import the needed keying material and a standard format will make 243 this task much easier, and the World Wide Web might enjoy an increase 244 in mutual authentication. 246 Enterprise PKIs can be better supported if: 248 1. Each enterprise PKI offers an OCSP Responder, and web sites with 249 certificates from the enterprise PKI make use of OCSP Stapling. 251 2. Browser vendors support a standard way for the trust anchors for 252 the enterprise PKI to be installed. 254 3. Browser vendors support a standard way to install private keys 255 and certificates for use in client authentication. 257 4. In the event that browser vendors continue to offer latency-free 258 proprietary revocation status checking mechanisms, then these 259 mechanisms need to expand the coverage to all of the Web PKI and 260 offer a means to include enterprise PKIs in the coverage. 262 3.3. Web PKI in the Home 264 More and more, web protocols are being used to manage devices in the 265 home. For example, homeowners can use a web browser to connect to a 266 web site that is embedded in their home router to adjust various 267 settings. The router allows the browser to access web pages to 268 adjust these setting as long as the connection originates from the 269 home network and the proper password is provided. However, there is 270 no way for the browser to authenticate to the embedded web site. 271 Authentication of the web site is normally performed during the TLS 272 handshake, but the Web PKI is not equipped to issue certificates to 273 home routers or the many other home devices that employ embedded web 274 sites for homeowner management. 276 A solution in this environment must not depend on the homeowner to 277 perform duties that are normally associated with a web site 278 administrator. However, some straightforward tasks could be done at 279 the time the device is installed in the home. These task cannot be 280 more complex that the initial setup of a new printer in the home, 281 otherwise they will be skipped or done incorrectly. 283 There are two very different approaches to certificates for home 284 devices that have been discussed over the years. In the first 285 approach, a private key and certificate are installed in the device 286 at the factory. The certificate has an unlimited lifetime. Since it 287 never expires, no homeowner action is needed to renew it. Also, 288 since the certificate never changes, the algorithms are selected by 289 the factory for the lifetime of the device. The subject name in the 290 certificate is quite generic, as it must be comprised of information 291 that is known in the factory. The subject name is often based on 292 some combination of the manufacturer, model, serial number, and MAC 293 address. While these do uniquely identify the device, they have 294 little meaning to the homeowner. 296 In the second approach, like the first one, a private key and a 297 certificate that are installed in the device at the factory, but the 298 homeowner is unaware of them. This factory-installed certificate is 299 used only to authenticate to a CA operated by the manufacturer. At 300 the time the device is installed, the homeowner can provide a portion 301 of the subject name for the device, and the manufacturer CA can issue 302 a certificate that includes a subject name that the homeowner will 303 recognize. The certificate can be renewed without any action by the 304 homeowner at appropriate intervals. Also, following a software 305 update, the algorithms used in the TLS handshake and the certificate 306 can be updated. 308 Section 3.1 of this document calls for the ability to transition from 309 weak cryptographic algorithms over time. For this reason, and the 310 ability to use a subject name that the homeowner will recognize, the 311 second approach is preferred. 313 One potential problem with the second approach is continuity of 314 operations of the manufacturer CA. After the device is deployed, the 315 manufacturer might go out of business, and then come time for renewal 316 of the certificate, there will not be a CA to issue the new 317 certificate. One possible solution might be modeled on the domain 318 name business, where other parties will continue to provide needed 319 services if the original provider goes out of business. 321 The Web PKI can prepare for the vast number of home devices that need 322 certificates by: 324 1. Building upon the work being done in the IETF ACME Working Group 325 [ACMEWG] to facilitate the automatic renewal of certificates for 326 home devices without any actions by the homeowner beyond the 327 initial device setup. 329 2. Working with device manufacturers to establish scalable CAs that 330 will continue to issue certificates for the deployed devices even 331 if the manufacture goes out of business. 333 3. Working with device manufacturers to establish OCSP Responders so 334 that the web sites that are embedded in the devices can provide 335 robust authentication and OCSP stapling in a manner that is 336 compatible with traditional web sites. 338 3.4. Browser Error Messages 340 Many users find browser error messages related to certificates 341 confusing. Good man-machine interfaces are always difficult, but in 342 this situation users are unable to fully understand the risks that 343 they are accepting, and as a result they do not make informed 344 decisions about when to proceed and when to stop. This aspect of 345 browser usability needs to be improved for users to make better 346 security choices. 348 Browser users have been trained to ignore warnings, making them 349 ineffective. Further, solving the error message situation in 350 isolation is probably not possible; instead, it needs to be 351 considered along side the other issues raised in this document. 352 Browser users have been trained to find a way around any error, and 353 very often, the error is the result of web server misconfiguration, 354 and it does not actually present a risk to the browser user. 356 If the risk to the user is high, then the session should be closed 357 with a clear description of the problem that was encountered. Doing 358 so will lead to improved management of the overall Web infrastructure 359 over time, especially as the tools that are being developed for web 360 server administrators are rolled out. 362 In some enterprises, avoiding these errors requires the addition of 363 enterprise-specific trust anchors to the browser. Additional tools 364 are needed to allow administrations to easily add appropriate trust 365 anchors, especially browsers on consumer devices as more and more 366 enterprises are embracing bring-your-own-device policies. 368 The Web PKI can simplify user choice and improve user actions by: 370 1. Browser vendors providing additional intelligence to eliminate 371 the majority of certificate warnings, only prompting the user 372 when there is likely to be a risk. 374 2. Browser vendors improving error messages to clearly indicate the 375 risk that the user is accepting if they proceed. 377 3.5. Governance Improvements to the Web PKI 379 As with many other technologies, Web PKI technical issues are tangled 380 up with policy and process issues. Policy and process issues have 381 evolved over time, sometimes eroding confidence and trust in the Web 382 PKI. Governance structures are needed that increase transparency and 383 trust. 385 Web PKI users are by definition asked to trust CAs. This includes 386 what CAs are trusted to do properly, and what they are trusted not to 387 do. The system for determining which CAs are added to or removed 388 from the trust anchor store in browsers is opaque and confusing to 389 most Web PKI users. The CA/Browser Forum has developed baseline 390 requirements for the management and issuance of certificates 391 [CAB2014] for individual CAs. However, the process by which an 392 individual CA gets added to the trust anchor store by each of the 393 browsers vendors is not straightforward. The individual browser 394 vendors determine what should and should not be trusted by including 395 the CA certificate in their trust anchor store. They do this by 396 leveraging the AICPA/CICA WebTrust Program for Certification 397 Authorities [WEBTRUST]. This program provides auditing requirements 398 and a trust mark for CAs that meet them. Failure to pass an audit 399 can result in the CA being removed from the trust store. 401 Once the browser has shipped, how does a user know which CAs are 402 trusted or what has changed recently? For an informed user, 403 information about which CAs have been added to or deleted from the 404 browser trust anchor store can be found in the browser release notes. 405 Users can also examine the policies of the various CAs that have been 406 developed and posted for the WebTrust Program. However, this is a 407 very high barrier for the average user. There are options to make 408 local modifications by educated users, but there is little 409 understanding about the implications of these choices. How does an 410 individual, organization, or enterprise really determine if a 411 particular CA is trustworthy? Do the default choices inherited from 412 the browser vendors truly represent the organization's trust model? 413 What constitutes sufficiently bad behavior by a CA to cause removal 414 from the trust anchor store? 416 In addition, it can be hazardous for users to remove CAs from the 417 browser trust anchor store. If a user removes a CA from the browser 418 trust anchor store, some web sites may become completely inaccessible 419 or require the user to take explicit action to accept warnings or 420 bypass browser protections related to untrusted certificates. 422 The guidelines provided by the WebTrust program [WEBTRUST] provide a 423 framework for removing a CA from the trust anchor store. There may 424 be a few very large CAs that are critical to significant portions of 425 World Wide Web infrastructure. Removing one of these CAs can have a 426 significant impact on a huge number of websites. As discussed in 427 Section 3.4, users are already struggling to understand the 428 implications of untrusted certificates, so they often ignore warnings 429 presented by the browser. 431 There are a number of organizations that play significant roles in 432 the operation of the Web PKI, including the CA/Browser Forum, the 433 WebTrust Program, and the browser vendors. These organizations act 434 on behalf of the entire Internet community; therefore, transparency 435 in these operations is fundamental to confidence and trust in the Web 436 PKI. Recently the CA/Browser Forum made some changes to their 437 operational procedures to make it easier for people to participate 438 and to improve visibility into their process [CAB1.2]. This is a 439 significant improvement, but these processes need to continue to 440 evolve in an open, inclusive, and transparent manner. Currently, as 441 the name implies, the CA/Browser Forum members primarily represent 442 CAs and browser vendors. It would be better if relying parties also 443 have a voice in this forum. 445 Since the Web PKI is widespread, applications beyond the World Wide 446 Web are making use of the Web PKI. For example, the Web PKI is used 447 to secure connections between SMTP servers. In these environments, 448 the browser-centric capabilities are unavailable. The current 449 governance structure does not provide a way for the relying parties 450 in these applications to participate. 452 The Web PKI governance structures can be made more open and 453 transparent by: 455 1. Browser vendors providing additional visibility and tools to 456 support the management of the trust anchor store. 458 2. Governance organizations providing a way for all relying parties, 459 including ones associated with non-browser applications, to 460 participate. 462 4. Security Considerations 464 This document considers the weaknesses of the current Web PKI system 465 and provides recommendations for improvements. Some of the risks 466 associated with doing nothing or continuing down the current path are 467 articulated. The Web PKI is a vital component of a trusted Internet, 468 and as such needs to be improved to sustain continued growth of the 469 Internet. 471 5. IANA Considerations 473 None. 475 {{{ RFC Editor: Please remove this section prior to publication. }}} 477 6. References 479 6.1. Normative References 481 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 482 Housley, R., and W. Polk, "Internet X.509 Public Key 483 Infrastructure Certificate and Certificate Revocation List 484 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 485 . 487 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 488 Galperin, S., and C. Adams, "X.509 Internet Public Key 489 Infrastructure Online Certificate Status Protocol - OCSP", 490 RFC 6960, DOI 10.17487/RFC6960, June 2013, 491 . 493 6.2. Informative References 495 [ACMEWG] IETF, "Charter for Automated Certificate Management 496 Environment (acme) Working Group", June 2015, 497 . 499 [AV] Arnbak, A. and N. van Eijk, "Certificate Authority 500 Collapse: Regulating Systemic Vulnerabilities in the HTTPS 501 Value Chain", 2012 TRPC , August 2012, 502 . 504 [AVAV] Asghari, H., van Eeten, M., Arnbak, A., and N. van Eijk, 505 "Security Economics in the HTTPS Value Chain", Workshop on 506 Economics of Information Security (WEIS) 2013 , 2013, 507 . 510 [CAB1.2] CA/Browser Forum, "Bylaws of the CA/Browser Forum", 511 October 2014, . 514 [CAB2014] CA/Browser Forum, "CA/Browser Forum Baseline Requirements 515 for the Issuance and Management of Publicly-Trusted 516 Certificates, v.1.2.2", October 2014, 517 . 519 [IMC2015] Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D., 520 Maggs, B., Mislove, A., Schulman, A., and C. Wilson, "An 521 End-to-End Measurement of Certificate Revocation in the 522 Web's PKI", October 2015, 523 . 526 [MB2015] Wilson, K., "Phase 2: Phasing out Certificates with 527 1024-bit RSA Keys", January 2015, 528 . 531 [MB2016] Barnes, R., "Payment Processors Still Using Weak Crypto", 532 February 2016, 533 . 536 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 537 (TLS) Protocol Version 1.2", RFC 5246, 538 DOI 10.17487/RFC5246, August 2008, 539 . 541 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 542 Multiple Certificate Status Request Extension", RFC 6961, 543 DOI 10.17487/RFC6961, June 2013, 544 . 546 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., 547 and M. Scott, "PKCS #12: Personal Information Exchange 548 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014, 549 . 551 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 552 Agility and Selecting Mandatory-to-Implement Algorithms", 553 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 554 . 556 [TLSFEATURE] 557 Hallam-Baker, P., "X.509v3 TLS Feature Extension", draft- 558 hallambaker-tlsfeature-10 (work in progress), July 2015. 560 [VFBH] Vratonjic, N., Freudiger, J., Bindschaedler, V., and J. 561 Hubaux, "The Inconvenient Truth About Web Certificates", 562 Workshop on Economics of Information Security (WEIS) 563 2011 , 2011, 564 . 567 [WEBTRUST] 568 CPA Canada, "WebTrust Program for Certification 569 Authorities", August 2015, . 572 Appendix A. Acknowledgements 574 This document has been developed within the IAB Privacy and Security 575 Program. The authors greatly appreciate the review and suggestions 576 provided by Rick Andrews, Mary Barnes, Richard Barnes, Marc Blanchet, 577 Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted Hardie, 578 Ralph Holz, Lee Howard, Christian Huitema, Eliot Lear, Xing Li, Lucy 579 Lynch, Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy 580 Rowley, Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Brian 581 Trammell, and Juan Carlos Zuniga. 583 Appendix B. IAB Members at the Time of Approval 585 {{{ RFC Editor: Please add the names to the IAB members at the time 586 that this document is put into the RFC Editor queue. }}} 588 Authors' Addresses 590 Russ Housley 591 Vigil Security 592 918 Spring Knoll Drive 593 Herndon, VA 20170 594 USA 596 Email: housley@vigilsec.com 598 Karen O'Donoghue 599 Internet Society 600 1775 Wiehle Ave #201 601 Reston, VA 20190 602 USA 604 Email: odonoghue@isoc.org