GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6170

Internet Engineering Task Force (IETF) S. Santesson Request for Comments: 6170 3xA Security Updates: 3709 R. Housley Category: Standards Track Vigil Security ISSN: 2070-1721 S. Bajaj

                                                        Symantec Corp.
                                                          L. Rosenthol
                                                                 Adobe
                                                              May 2011
   Internet X.509 Public Key Infrastructure -- Certificate Image

Abstract

 This document specifies a method to bind a visual representation of a
 certificate in the form of a certificate image to a public key
 certificate as defined in RFC 5280, by defining a new "otherLogos"
 image type according to RFC 3709.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6170.

Copyright Notice

 Copyright (c) 2011 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.

Santesson, et al. Standards Track [Page 1] RFC 6170 Certificate Image May 2011

Table of Contents

 1. Introduction ....................................................2
    1.1. Terminology ................................................3
 2. Certificate Image ...............................................3
 3. LogotypeImageInfo ...............................................4
 4. Embedded Images .................................................5
 5. Certificate Image Formats .......................................6
    5.1. PDF ........................................................6
    5.2. SVG ........................................................6
    5.3. PNG ........................................................7
 6. Security Considerations .........................................7
 7. Acknowledgements ................................................8
 8. References ......................................................9
    8.1. Normative References .......................................9
    8.2. Informative References .....................................9
 Appendix A.  ASN.1 Module .........................................10
 Appendix B.  Example ..............................................11

1. Introduction

 This standard specifies how to bind a certificate image to a
 certificate (defined in [RFC5280]), providing a visual representation
 of that certificate using the Logotype extension defined in [RFC3709]
 and specifying the certificate image as a new "otherLogos" type.
 The purpose of the certificate image is to aid human interpretation
 of a certificate by providing meaningful visual information to the
 user interface (UI).
 Typical situations when a human needs to examine the visual
 representation of a certificate are:
  1. A person establishes a secured channel with an authenticated

service. The person needs to determine the identity of the

    service based on the authenticated credentials.
  1. A person validates the signature on critical information, such as

signed executable code, and needs to determine the identity of the

    signer based on the signer's certificate.
  1. A person is required to select an appropriate certificate to be

used when authenticating to a service or Identity Management

    infrastructure.  The person needs to see the available
    certificates in order to distinguish between them in the selection
    process.

Santesson, et al. Standards Track [Page 2] RFC 6170 Certificate Image May 2011

 The display of certificate information to humans is challenging due
 to lack of well-defined semantics for critical identity attributes.
 Unless the application has out-of-band knowledge about a particular
 certificate, the application will not know the exact nature of the
 data stored in common identification attributes such as serialNumber,
 organizationName, country, etc.  Consequently, the application can
 display the actual data, but faces the problem of labeling that data
 in the UI and informing the human about the exact nature (semantics)
 of that data.  It is also challenging for the application to
 determine which identification attributes are important to display
 and how to organize them in a logical order.
 RFC 3709 [RFC3709] defines a certificate extension for binding images
 to a certificate, such as a community logo and issuer logo, enhancing
 the display of certificate information.  The syntax is extensible and
 allows inclusion of new image types using the otherLogos structure.
 This standard defines how to include a complete certificate image
 using the extensibility mechanism of RFC 3709.

1.1. 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].

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 3 }
 When present, the certificate image MUST be 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
 to 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:

Santesson, et al. Standards Track [Page 3] RFC 6170 Certificate Image May 2011

  1. Certificate Context
  1. Certificate Issuer
  1. Certificate Subject
 Certificate Context information is visual marks and/or textual
 information that 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, graphical symbols, and elements -- represents a complete visual
 representation of the certificate.  However, the visual
 representation of Certificate Subject and Certificate Issuer
 information from the certificate MUST have the same meaning as the
 textual representation of that information in the certificate itself.
 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:
   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
 NOTE: The referenced RFC 3066 in the structure above (from RFC 3709)
       is obsolete and is currently replaced by RFC 5646 [RFC5646].
       The language tag may carry information about the language used
       to express any textual elements within the image as well as any
       audio information associated with the image.
 When the optional LogotypeImageInfo is included with a certificate
 image, the parameters shall be used with the following semantics and
 restrictions.
 xSize and ySize represent the recommended display size for the image.
 When a value of 0 (zero) is present, no recommended display size is
 specified.  When non-zero values are present and these values differ

Santesson, et al. Standards Track [Page 4] RFC 6170 Certificate Image May 2011

 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 the x and y ratio intact.
 The resolution parameter is redundant for all image formats that are
 relevant for certificate images and MUST NOT be specified.

4. Embedded Images

 The certificate image otherLogos type defined in this specification
 and all logotype types defined in RFC 3709 [RFC3709] 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 (see Section 5)
       logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
       logotypeURI     SEQUENCE SIZE (1..MAX) OF IA5String }
 The syntax of the "data" URL scheme defined in RFC 2397 is included
 here for convenience:
    dataurl    := "data:" [ mediatype ] [ ";base64" ] "," data
    mediatype  := [ type "/" subtype ] *( ";" parameter )
    data       := *urlchar
    parameter  := attribute "=" value
 When including the image data in the logotype extension using the
 "data" URL scheme, the following conventions apply.
  1. The value of mediaType in LogotypeDetails MUST be identical to the

media type value in the "data" URL.

  1. 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 settings that otherwise apply to URLs in
       general.

Santesson, et al. Standards Track [Page 5] RFC 6170 Certificate Image May 2011

 NOTE: Implementations need to be cautious about the size of images
       included in a certificate in order to ensure that the size of
       the certificate does not prevent the certificate from being
       used as intended.

5. Certificate Image Formats

 Implementations of this specification MUST support JPEG and GIF as
 defined in RFC 3709 [RFC3709].  In addition to these mandatory-to-
 implement formats, this specification specifies the use of the
 Portable Document Format (PDF), Scalable Vector Graphics (SVG), and
 Portable Network Graphics (PNG) as image formats.

5.1. PDF

 A certificate image MAY be provided in the form of a Portable
 Document Format (PDF) document according to [ISO32000] and 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 a certificate image, the following
 MIME media type as specified in [RFC3778] MUST be used as mediaType
 in LogotypeDetails:
    application/pdf

5.2. SVG

 A certificate image MAY be provided in the form of a Scalable Vector
 Graphics (SVG) image, which MUST follow the SVG Tiny profile [SVGT]
 with the following amendments:
  1. The SVG image MUST NOT contain any Internationalized Resource

Identifier (IRI) references to information stored outside of the

    SVG image of type B, C, or D, according to Section 14.1.4 of SVG
    Tiny 1.2 [SVGT].
  1. The SVG image MUST NOT contain any 'script' element, according to

Section 15.2 of SVG Tiny 1.2 [SVGT].

  1. The XML structure in the SVG file MUST use <LF> (linefeed 0x0A) as

the end-of-line (EOL) character when calculating a hash over the

    SVG image.
 The referenced SVG file MAY be provided in GZIP-compressed [RFC1952]
 form as an SVGZ file.  In this case, the extension 'svgz' is used as
 an alias for 'svg.gz' [RFC1952], i.e., octet streams of type

Santesson, et al. Standards Track [Page 6] RFC 6170 Certificate Image May 2011

 image/svg+xml, subsequently compressed with gzip as specified in
 [SVGR].  The hash over the SVGZ file is calculated over the
 decompressed SVG content with canonicalized EOL characters (<LF>) as
 specified above.
 The following MIME media type, defined in Appendix M of [SVGT], MUST
 be included as mediaType in LogotypeDetails for all SVG and SVGZ
 images:
    image/svg+xml
 When the SVG image is embedded using the "data" URL scheme as defined
 in Section 4, SVG image data MUST be provided in SVGZ (GZIP
 compressed) form (i.e., it MUST NOT be provided in uncompressed SVG
 form).
 Compliant implementations of this specification SHOULD be able to
 process SVG images that are formatted according to this section.

5.3. PNG

 If a certificate image is provided as a bitmapped image, the PNG
 [ISO15948] format SHOULD be used.
 PNG images are identified by the following mediaType in
 LogotypeDetails:
    image/png

6. Security Considerations

 This document is based on and inherits all security considerations
 from RFC 3709 [RFC3709].  In particular, RFC 3709 discusses several
 issues a Certificate Authority (CA) should take into consideration
 when evaluating a request to issue a certificate with a certificate
 image.
 Images incorporated according to RFC 3709 provide an additional
 possibility for a CA with bad intentions or bad security procedures
 to include false, conflicting, or malicious information to relying
 parties.  Such a CA may, for example:
  1. include information in graphical form that is in conflict with

information in provided text-based attributes or other name forms,

    and
  1. include malicious data that could exploit known security bugs in

common software libraries used to render graphical images.

Santesson, et al. Standards Track [Page 7] RFC 6170 Certificate Image May 2011

 This underlines the necessity for CAs to provide reliable services,
 and the relying party's responsibility and need to carefully select
 which CAs are trusted to provide public key certificates.
 This also underlines the general necessity for relying parties to use
 up-to-date software libraries to render or dereference data from
 external sources (such as certificates), to minimize risks related to
 processing potentially malicious data before the data has been
 adequately verified and validated.
 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 an 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.  Clients SHOULD verify that SVGT
 images meet all requirements listed in Section 5.2 and reject images
 that contain references to external data.
 CAs issuing certificates 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 a case, the
 accepted image may contain data that could help an attacker to obtain
 colliding certificates with identical certificate signatures.
 Certificates, and hence their certificate images, are commonly public
 objects and as such usually will not contain privacy-sensitive
 information.  However, when a certificate image that is referenced
 from a certificate contains privacy-sensitive information,
 appropriate security controls should be in place to protect the
 privacy of that information.  Details of such controls are outside
 the scope of this document.

7. Acknowledgements

 The authors recognize valuable contributions from members of the PKIX
 working group, the CA Browser Forum, and James Manger, for their
 review and sample data.

Santesson, et al. Standards Track [Page 8] RFC 6170 Certificate Image May 2011

8. References

8.1. Normative References

 [RFC1952]   Deutsch, P., "GZIP file format specification version
             4.3", RFC 1952, May 1996.
 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2397]   Masinter, L., "The "data" URL scheme", RFC 2397, August
             1998.
 [RFC3709]   Santesson, S., Housley, R., and T. Freeman, "Internet
             X.509 Public Key Infrastructure: Logotypes in X.509
             Certificates", RFC 3709, February 2004.
 [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.
 [RFC5646]   Phillips, A., Ed., and M. Davis, Ed., "Tags for
             Identifying Languages", BCP 47, RFC 5646, September 2009.
 [ISO15948]  ISO/IEC 15948:2004, "Information technology -- Computer
             graphics and image processing -- Portable Network
             Graphics (PNG): Functional specification", 2004.
 [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.
 [ISO32000]  ISO 32000-1:2008, "Document management -- Portable
             document format -- Part 1: PDF 1.7", April 2008.
 [SVGT]      W3C Recommendation, "Scalable Vector Graphics (SVG) Tiny
             1.2 Specification", December 2008.

8.2. Informative References

 [RFC3778]   Taft, E., Pravetz, J., Zilles, S., and L. Masinter, "The
             application/pdf Media Type", RFC 3778, May 2004.
 [SVGR]      "Media Type Registration for image/svg+xml",
             http://dev.w3.org/SVG/profiles/1.1F2/master/mimereg.html.

Santesson, et al. Standards Track [Page 9] RFC 6170 Certificate Image May 2011

Appendix A. ASN.1 Module

 CERT-IMAGE-MODULE { iso(1) identified-organization(3) dod(6)
     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-logotype-certimage(68) }
 DEFINITIONS EXPLICIT TAGS ::=
 BEGIN
   EXPORTS ALL;   -- export all items from this module
     id-logo-certImage  OBJECT IDENTIFIER  ::=
           { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-logo(20) 3 }
 END

Santesson, et al. Standards Track [Page 10] RFC 6170 Certificate Image May 2011

Appendix B. Example

 The following example stores an embedded svgz-encoded SVG image using
 the "data" URL scheme.
    data:image/svg+xml;base64,H4sICLXutU0AA0NlcnRJbWFnZURlbW8uc3ZnANVa
    W2/bOBZ+n19BqBigwdoS7xK9jmeapB0EWHQHzez2WZZoR1tZMiQ5jvvr95CSL7Gl1E
    m8C9d9iERSPOd85+O5EB3+9jhL0YMuyiTPLh3iYgfpLMrjJJteOv/661M/cFBZhVkc
    pnmmL50sd34b/TIsH6YoiS+da11UySSJwkqj21k41Q6CDbNyUMSTS+e+quYDz1sul+
    6SuXkx9YhSysPUo7QPK/rlKqvCx35Wvmu+a/uGYow9EOigh0Qvr/LHSwcjjDjGiGHQ
    914n0/sKlMf4Vwctk7i6X7/sGEYdNA5L/WeRT5IUDKmSbLVWNoo2cqNCh1XyoKN8Ns
    uz0iqwVW8Qb1fOF0Vqp+PI06me6awqPeISzxn9goYzXYVxWIUWpfWLCMwcGoLpgy83
    n8wzGkbR4GtefENmMBznC7DEroKpOBpM8mIWVqPEYGtA+BvoMfS2E5uF1Wqu7R6FLv
    NFEelWReNolpiV3l2VpGntMW9nk6RKdf0+9BrFrMbeVuWhtzbHvMR6UlobPyVpBWjX
    Bk7six2vH5nCwY6nXCo5xb7YusvFVPqCOGh16fSxSxglmPkScLfvmDDmC4FlDc1wov
    8IF2WZhNlVumgEPRliimDD3PhGPyTgUUMC6lKqKAjxaptq1boUJvQFsvi+LOJyxZkP
    E/vCwHuAmXmoj1AarnRBatzqkbv7cK5Ls2ORfwM/vsOG5lURZqXxOnDXPKZw5t5jVz
    IhFKO0B6D6hARSXDR6Fzqq7H7mQeJAOQiUSPvFIrUHOfuui3zrFI5dYVeAmpcOcOb9
    u63vLjae4kYX4yRifYPrTa2SlMigYdO+cEWeGADMLZLH96SH4R9xRYApl6q3Y02f+N
    zlRAl+cZSKhB6qSIVa80fsqMnWOqZJpmsXwAPoyNaQ95uNIGasKPwhxGzQzOXzMIIz
    BKabmLIil470zfSjWWn+kvpvLQ9g1l3yRIc8gukz0uysEcakcDfy3KMk+l0SOXlOop
    ltJL7EPtUlzZfP4tnM70k8xkKCySt92MwfIXPoTe0pnu4dYbp7hJ/kxWySN0ey0o/1
    qbiCsxDXJMWWo37QekBcAUFPSGkPCnUJF5wwBacDK5cGlEp4BC2lYoJcrNNGVc7DzI
    qxT4CKsPlrAG8mL8whRejiQe9EmImIAoz3sds9NxP4RZEzugqzb7c3Q89u3WQKY9ae
    gbsA/AUJB/bJs6pfJt9BHFEuk5DWITzOH5uZSThLUsDjQ5GE6RMsyihMTaQLfA6BIi
    AQMAhnHHN1sd61WtUhDVJiuhkrdBXd740+hLB9Vm1HjQe4ywLOBLWOMMiyQAXNB8sm
    9Gx2qdGgGkMG6wY8aLfqgH4dfnmrVc+pPrE/Z/QnZOs8C1Okb2/ggwLdxlDC1D6DFP
    ZDD98txv8xQf5TEc7Ax6ZyaDf6BC4SylWKCMqtizp80+UMchATal63qHq0M3ZTs83O
    b/XO6LYsFzpGVY5+iLxdWvwY+NaKoR/0iJIXL3dBjT2hG+wO+NXm53XStSh1eogfeo
    jV35BTOaqh/cmPUe2Mdp91pQp2CjWOO2k7OamhjU1HB3DLGm66n6iajz4bqn2oICmN
    FxDR/x2mC5s+rKhlkUA3Ne3P8lgP0qJfjf9uvu+HWXSfFwNoH4uqGUmTadYMtOc7yj
    EEd9EUhkwEEOcDSHKQ+yhnSvUYRH8miQo2FK5TCjWZZGWKB8iHPud16wApnCvTOzjI
    FAj9TQdCxa+ddOTizaa1xJvD0qMrKx+Ydaj6iwJQG0vaSdYWpTv4HwVRAP3Z6ONjOJ
    unEIeKRVmhujpA2+wPmQR9WFQAFhh9bGQzFEXX+WwOnXq8pV35P2Acdn0pGebcMg7O
    gQKaEdOKEAkFlk/9HuEKGBVwucc4AjnJ/LBYU09hVwWY1F0HlBUC2lbyIuYF58O8p+
    adMwUt9YAoX/IwRtAC9NAdBAyGuEB3VR59u8/TGYx9/Xjz8bPB/Z/F9B0SghBK+4xx
    fiwtr0GXECqedQQ9PRVpEAQ+26MidbGSmPm8RwRzcQsT17EPSmoorH3+av4Jcj78O/
    vIp/uzMEkHKAE6/F7VHHSj8HddR0Q3ymcGZfRVjwfmOnNn3GuWR+FzhcPmPqiptHca
    yacT28T8j3Cs0/LQCwo6J2iYxP4R58AsobjFegusoJhuq7VNS2evRPcqASvQki+gbk
    BYwETNPt/1A2pT6UErR1zMzUITZRvF5Lp5basO1fk2U4aBSjkji8quL3cDyW7TpI3u
    nxezMcSTNhQJhfpGctKgKN2Amo7/7ShSev4oXicPSYS+6GkCm9a1Qw3VEchCUA+z5H
    tTcbQhK6F14YFUp+Yn7WgmzwpZCDf5DDiXT9B7U6RdHAHpdb7IqmLVjqZSLnTW61zj
    Q7/G7D3hm9E846uTDZoNMADmLlm7IG2ieXfUtu1US9TeNGUHibE9Nv//2jRJGZfQmK
    3v7ykJJOv1IXjBsDCPpmgWppe6sHxR3KVSQKqp+WIqammuJbtqkxZmMHry4oS/9pLh
    dCXKq8uR0R+LDEqCKRxqc5VXdvPvIP+ggwR0RkyBfO9iKZvrWGAKVdz31cuocvoO/q
    emClFMYEFEH7oI+vpkek4s4bCMBqK+5mHQUlDpE/oylpy+2/6pWXK31PEYagP04epV
    1cE50UMy6IQZeQM7+Ol74Z+eHfpHNc7OjffQ/HeV0X8BopoDkGEkAAA=

Santesson, et al. Standards Track [Page 11] RFC 6170 Certificate Image May 2011

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
 Symantec Corp.
 350 Ellis Street
 Mountain View, CA  94043
 USA
 EMail: siddharthietf@gmail.com
 Leonard Rosenthol
 3533 Sunset Way
 Huntingdon Valley, PA  19006
 USA
 EMail: leonardr@adobe.com

Santesson, et al. Standards Track [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6170.txt · Last modified: 2011/05/03 23:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki