draft-ietf-pkix-logotypes-09.txt

PKIX的RFC英文文档

   caching logotype data.

4. Logotype extension

   This section specifies the syntax and semantics of the logotype
   extension.











Santesson, Housley, & Freeman                                   [Page 7]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


4.1 Extension format

   The logotype extension MAY be included in public key certificates
   [PKIX-1] or attribute certificates [PKIX-AC]. The logotype extension
   MUST be identified by the following object identifier:

      id-pe-logotype  OBJECT IDENTIFIER  ::=
         { iso(1) identified-organization(3) dod(6) internet(1)
           security(5) mechanisms(5) pkix(7) id-pe(1) 12 }

   This extension MUST NOT be marked critical.

   Logotype data may be referenced through either direct or indirect
   addressing. Clients MUST support both direct and indirect addressing.
   Certificate issuing applications MUST support direct addressing, and
   certificate issuing applications SHOULD support indirect addressing.

   The direct addressing includes information about each logotype in the
   certificate, and URIs point to the image and audio data files. Direct
   addressing supports cases where just one or a few alternative images
   and audio files are referenced.

   The indirect addressing includes one reference to an external hashed
   data structure that contains information on the type, content and
   location of each image and audio file. Indirect addressing supports
   cases where each logotype is represented by many alternative audio or
   image files.

   Both direct and indirect addressing accommodate alternative URIs to
   obtain exactly the same item. This opportunity for replication is
   intended to improve availability. Therefore, if a client is unable to
   fetch the item form one URI, the client SHOULD try another URI in the
   sequence. At least one URI in each sequence MUST use the HTTP scheme
   (http://...) [URI]. Clients MUST support retrieval of referenced
   LogoTypeData with HTTP/1.1 [HTTP/1.1].

   The logotype extension MUST have the following syntax:

      LogotypeExtn ::= SEQUENCE {
         communityLogos  [0] SEQUENCE OF LogotypeInfo OPTIONAL,
         issuerLogo      [1] LogotypeInfo OPTIONAL,
         subjectLogo     [2] LogotypeInfo OPTIONAL,
         otherLogos      [3] SEQUENCE OF OtherLogotypeInfo OPTIONAL }

      LogotypeInfo ::= CHOICE {
         direct          [0] LogotypeData,
         indirect        [1] LogotypeReference }




Santesson, Housley, & Freeman                                   [Page 8]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


      LogotypeData ::= SEQUENCE {
         image           SEQUENCE OF LogotypeImage OPTIONAL,
         audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

      LogotypeImage ::= SEQUENCE {
         imageDetails    LogotypeDetails,
         imageInfo       LogotypeImageInfo OPTIONAL }

      LogotypeAudio ::= SEQUENCE {
         audioDetails    LogotypeDetails,
         audioInfo       LogotypeAudioInfo OPTIONAL }

      LogotypeDetails ::= SEQUENCE {
         mediaSubType    IA5String, -- MIME image or audio subtype
         logotypeHash    SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
         logotypeURI     SEQUENCE SIZE (1..MAX) OF IA5String }

      LogotypeImageInfo ::= CHOICE {
         grayScale       [0] LogotypeGrayScaleImageInfo,
         color           [1] LogotypeColorImageInfo }

      LogotypeGrayScaleImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- Horizontal size in pixels
         ySize           INTEGER,  -- Vertical size in pixels
         numLevels       INTEGER } -- # of grayscale levels in bits

      LogotypeColorImageInfo ::= SEQUENCE {
         fileSize        INTEGER,  -- In octets
         xSize           INTEGER,  -- Horizontal size in pixels
         ySize           INTEGER,  -- Vertical size in pixels
         numColors       INTEGER } -- # of colors in bits

      LogotypeAudioInfo ::= SEQUENCE {
         fileSize        INTEGER, -- In octets
         playTime        INTEGER, -- In milliseconds
         sampleRate      INTEGER, -- Samples per second
         channels        INTEGER, -- 1=mono, 2=stereo, 4=quad
         language        IA5String OPTIONAL } -- RFC 3066 Language Tag

      OtherLogotypeInfo ::= SEQUENCE {
         logotypeType    OBJECT IDENTIFIER,
         info            LogotypeInfo }

      LogotypeReference ::= SEQUENCE {
         refStructHash   SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
         refStructURI    SEQUENCE SIZE (1..MAX) OF IA5String }




Santesson, Housley, & Freeman                                   [Page 9]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


      HashAlgAndValue ::= SEQUENCE {
         hashAlg         AlgorithmIdentifier,
         hashValue       OCTET STRING }

   When using indirect addressing, the URI (refStructURI) pointing to
   the external data structure MUST point to a binary file containing
   the DER encoded data with the syntax LogotypeData. The referenced
   file name SHOULD include a file extension of "LTD".

   At least one of the optional elements in the LogotypeExtn structure
   MUST be present. Avoid the use of otherLogos whenever possible.

   The LogotypeReference, LogotypeImage and LogotypeAudio structures
   explicitly identify one or more one-way hash functions employed.
   Clients MUST support the SHA-1 [SHS] one-way hash function, and
   clients MAY support other one-way hash functions. CAs MUST include a
   SHA-1 hash value in every logotypes extension, and CAs MAY include
   other one-way hash values. If more than one is present, clients MUST
   validate at least one value.

   A MIME type is used to specify the format of the file containing the
   logotype data. Implementations MUST support both the JPEG and GIF
   image formats (with MIME types of "image/jpeg" and "image/gif",
   respectively). Animated images SHOULD NOT be used. Implementations
   that support audio MUST support the MP3 audio format (with a MIME
   type of "audio/mpeg").

   When language is specified within the LogotypeAudioInfo structure,
   the language tag MUST use the RFC 3066 [LANGCODES] syntax.

   Logotype types defined in this specification are:

      Community Logotype. If communityLogos is present, the logotypes
      MUST represent one or more communities to which the certificate
      issuer is affiliated. The communityLogos MAY be present in an end
      entity certificate, a CA certificate, or an attribute certificate.
      The communityLogos contains a sequence of Community Logotypes,
      each representing different community. If more than one Community
      logotype is present, they MUST be placed in order of preferred
      appearance. Some clients MAY choose to display a subset of the
      present community logos, therefore the placement within the
      sequence aids the client selection. The most preferred logotype
      MUST be first in the sequence, and the least preferred logotype
      MUST be last in the sequence.

      Issuer Organization Logotype. If issuerLogo is present, the
      logotype MUST represent the issuer's organization. The logotype
      MUST be consistent with, and require the presence of, an



Santesson, Housley, & Freeman                                  [Page 10]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


      organization name stored in the organization attribute in the
      issuer field (for either a public key certificate or attribute
      certificate). The issuerLogo MAY be present in an end entity
      certificate, a CA certificate, or an attribute certificate.

      Subject Organization Logotype. If subjectLogo is present, the
      logotype MUST represent the subject's organization. The logotype
      MUST be consistent with, and require the presence of, an
      organization name stored in the organization attribute in the
      subject field (for either a public key certificate or attribute
      certificate). The subjectLogo MAY be present in an end entity
      certificate, a CA certificate, or an attribute certificate.

   The relationship between the subject organization and the subject
   organization logotype and the relationship between the issuer and
   either the issuer organization logotype or the community logotype,
   are relationships asserted by the issuer. The policies and practices
   employed by the issuer to check subject organization logotypes or
   claims its issuer and community logotypes is outside the scope of
   this standard.

4.2 Other Logotypes

   Logotypes identified by otherLogos (as defined in 4.1) can be used to
   enhance display of logotypes and marks that represent partners,
   products, services, or any other characteristic associated with the
   certificate or its intended application environment when the standard
   logotype types are insufficient.

   The conditions and contexts of the intended use of these logotypes
   are defined at the discretion of the local client application.

   The following other logotype types are defined in this standard:

      - Certificate Background logotype
      - Loyalty logotype

   OID Definitions:

      id-logo OBJECT IDENTIFIER ::= { id-pkix 20 }

      id-logo-loyalty    OBJECT IDENTIFIER ::= { id-logo 1 }
      id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }

   A loyalty logotype, if present, MUST contain a logotype associated
   with a loyalty program related to the certificate or its use. The
   relation between the certificate and the identified loyalty program
   is beyond the scope of this standard. The logotype extension MAY



Santesson, Housley, & Freeman                                  [Page 11]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


   contain more than one Loyalty logotype.

   The certificate background logotype, if present, MUST contain a
   graphical image intended as background image for the certificate,
   and/or a general audio sequence for the certificate. The background
   image MUST allow black text to be clearly read when placed on top of
   the background image. The logotype extension MUST NOT contain more
   than one certificate background logotype.

5. Type of certificates

   Logotypes MAY be included in public key certificates and attribute
   certificates at the discretion of the certificate issuer; however;
   logotypes MUST NOT be part of certification path validation or any
   type of automated processing. The sole purpose of logotypes is to
   enhance display of a particular certificate, regardless of its
   position in a certification path.

6. Use in Clients

   All PKI implementations require relying party software to have some
   mechanism to determine whether a trusted CA issues a particular
   certificate. This is an issue for certification path validation,
   including consistent policy and name checking.

   After a certification path is successfully validated, the replying
   party trusts the information that the CA includes in the certificate,
   including any certificate extensions. The client software can choose
   to make use of such information, or the client software can ignore
   it. If client is unable to support a provided logotype, the client
   MUST NOT report an error, rather the client MUST behave as though no
   logotype extension was included in the certificate. Current standards
   do not provide any mechanism for cross-certifying CAs to constrain
   subordinate CAs from including private extensions (see the security
   considerations section).

   Consequently, if relying party software accepts a CA, then it should
   be prepared to (unquestioningly) display the associated logotypes to
   its human user, given that it is configured to do so. Information
   about the logotypes is provided so that the replying party software
   can select the one that will best meet the needs of the human user.
   This choice depends on the abilities of the human user as well as the
   capabilities of the platform on which the replaying party software is
   running. If none of the provided logotypes meets the needs of the
   human user or matches the capabilities of the platform, then the
   logotypes can be ignored.

   A client MAY, subject to local policy, choose to display none, one or



Santesson, Housley, & Freeman                                  [Page 12]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


   any number of the logotypes in the logotype extension.

   In many cases, a client will be used in an environment with a good
   network connection and also used in an environment with little or no
   network connectivity. For example, a laptop computer can be docked
   with a high-speed LAN connection, or it can be disconnected from the
   network altogether. In recognition of this situation, the client MUST
   include the ability to disable the fetching of logotypes. However,
   locally cached logotypes can still be displayed when the user
   disables the fetching of additional logotypes.

   A client MAY, subject to local policy, choose any combination of
   audio and image presentation for each logotype. That is, the client
   MAY display an image with or without playing a sound, and it MAY play
   a sound with or without displaying an image. A client MUST NOT play
   more than one logotype audio sequence at the same time.

   The logotype is to be displayed in conjunction with other identity
   information contained in the certificate. The logotype is not a
   replacement for this identity information.

   Care is needed when designing replying party software to ensure that
   appropriate context of logotype information is provided. This is
   especially difficult with audio logotypes. It is important that the
   human user is able to distinguish the context of the logotype even if
   other audio streams are being played.

   If the relying party software is unable to successfully validate a
   particular certificate, then it MUST NOT display any logotype data
   associated with that certificate unless the end user is given a clear
   warning that the certificate, including its associated logotypes
   cannot be trusted.

7. Security considerations

   Logotypes are very difficult to securely and accurately define. Names
   are also difficult in this regard, but logotypes are even worse. It
   is quite difficult to specify what is, and what is not, a legitimate
   logotype of an organization. There is a whole legal structure around
   this issue, and it will not be repeated here. However, issuers should
   be aware of the implications of including images associated with a
   trademark or servicemark before doing so.

   As logotypes can be difficult (and sometimes expensive) to verify,
   this increases the possibility of errors related to assigning wrong
   logotypes to organizations.

   This is not a new issue for electronic identification instruments. It



Santesson, Housley, & Freeman                                  [Page 13]

INTERNET DRAFT       Logotypes in X.509 Certificates       December 2002


   is already dealt with in numerous of similar situations in the
   physical world, including physical employee identification cards.
   Secondly, there are situations where identification of logotypes is
   rather simple and straightforward, such as logotypes for well-known
   industries and institutes. These issues should not stop those service
   providers who want to issue logotypes from doing so, where relevant.

   It is impossible to prevent fraudulent creation of certificates by
   dishonest or badly performing issuers, containing names and logotypes
   that the issuer has no claim to or has failed to check correctly.
   Such certificates could be created in an attempt to socially engineer
   a user into accepting a certificate. The premise used for the
   logotype work is thus that logotype graphics in a certificate are
   trusted only if the certificate is successfully validated within a
   valid path. It is thus imperative that the representation of any
   certificate that fails to validate is not enhanced in any way by