relation between the certificate and the identified loyalty program
is beyond the scope of this document. The logotype extension MAY
contain more than one Loyalty logotype.
The certificate background logotype, if present, MUST contain a
graphical image intended as a 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 the 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 the 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 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
an appropriate context of logotype information is provided. This is
especially difficult with audio logotypes. It is important that the
human user be able to recognize 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.
7. Security Considerations
Implementations that simultaneously display multiple logotype types
(subject organization, issuer, community or other), MUST ensure that
there is no ambiguity as to the binding between the image and the
type of logotype that the image represents. "Logotype type" is
defined in section 2, and it refers to the type of entity or
affiliation represented by the logotype, not the type of binary
format.
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 an entire 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,
the possibility of errors related to assigning wrong logotypes to
organizations is increased.
This is not a new issue for electronic identification instruments.
It is already dealt with in a number 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
using the logotype graphic.
Logotype data is fetched from a server when it is needed. By
watching activity on the network, an observer can determine which
clients are making use of certificates that contain particular
logotype data. This observation can potentially introduce privacy
issues. Since clients are expected to locally cache logotype data,
network traffic to the server containing the logotype data will not
be generated every time the certificate is used. In cases where
logotype data is not cashed, monitoring would reveal usage frequency.
In cases where logotype data is cached, monitoring would reveal when
a certain logotype image or audio sequence is used for the first
time.
Certification paths may also impose name constraints that are
systematically checked during certification path processing, which,
in theory, may be circumvented by logotypes.
Certificate path processing as defined in RFC 3280 [PKIX-1] does not
constrain the inclusion of logotype data in certificates. A parent
CA can constrain certification path validation such that subordinate
CAs cannot issue valid certificates to end-entities outside a limited
name space or outside specific certificate polices. A malicious CA
can comply with these name and policy requirements and still include
inappropriate logotypes in the certificates that it issues. These
certificates will pass the certification path validation algorithm,
which means the client will trust the logotypes in the certificates.
Since there is no technical mechanism to prevent or control
subordinate CAs from including the logotype extension or its
contents, where appropriate, a parent CA could employ a legal
agreement to impose a suitable restriction on the subordinate CA.
This situation is not unique to the logotype extension.
The controls available to a parent CA to protect itself from rogue
subordinate CAs are non-technical. They include:
- Contractual agreements of suitable behavior, including terms of
liability in case of material breach.
- Control mechanisms and procedures to monitor and follow-up
behavior of subordinate CAs.
- Use of certificate policies to declare an assurance level of
logotype data, as well as to guide applications on how to treat
and display logotypes.
- Use of revocation functions to revoke any misbehaving CA.
There is not a simple, straightforward, and absolute technical
solution. Rather, involved parties must settle some aspects of PKI
outside the scope of technical controls. As such, issuers need to
clearly identify and communicate the associated risks.
8. IANA Considerations
Certificate extensions and attribute certificate extensions are
identified by object identifiers (OIDs). The OID for the extension
defined in this document was assigned from an arc delegated by the
IANA to the PKIX Working Group. No further action by the IANA is
necessary for this document or any anticipated updates.
9. Acknowledgments
This document is the result of contributions from many professionals.
The authors appreciate contributions from all members of the IETF
PKIX Working Group. We extend a special thanks to Al Arsenault,
David Cross, Tim Polk, Russel Weiser, Terry Hayes, Alex Deacon,
Andrew Hoag, Randy Sabett, Denis Pinkas, Magnus Nystrom, Ryan Hurst,
and Phil Griffin for their efforts and support.
Russ Housley thanks the management at RSA Laboratories, especially
Burt Kaliski, who supported the development of this specification.
The vast majority of the work on this specification was done while
Russ was employed at RSA Laboratories.
10. References
10.1. Normative References
[LANGCODES] Alvestrand, H., "Tags for Identification of Languages",
BCP 47, RFC 3066, January 2001.
[PKIX-1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure: Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[PKIX-AC] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[SHS] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[Supersedes FIPS PUB 180 dated 11 May 1993.]
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[HTTP/1.1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[MEDIA] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[AUDIO/MPEG] Nilsson, M., "The audio/mpeg Media Type", RFC 3003,
November 2000.
10.2. Informative References
[X.509] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
Information technology - Open Systems Interconnection -
The Directory: Public-key and attribute certificate
frameworks
APPENDIX A. ASN.1 Module
LogotypeCertExtn
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-logotype(22) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
AlgorithmIdentifier FROM PKIX1Explicit88 -- RFC 3280
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit(18) };
-- Logotype Extension OID
id-pe-logotype OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-pe(1) 12 }
-- Logotype Extension Syntax
LogotypeExtn ::= SEQUENCE {
communityLogos [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
issuerLogo [1] EXPLICIT LogotypeInfo OPTIONAL,
subjectLogo [2] EXPLICIT LogotypeInfo OPTIONAL,
otherLogos [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo OPTIONAL }
LogotypeInfo ::= CHOICE {
direct [0] LogotypeData,
indirect [1] LogotypeReference }
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 {
mediaType IA5String, -- MIME media type name and optional
-- parameters
logotypeHash SEQUENCE SIZE (1..MAX) OF HashAlgAndValue,
logotypeURI SEQUENCE SIZE (1..MAX) OF IA5String }
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
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets
playTime INTEGER, -- In milliseconds
channels INTEGER, -- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] 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 }
-- Places to get the same "LTD" file
-- Note: The content of referenced "LTD" files is defined by the
-- LogotypeData type
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
-- Other logotype type OIDs
id-logo OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 20 }
id-logo-loyalty OBJECT IDENTIFIER ::= { id-logo 1 }
id-logo-background OBJECT IDENTIFIER ::= { id-logo 2 }
END
APPENDIX B. Example Extension
The following example displays a logotype extension containing one
Issuer logotype using direct addressing. The issuer logotype image
is of the type image/gif. The logotype image file is referenced
through 1 URI and the image is hashed by one sha1 hash value.
The values on the left are the ASN.1 tag and length, in hexadecimal.
30 106: SEQUENCE {
06 8: OBJECT IDENTIFIER ’1 3 6 1 5 5 7 1 12’
04 94: OCTET STRING, encapsulates {
30 92: SEQUENCE {
A1 90: [1] {
A0 88: [0] {
30 86: SEQUENCE {
30 84: SEQUENCE {
30 82: SEQUENCE {
16 9: IA5String ’image/gif’
30 33: SEQUENCE {
30 31: SEQUENCE {
30 7: SEQUENCE {
06 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
04 20: OCTET STRING
: 8F E5 D3 1A 86 AC 8D 8E 6B C3 CF 80 6A D4 48 18
: 2C 7B 19 2E
: }
: }
30 34: SEQUENCE {
16 32: IA5String ’http://logo.example.com/logo.gif’
: }
: }
: }
: }
: }
: }
: }
: }
: }
Authors’ Addresses
Stefan Santesson
Microsoft Denmark
Tuborg Boulevard 12
DK-2900 Hellerup
Denmark
EMail: stefans@microsoft.com
Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
Trevor Freeman
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
USA
EMail: trevorf@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.