idnits 2.17.1 draft-ietf-pkix-certimage-11.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5280], [RFC3709]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC3709, but the abstract doesn't seem to directly say this. It does mention RFC3709 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3709, updated by this document, for RFC5378 checks: 2001-07-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2011) is 4818 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 177 -- Looks like a reference, but probably isn't: '4' on line 182 ** Downref: Normative reference to an Informational RFC: RFC 1952 ** Obsolete normative reference: RFC 3709 (Obsoleted by RFC 9399) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO15948' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO19005' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO32000' -- Possible downref: Non-RFC (?) normative reference: ref. 'SVG' -- Possible downref: Non-RFC (?) normative reference: ref. 'SVGT' -- Obsolete informational reference (is this intentional?): RFC 3778 (Obsoleted by RFC 8118) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Stefan Santesson (3xA Security) 3 Intended Status: Proposed Standard Russ Housley (Vigil Security) 4 Updates: 3709 (once approved) Siddharth Bajaj (VeriSign) 5 Expires: August 19, 2011 Leonard Rosenthol (Adobe) 6 February 15, 2011 8 Internet X.509 Public Key Infrastructure - Certificate Image 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright and License Notice 34 Copyright (c) 2011 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 This document specifies a method to bind a visual representation of a 50 certificate in the form of a certificate image to a public key 51 certificate as defined in RFC 5280 [RFC5280] by defining a new 52 otherLogos image type according to RFC 3709 [RFC3709]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Certificate Image . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. LogotypeImageInfo . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Embedded images . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Certificate Image Formats . . . . . . . . . . . . . . . . . . . 7 62 5.1. PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.2. SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.3. PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 9.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Appendix A - ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 72 Appendix B - Example . . . . . . . . . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 This standard specifies how to bind a Certificate Image to a 78 certificate (defined in [RFC5280]), providing a visual representation 79 of that certificate using the Logotype extension defined in 80 [RFC3709], specifying the Certificate Image as a new otherLogos type. 82 The purpose of the Certificate image is to aid human interpretation 83 of a certificate by providing meaningful visual information to the 84 user interface. 86 Typical situations when a human needs to examine the visual 87 representation of a certificate are: 89 - A person establishes secured channel with an authenticated 90 service. The person needs to determine the identity of the service 91 based on the authenticated credentials. 93 - A person validates the signature on critical information, such 94 as signed executable code, and needs to determine the identity of 95 the signer based on the signer's certificate. 97 - A person is required to select an appropriate certificate to be 98 used when authenticating to a service or Identity Management 99 infrastructure. The person needs to see the available certificates 100 in order to distinguish between them in the selection process. 102 Display of certificate information to humans is challenging due to 103 lack of well-defined semantics for critical identity attributes. 104 Unless the application has out of band knowledge about a particular 105 certificate, the application will not know the exact nature of the 106 data stored in common identification attributes such as serialNumber, 107 organizationName, country, etc. Consequently the application can 108 display the actual data, but faces problem to label that data in the 109 UI, informing the human about the exact nature (semantics) of that 110 data. It is also challenging for the application to determine which 111 identification attribute that are important to display and how to 112 organize them in a logical order. 114 RFC 3709 [RFC3709] defines a certificate extension for binding images 115 to a certificate, such as community logo and issuer logo, enhancing 116 display of certificate information. The syntax is extensible and 117 allows inclusion of new image types using the other-Logos structure. 118 This standard defines how to include a complete certificate image 119 using the extensibility mechanism of RFC 3709. 121 1.2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2. Certificate Image 129 This section defines the Certificate Image as a new otherLogos type 130 according to section 4.1 of [RFC3709]. 132 The Certificate Image otherLogos type is identified by the Object 133 Identifier (OID) id-logo-certimage. 135 id-pkix OBJECT IDENTIFIER ::= 136 { iso(1) identified-organization(3) dod(6) internet(1) 137 security(5) mechanisms(5) pkix(7) } 139 id-logo OBJECT IDENTIFIER ::= { id-pkix 20 } 141 id-logo-certimage OBJECT IDENTIFIER ::= { id-logo 3 } 143 When present the Certificate Image MUST be a complete visual 144 representation of the certificate. This means that the display of 145 this certificate image represents all information about the 146 certificate that the issuer subjectively defines as relevant to show 147 a typical human user within the typical intended use of the 148 certificate, giving adequate information about at least the following 149 three aspects of the certificate: 151 - Certificate Context 152 - Certificate Issuer 153 - Certificate Subject 155 Certificate Context information is visual marks and/or textual 156 information which helps the typical user to understand the typical 157 usage and/or purpose of the certificate 159 It is up to the issuer to decide what information in the form of text 160 and graphical symbols and elements that represents a complete visual 161 representation of the certificate. However, The visual representation 162 of Subject and Issuer information from the certificate MUST have the 163 same meaning as the textual representation of that information in the 164 certificate itself. 166 Applications providing a Graphical User Interface (GUI) to the 167 certificate user MAY present a Certificate Image according to this 168 standard in any given application interface, as the only visual 169 representation of a certificate. 171 3. LogotypeImageInfo 173 The optional LogotypeImageInfo structure is defined in [RFC3709] and 174 is included here for convenience: 176 LogotypeImageInfo ::= SEQUENCE { 177 type [0] LogotypeImageType DEFAULT color, 178 fileSize INTEGER, -- In octets 179 xSize INTEGER, -- Horizontal size in pixels 180 ySize INTEGER, -- Vertical size in pixels 181 resolution LogotypeImageResolution OPTIONAL, 182 language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag 184 Note: The referenced RFC 3066 in the structure above (from RFC 3709) 185 is obsolete and is currently replaced by RFC 5646 [RFC5646]. 186 The language tag may carry information about the the language 187 used to express any textual elements within the image as well 188 as any audio information associated with the image. 190 When the optional LogotypeImageInfo is included with a certificate 191 image, the parameters shall be used with the following semantics and 192 restrictions. 194 xSize and ySize represents recommended display size for the image. 195 When a value of 0 (zero) is present, no recommended display size 196 specified. When non-zero values are present and these values differ 197 from corresponding size values in the referenced image file, then the 198 referenced image SHOULD be scaled to fit within the size parameters 199 of LogotypeImageInfo, while keeping x and y ratio intact. 201 The resolution parameter is redundant for all image formats that are 202 relevant for certificate images and MUST NOT be specified. 204 4. Embedded images 206 The certificate image otherLogos type defined in this specification 207 and all logotype types defined in RFC 3709 [RFC3709] MAY be stored 208 within the logotype extension using the "data" URL scheme defined in 209 RFC 2397 [RFC2397] if the logotype image is provided through direct 210 addressing, i.e. the image is referenced using the LogotypeDetails 211 structure. 213 The syntax of Logotype details defined in RFC 3709 is included here 214 for convenience: 216 LogotypeDetails ::= SEQUENCE { 217 mediaType IA5String, -- MIME media type name and optional 218 -- parameters 219 logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, 220 logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } 222 The syntax of the "data" URL Scheme defined in RFC 2397 is included 223 here for convenience: 225 dataurl := "data:" [ mediatype ] [ ";base64" ] "," data 226 mediatype := [ type "/" subtype ] *( ";" parameter ) 227 data := *urlchar 228 parameter := attribute "=" value 230 When including the image data in the logotype extension using the 231 "data" URL scheme the following conventions apply. 233 - the value of mediaType in LogotypeDetails MUST be identical to 234 the media type value in the "data" URL. 236 - The hash of the image MUST be included in logotypeHash and MUST 237 be calculated over the same data as it would have been, had the 238 image been referenced through a link to an external resource. 240 Note: As the "data" URL scheme is processed as a data source rather 241 than as a URL, the image data is typically not limited by any 242 URL length limit setting that otherwise apply to URLs in 243 general. 245 Note: Implementations need to be cautious about the size of images 246 included in a certificate in order to ensure that the size of 247 the certificate does not prevent the certificate to be used as 248 intended. 250 5. Certificate Image Formats 252 Implementations of this specification MUST support JPEG and GIF as 253 defined in RFC 3709 [RFC3709]. In addition to these mandatory to 254 implement formats, this specification specifies the use of PDF, SVG 255 and PNG as image formats. 257 5.1. PDF 259 A Certificate Image MAY be provided in the form of a Portable 260 Document Format (PDF) document according to [ISO32000] following the 261 conventions defined in this section. When a certificate image is 262 formatted as a PDF document, it MUST also be formatted according to 263 the profile PDF/A [ISO19005]. 265 When including a PDF document as Certificate Image, the following 266 MIME media type as specified in [RFC3778] MUST be used as mediaType 267 in LogotypeDetails: 269 application/pdf 271 5.2. SVG 273 A Certificate Image MAY be provided in the form of a Scalable Vector 274 Graphic (SVG) image, which MUST follow the SVG Tiny profile [SVGT] 275 with the following amendments: 277 - The SVG image MUST NOT contain any IRI references to information 278 stored outside of the SVG image of type B, C or D according to 279 section 14.1.4 of SVG Tiny 1.2 [SVGT] 281 - The SVG image MUST NOT contain any 'script' element according to 282 section 15.2 of SVG Tiny 1.2 [SVGT] 284 - The XML structure in the SVG file MUST use (linefeed 0x0A) 285 as end-of-line (EOL) character when calculating a hash over the 286 SVG image. 288 The referenced SVG file MAY be provided in GZIP [RFC1952] compressed 289 form as an SVGZ file according to section 1.2 in SVG 1.1 [SVG]. Hash 290 over the SVGZ file is calculated over the decompressed SVG content 291 with canonicalized EOL characters () as specified above. 293 The following MIME media type, defined in Appendix M of [SVGT], MUST 294 be included as mediaType in LogotypeDetails for all SVG and SVGZ 295 images: 297 image/svg+xml 299 When the SVG image is embedded using the "data" URL scheme as defined 300 in section 4, SVG image data MUST be provided in SVGZ (GZIP 301 compressed) form (i.e. it MUST NOT be provided in uncompressed SVG 302 form). 304 Compliant implementations of this specification SHOULD be able to 305 process SVG images that are formatted according to this section. 307 5.3. PNG 309 If a certificate image is provided as a bit mapped image, the PNG 310 [ISO15948] format SHOULD be used. 312 PNG images are identified by the following mediaType in 313 LogotypeDetails: 315 image/png 317 6. Security Considerations 319 This document is based on and inherits all security considerations 320 from RFC 3709 [RFC3709]. In particular, RFC 3709 discusses several 321 issues a Certificate Authority should take into consideration when 322 evaluating a request to issue a certificate with a certificate image. 324 Images incorporated according to RFC 3709 provide an additional 325 possibility for a CA with bad intentions or bad security procedures 326 to include false, conflicting or malicious information to relying 327 parties. A bad performing CA may for example; 329 - include information in graphical form that is in conflict with 330 information in provided text based attributes or other name 331 forms, and; 333 - include malicious data that could exploit known security bugs in 334 common software libraries used to render graphical images. 336 This underlines the necessity for CAs to provide reliable services 337 and the relying party's responsibility and need to carefully select 338 which CA that is trusted to provide public key certificates. 340 This also underlines the general necessity for relying parties to use 341 up-to-date software libraries to render or dereference data from 342 external sources (such as certificates) to minimize risks related to 343 processing potentially malicious data before the data has been 344 adequately verified and validated. 346 Referenced image files are hashed in order to bind the image to the 347 signature of the certificate. Some image types, such as SVG allow 348 part of the image to be collected from external source by 349 incorporating a reference to an external image file. If this feature 350 were used within a certificate image file, the hash of the image file 351 would only cover the URI reference to the external image file, but 352 not the referenced image data. Clients SHOULD verify that SVGT images 353 meets all requirements of section 5.2 and reject images that contain 354 references to external data. 356 CAs issuing certificate with embedded certificate images should be 357 cautious when accepting graphics from the certificate requestor for 358 inclusion in the certificate if the hash algorithm used to sign the 359 certificate is vulnerable to collision attacks. In such case the 360 accepted image may contain data that could help an attacker to obtain 361 colliding certificates with identical certificate signatures. 363 Certificates, and hence their cert images, are commonly public 364 objects and as such usually will not contain privacy sensitive 365 information. However, when a cert image that is referenced from a 366 certificate contains privacy sensitive information appropriate 367 security controls should be in place to protect the privacy of that 368 information. Details of such controls are outside the scope of this 369 document. 371 7. Acknowledgements The Authors recognize valuable contributions from 372 members of the PKIX work group, the CA Browser Forum and James Manger 373 for review and sample data. 375 8. IANA Considerations 377 This document requires no actions from IANA. 379 9. References 381 9.1. Normative References 383 [RFC1952] P. Deutsch, "GZIP file format specification version 4.3", 384 RFC 1952, May 1996 386 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997 389 [RFC2397] L. Masinter, 'The "data" URL scheme' RFC 2397, August 1998 391 [RFC3709] S. Santesson, R. Housley, T. Freeman, "Internet X.509 392 Public Key Infrastructure Logotypes in X.509 393 Certificates", RFC 3709, February 2004 395 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 396 Housley, R., and W. Polk, "Internet X.509 Public Key 397 Infrastructure Certificate and Certificate Revocation List 398 (CRL) Profile", RFC 5280, May 2008 400 [RFC5646] A. Phillips, M. Davis, "Tags for Identifying Languages", 401 RFC 5646, September 2009 403 [ISO15948] ISO/IEC 15948:2004, "Information technology - Computer 404 graphics and image processing -- Portable Network Graphics 405 (PNG): Functional specification", 2004 407 [ISO19005] ISO 19005-1:2005, "Document Management - Electronic 408 document file format for long term preservation - Part 1: 409 Use of PDF 1.4 (PDF/A-1)", 2005 411 [ISO32000] ISO 32000-1:2008, "Document management - Portable document 412 format" -- Part 1: PDF 1.7, April 2008 414 [SVG] W3C Recommendation, "Scalable Vector Graphics (SVG) 1.1 415 Specification", January 2003 417 [SVGT] W3C Recommendation, "Scalable Vector Graphics (SVG) Tiny 418 1.2 Specification", December 2008 420 9.2. Informative References 422 [RFC3778] E. Taft, J. Pravetz, S. Zilles, L. Masinter "The 423 application/pdf Media Type", RFC 3778, May 2004 425 Appendix A - ASN.1 Module 427 CERT-IMAGE-MODULE { iso(1) identified-organization(3) dod(6) 428 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 429 id-mod-logotype-certimage(68) } 431 DEFINITIONS EXPLICIT TAGS ::= 432 BEGIN 434 EXPORTS ALL; -- export all items from this module 436 id-logo-certImage OBJECT IDENTIFIER ::= 437 { iso(1) identified-organization(3) dod(6) internet(1) 438 security(5) mechanisms(5) pkix(7) id-logo(20) 3 } 440 END 442 Appendix B - Example 444 The following example stores an embedded svgz encoded SVG image using 445 the "data" URL scheme. 447 data:image/svg+xml;base64, 448 H4sIAAAAAAAAAO1aW3OjxhJ+968gbKXKrhJo7jCy5WTtvZSrUptT65yTZ4xGElkE 449 KkCWvb8+PYAkQEKSLe3amxz5RfQMQ1++7v4a+eKXh0lo3KskDeKob2IbmYaK/HgQ 450 RKO++d8/PliuaaSZFw28MI5U34xi85fLk4ufLMu4TpSXqYExD7KxcRN9SX1vqozT 451 cZZNe93ufD63g1Jox8moe2ZY1uXJyUV6PzoxDAOeG6U9uOiblTvmNN9LEEJdWDOX 452 O3fuqtmgBfNgkI3hEqGf8+uxCkbjrCK4D9T8Kn7om8hABkPIoKi4Mxj0zWuVZMEw 453 8MFC42bijZR5CUsXAzVM9ZZi04cgzOCx+RIsDvPLYhnU7psWshGm1OEcCXMhf8zl 454 mBKMqLMSL9S1EREOx0v5Um2bCEaQw5crfhzGiRVE8MxpHHoZWG8VKoC30s8fr5Y7 455 ta7FCpXILdXVCquP3ixNAy+6CmdLxQ0I+OCdug/yI/smsQmRpKJSeWDtZioxQKdb 456 eqJbPG2jX56nNiZPVRvbTDLqYLZLb7ZR74uujnX+bbSKeOg9qgQvAj5anJwlXpQO 457 42TSN/OvYJY6RbagnEtKSAeC52DsCn5WM+52DMmRLkVp9hhCiqVZEn9RvTco/6zM 458 TpSfrUwp8cJKzNbBwpDNK2KN8cqlRmAzmvpwgVxpVt2ZqwMuCbUyBAv3XF9YySxU 459 vSiOvqokPi881psl4embFcbOlj49VHGrLgHdCa9qWXH9xMuS4OEUdxD8YZu7iDAh 460 O5U4WNhhNsOSs7ON9kvcbj9ClG60FpOatWEQqfrZWgJn09rZOsZW6QtSNZDANcY1 461 o8vd8dTzgww8gOzaHbhvCqfuN31ITYAbAm2VruaRarFYL51X1eyR87oePa3GPoZv 462 MKXFcIzIk8yu79dWU8HtdcPtlzLd2d90hp9mem1/afpribjc32xHPBHqzTvaTH+h 463 mGO0IY5Hy/PmHS9i/EV3VHTI0cb2SNba4xqhiobxqq9l6qHSHqDkO26j4Fc7xYZ6 464 b3MgWFyIvO4TGzPOMJVQ7JG0iUuIgK/gESEpx826fwXHDZa6aG3SqRet9hS7ciGE 465 turVnJj2YMEHN04TlarkXtXWaw1kCB/fP1809yH3XYTqTted7vLKi77cvLvo5o+8 466 LJXqah+1O0wbSl3ZdBsDIaOcbPYeMPNQkxTXYdApXQwdEzPKEJNNH1VD98fjdBOK 467 4iiz0uCr6mHQRAAxB941fTgv5HoPYCyZeGEhufcSoF9ZTTbPGUBNBM5RmT9eynI/ 468 EoWABxcbht4kCB97b+G0cO8Yus+K4fENGeaftTzbZNl/gBvHkRca6uadAdEzbgYq 469 KkMCXPdpYGmghEtbSsxJkybfzu7+Ak5kfEi8CYQ9yMLWuB/LLc8NKcYvHtI6Z19L 470 60223aTpDKbnLDaemOykSYg525zhq1HEcjtYimZe5xok3zPCSyqNNuJ8z3CzFw/3 471 hgxuJvQi9rQwF7dCIGkP/45Guxgovmcy1pt6iaC8n2+cYpduEIUbyJa2D6yFSf26 472 pI5u7EDvdhgTO0gAYQj6Fy+HP8pdaGUudH4gBIRRKTsUGhwVWLotefBJp8HbDI67 473 m0Gn+58Xzra3OgIdTltheWEwinpp5iXZuSaBVjHOwg7+8/k8CbIgGlmTeKB6YWJl 474 d+VNkT+Ok+KufaHPnkdA6iofFSfHsb9MKN/1XUfsLKZr1HRjfX3/4E2mIRS2ZJZm 475 RkGrjBWVgb5pvJ1loAKc8bQKDMSKI0xxA6cS2dJFePvLCWQ7QlDEWI5TyAsJ4MT6 476 JQUWwFUd4nQwkwB4l7XVa51txnU8mQYh9I8lYNOtWMXQ5fUH8e8P2gMY17ru/xL0 477 5qiF8H6OvYEBM2XHuIVSRg3Gjdss9r+M43ACsj/fv3v/SXvt92T0xuAcY0IsShk7 478 BqKBxgOZd1rYxQrQxHVdhzYATWwkBaIO62BObbQFz9dgvQdMs9ZFXke95Qcwy39b 479 vVXWxAvCnhFAGH/NCvjavverKuqw7ceT3El/qrue/hGnIu+W231vJxdqMpDFmFJ/ 480 pTCqA22xadXcf/PuVLirYjIAMJdMx3DpIk4QWXORhAEa5mZeg1Utx4osc2zHJc0m 481 DonmEtvF1KX1hbVZHduI6V26W5SPrOVUOa3Hk0kcNchMbm9FvU24r5NsadbXdmH/ 482 W08MUu41Kud211HULH8twRG2S/R7o2ZwMAHeKBg+SnBulVbz02xyB4XvgPAQ8mOG 483 5zq4D3zjsxoFsLsgYYUznhWytnwCKmVz5gp5jJBBZ/Wi4GvJGA8IGf9BQwalOZ4A 484 XOOhcapp9NkzY0URrf9oUdJmaWOMHXac2jeLsuTxoDC5P2iYStMhStX02h6rZVPd 485 p2fmA/H2nrlqle2Dfws+9Mwj0FoqS2YTwaELt8FjOf8LQpmAiX/x4y/BrqAdC6o3 486 iLn+qucqrofotqa56xXA0uSjs9CdsKQHFvxXzUa3E1C25Q3ax1kE1G8E1Um/I093 487 4b0Ve0Qyx1lv/VjaSAhOvi34ClJgrLGC1wS/A5vXPxR+WFKOOOYWzLnkOdCjMEwR 488 4WCyBj0GMCIuF98Wei3k5jUh78B+/A9F3u1cDe6AjBlvr46LO0FtKij+1u22ydNe 489 EeIaHPX/iFshTu3LJ6u/XF3o/9G9PPkbr+DaC2ssAAA= 491 Authors' Addresses 493 Stefan Santesson 494 3xA Security (AAA-sec.com) 495 Bjornstorp 744 496 247 98 Genarp 497 Sweden 498 EMail: sts@aaa-sec.com 500 Russell Housley 501 Vigil Security, LLC 502 918 Spring Knoll Drive 503 Herndon, VA 20170 504 USA 505 EMail: housley@vigilsec.com 507 Siddharth Bajaj 508 VeriSign 509 685 East Middlefield rd 510 Mountain view, CA 94043 511 USA 512 Email: sbajaj@verisign.com 514 Leonard Rosenthol 515 3533 Sunset Way 516 Huntingdon Valley, PA 19006 517 USA 518 Email: leonardr@adobe.com