[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 draft-ietf-pkix-certimage

INTERNET-DRAFT                          Stefan Santesson (3xA Security)
Intended Status: Proposed Standard        Russ Housley (Vigil Security)
Expires October 2009                         Siddharth Bajaj (VeriSign)
                                              Leonard Rosenthol (Adobe)

                                                             April 2009
               Internet X.509 Public Key Infrastructure:
                           Certificate Image

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   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

Santesson et all.                                               [Page 1]

INTERNET DRAFT             Certificate Image                  March 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

   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 recognize 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

      - Some name forms are suitable for human consumption and others

Santesson et all.                                               [Page 2]

INTERNET DRAFT             Certificate Image                  March 2009

      for machine processing. It is extremely hard for a certificate
      viewer to know exactly which name types that makes 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.1  Outstanding issues

   This section lists issues that should be resolved before publication
   of the standard. When these issues are resolved, this section will be

   Issue: embedded images

      RFC 3709 specifies how to reference images through a URL, but does
      not specify any means to store referenced images in the
      certificate itself. It will remain outside of the scope of this
      specification to define any means to embed certificate images in
      the certificate. However, a complementing standard could be
      defined, specifying the syntax of URL references pointing to
      images stored in a separate local extension embedded in the

   Issue: Image formats

      This draft recommends that certificate images are stored in a
      scalable format and specifically defines how to include images in
      PDF/A [ISO19005] and SVG Tiny [SVGT1.2] format. A third popular
      scalable vector graphic format VML (Vector graphic Markup
      Language) is not a public standard. Nevertheless, some
      implementers have chosen to support VML instead of SVG. It might
      therefore be useful to specify how to reference a VML formatted
      certificate image in an informational annex.

1.2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Santesson et all.                                               [Page 3]

INTERNET DRAFT             Certificate Image                  March 2009

2  Certificate Image

   This section defines the Certificate Image as a new otherLogos type
   as defined in 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.                                               [Page 4]

INTERNET DRAFT             Certificate Image                  March 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

   xSize and ySize represents recommended display size for the image.
   When a value of 0 (zero) is present, no recommended display size

   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 Logotype Details:


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]

   When including a PDF document as Certificate Image, the following
   MIME media type defined in Appendix M of [SVGT1.2] MUST be used as
   mediaType in Logotype Details:


   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

Santesson et all.                                               [Page 5]

INTERNET DRAFT             Certificate Image                  March 2009

   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.

Santesson et all.                                               [Page 6]

INTERNET DRAFT             Certificate Image                  March 2009

5  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.

6  IANA Considerations

   IANA considerations

7  References

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

   [RFC3709]  S. Santesson, R. Housley, T. Freeman, "Internet X.509
              Public Key Infrastructure Logotypes in X.509
              Certificates", RFC 3709, February 2004.

   [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.

   [SVGT1.2]  W3C Recommendation, "Scalable Vector Graphics (SVG)
              Tiny 1.2 Specification", December 2008.

7.2 Informative References

Santesson et all.                                               [Page 7]

INTERNET DRAFT             Certificate Image                  March 2009

   [RFC3778]  E. Taft, J. Pravetz, S. Zilles, L. Masinter "The
              application/pdf Media Type", RFC 3778, May 2004

Santesson et all.                                               [Page 8]

INTERNET DRAFT             Certificate Image                  March 2009

Authors' Addresses

   Stefan Santesson
   3xA Security (AAA-sec.com)
   Bjornstorp 744
   247 98 Genarp
   EMail: sts@aaa-sec.com

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   EMail: housley@vigilsec.com

   Siddharth Bajaj
   685 East Middlefield rd
   Mountain view, CA 94043
   Email: sbajaj@verisign.com

   Leonard Rosenthol
   3533 Sunset Way
   Huntingdon Valley, PA 19006
   Email: leonardr@adobe.com

Santesson et all.                                               [Page 9]

INTERNET DRAFT             Certificate Image                  March 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/licenseinfo).
   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

Expires October 2009

Santesson et all.                                              [Page 10]

Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/