INTERNET-DRAFT Stefan Santesson (3xA Security) Intended Status: Proposed Standard Russ Housley (Vigil Security) Updates: 3709 (once approved) Siddharth Bajaj (VeriSign) Expires: February 26, 2010 Leonard Rosenthol (Adobe) August 25, 2009 Internet X.509 Public Key Infrastructure: Certificate Image <draft-ietf-pkix-certimage-01.txt> Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document specifies a method to bind a visual representation of a certificate in the form of a certificate image to a [RFC5280] public key certificate by defining a new otherLogos image type according to [RFC3709]. Santesson et all. Expires February 26, 2010 [Page 1]
INTERNET DRAFT Certificate Image August 25, 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Certificate Image . . . . . . . . . . . . . . . . . . . . . . . 5 3 LogotypeImageInfo . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Certificate Image Formats . . . . . . . . . . . . . . . . . . . 6 4.1 PDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 PNG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5 Embedded images . . . . . . . . . . . . . . . . . . . . . . . . 7 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 8.2 Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 12 Santesson et all. Expires February 26, 2010 [Page 2]
INTERNET DRAFT Certificate Image August 25, 2009 1. Introduction This standard specifies a Certificate Image that may be signed and referenced by a certificate as a visual representation of that certificate to humans. This standard makes use of the certificate Logotype extension defined in [RFC3709] and specifies the Certificate Image as a new otherLogos type. The purpose of the Certificate image is to enable a meaningful informational and visual experience for a human user in situations where a Graphical User Interface (GUI) of an application needs to show a certificate to a user. Typical situations when an application may want to show a certificate to a human are: - A person establishes contact with an authenticated entity, such as a commercial web site or government service. The person wants to see the authenticated identity of the service provider. - A person consumes signed information such as a signed e-mail, a signed document, or a signed contract. The person wants to see the authenticated identity of the signer. - A person is requested to authenticate to a service, or to sign some information, and is requested to select an appropriate certificate for the purpose. The person needs to see the available certificates to understand what type of personal data they contain and for what purpose they are intended. Unless an application recognizes the certificate type and has some predefined display logic for the certificate it displays, it will extremely hard for the application to provide meaningful information about the certificate to humans. Some important reasons are: - Many common attributes are not specific enough to identify their information content. For example, the country attribute includes a country identifier but does not define whether this represents a country of residence, country of citizenship or something else. The attribute SRIALNUMBER may contain any type of identifier such as social security number, membership number or driver's license number. - Some name forms are suitable for human consumption and others Santesson et all. Expires February 26, 2010 [Page 3]
INTERNET DRAFT Certificate Image August 25, 2009 for machine processing. It is extremely hard for a certificate viewer to know exactly which name types that make sense to a human and how to label this information in the user interface. RFC 3709 specifies how to bind images to a certificate, such as community logo, issuer logo. RFC 3709 is also extensible and allows inclusion of new image types using the other-Logos structure. This extensibility is used in this standard to allow inclusion of a complete certificate display image. 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Santesson et all. Expires February 26, 2010 [Page 4]
INTERNET DRAFT Certificate Image August 25, 2009 2 Certificate Image This section defines the Certificate Image as a new otherLogos type according to section 4.1 of [RFC3709]. The Certificate Image otherLogos type is identified by the Object Identifier (OID) id-logo-certimage. id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-logo OBJECT IDENTIFIER ::= { id-pkix 20 } id-logo-certimage OBJECT IDENTIFIER ::= { id-logo TBD } //* Note: TBD is to be replaced by a real OID before publication of this draft *// When present the Certificate Image MUST represent a complete visual representation of the certificate. This means that the display of this certificate image represents all information about the certificate that the issuer subjectively defines as relevant to show a typical human user within the typical intended use of the certificate, giving adequate information about at least the following three aspects of the certificate: - Certificate Context - Certificate Issuer - Certificate Subject Certificate Context information is visual marks and/or textual information which helps the typical user to understand the typical usage and/or purpose of the certificate It is up to the issuer to decide what information in the form of text and graphical symbols and elements, which represents a complete visual representation of the certificate. Applications providing a Graphical User Interface (GUI) to the certificate user MAY present a Certificate Image according to this standard in any given application interface, as the only visual representation of a certificate. 3 LogotypeImageInfo The optional LogotypeImageInfo structure is defined in [RFC3709] and is included here for convenience: Santesson et all. Expires February 26, 2010 [Page 5]
INTERNET DRAFT Certificate Image August 25, 2009 LogotypeImageInfo ::= SEQUENCE { type [0] LogotypeImageType DEFAULT color, fileSize INTEGER, -- In octets xSize INTEGER, -- Horizontal size in pixels ySize INTEGER, -- Vertical size in pixels resolution LogotypeImageResolution OPTIONAL, language [4] IA5String OPTIONAL } -- RFC 3066 Language Tag When the optional LogotypeImageInfo is included with a certificate image, the parameters shall be used with the following semantics and restrictions. xSize and ySize represents recommended display size for the image. When a value of 0 (zero) is present, no recommended display size specified. When non-zero values are present and these values differ from corresponding size values in the referenced image file, then the referenced image SHOULD be scaled to fit within the size parameters of LogotypeImageInfo, while keeping x and y ratio intact. Resolution MUST NOT be specified. 4 Certificate Image Formats 4.1 PDF A Certificate Image MAY be provided in the form of a Portable Document Format (PDF) document according to [ISO32000] following the conventions defined in this section. When a certificate image is formatted as a PDF document, it MUST also be formatted according to the profile PDF/A [ISO19005]. When including a PDF document as Certificate Image, the following MIME media type as specified in [RFC3778] MUST be used as mediaType in LogotypeDetails: application/pdf 4.2 SVG A Certificate Image MAY be provided in the form of a Scalable Vector Graphic (SVG) image, which MUST follow the SVG Tiny profile [SVGT1.2] The following MIME media type defined in Appendix M of [SVGT1.2] MUST be used as mediaType in LogotypeDetails for SVG images: image/svg+xml Santesson et all. Expires February 26, 2010 [Page 6]
INTERNET DRAFT Certificate Image August 25, 2009 The SVG image file MUST NOT incorporate any external image data by reference to an external SVG document, or by reference to an external media source other than SVG. Doing so would incorporate image data that is not covered by the logotypeHash value of the image. Certificate using applications MUST reject any image that violates this rule. The XML structure in the SVG file MUST use <LF> (linefeed 0x0A) as end-of-line (EOL) character when calculating the hash over the SVG file. The referenced SVG file may be provided in compressed form, for example as SVG.GZ or SVGZ. It is outside the scope of this specification to specify any such compression algorithm. However, after decompression the EOL characters of the SVG file MUST be normalized according to this section before computing the hash of the SVG file. 4.2 PNG If a certificate image is provided as a bit mapped image, the PNG [ISO15948] format SHOULD be used. PNG images are identified by the following mediaType in LogotypeDetails: image/png 5 Embedded images The certificate image otherLogos type MAY be stored within the logotype extension using the "data" URL scheme defined in RFC 2397 [RFC2397] if the logotype image is provided through direct addressing, i.e. the image is referenced using the LogotypeDetails structure. The syntax of Logotype details defined in RFC 3709 is included here for convenience: LogotypeDetails ::= SEQUENCE { mediaType IA5String, -- MIME media type name and optional -- parameters logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue, logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String } Santesson et all. Expires February 26, 2010 [Page 7]
INTERNET DRAFT Certificate Image August 25, 2009 When including the image data in the logotype extension using the "data" URL scheme the following conventions apply. - the value of mediaType MUST be identical to the mediatype value in the "data:" URL. - The hash of the image MUST be included in logotypeHash and MUST be calculated over the same data as it would have been, had the image been referenced through a link to an external resource. Note: As the "data:" URL scheme is processed as a data source rather than as a URL, the image data is typically not limited by any URL length limit setting that otherwise apply to URLs in general. Note: Implementations need to be cautious about the the size of images included in a certificate in order to ensure that the size of the certificate does not prevent the certificate to be used as intended. Santesson et all. Expires February 26, 2010 [Page 8]
INTERNET DRAFT Certificate Image August 25, 2009 6 Security Considerations The security considerations of [RFC3709] apply also to this standard. This standard makes it possible for a CA to issue a certificate with a Certificate Image that is in conflict with other data included in the certificate without the relying party application being able to detect the delta. A relying party application MUST decide that the certificate is valid and trustworthy enough to provide a Certificate Image to the local GUI before using it. Referenced image files are hashed in order to bind the image to the signature of the certificate. Some image types, such as SVG allow part of the image to be collected from external source by incorporating a reference to an external image file. If this feature were used within a certificate image file, the hash of the image file would only cover the URI reference to the external image file, but not the referenced image data. To ensure that the hash of the certificate image covers the whole image, implementations of this standard MUST reject images that incorporate parts of the image by reference to external image files. CAs issuing certificate with embedded certificate images should be cautious when accepting graphics from the certificate requestor for inclusion in the certificate, if the hash algorithm used to sign the certificate is vulnerable to collision attacks. In such case the accepted image may contain data that could help an attacker to obtain colliding certificates with identical certificate signatures. 7 IANA Considerations This document requires no actions from IANA. 8 References 8.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [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 Santesson et all. Expires February 26, 2010 [Page 9]
INTERNET DRAFT Certificate Image August 25, 2009 [RFC3709] S. Santesson, R. Housley, T. Freeman, "Internet X.509 Public Key Infrastructure Logotypes in X.509 Certificates", RFC 3709, February 2004 [RFC2397] L. Masinter, 'The "data" URL scheme' RFC 2397, August 1998 [ISO32000] ISO 32000-1:2008, "Document management - Portable document format" -- Part 1: PDF 1.7, April 2008 [ISO19005] ISO 19005-1:2005, "Document Management - Electronic document file format for long term preservation - Part 1: Use of PDF 1.4 (PDF/A-1)", 2005 [ISO15948] ISO/IEC 15948:2004, "Information technology - Computer graphics and image processing -- Portable Network Graphics (PNG): Functional specification", 2004 [SVGT1.2] W3C Recommendation, "Scalable Vector Graphics (SVG) Tiny 1.2 Specification", December 2008 8.2 Informative References [RFC3778] E. Taft, J. Pravetz, S. Zilles, L. Masinter "The application/pdf Media Type", RFC 3778, May 2004 Santesson et all. Expires February 26, 2010 [Page 10]
INTERNET DRAFT Certificate Image August 25, 2009 Authors' Addresses Stefan Santesson 3xA Security (AAA-sec.com) Bjornstorp 744 247 98 Genarp Sweden EMail: sts@aaa-sec.com Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Siddharth Bajaj VeriSign 685 East Middlefield rd Mountain view, CA 94043 USA Email: sbajaj@verisign.com Leonard Rosenthol 3533 Sunset Way Huntingdon Valley, PA 19006 USA Email: leonardr@adobe.com Santesson et all. Expires February 26, 2010 [Page 11]
INTERNET DRAFT Certificate Image August 25, 2009 Full Copyright Statement Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Santesson et all. Expires February 26, 2010 [Page 12]
