IPv6 Transition in the Session Initiation Protocol (SIP)
RFC 6157
| Document | Type |
RFC
- Proposed Standard
(April 2011)
IPR
Updates RFC 3264
|
|
|---|---|---|---|
| Authors | Gonzalo Camarillo , Karim El Malki , Vijay K. Gurbani | ||
| Last updated | 2020-07-29 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Jon Peterson | |
| Send notices to | (None) |
RFC 6157
Network Working Group S. Santesson
Internet-Draft IDsec Solutions
Obsoletes: 3709, 6170 (if approved) R. Housley
Intended status: Standards Track Vigil Security
Expires: 25 November 2022 T. Freeman
Amazon Web Services
L. Rosenthol
Adobe
24 May 2022
Internet X.509 Public Key Infrastructure: Logotypes in X.509
Certificates
draft-ietf-lamps-rfc3709bis-02
Abstract
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
This document obsoletes RFC 3709 and RFC 6170.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 25 November 2022.
Copyright Notice
Copyright (c) 2022 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 (https://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
Santesson, et al. Expires 25 November 2022 [Page 1]
Internet-Draft Logotypes in X.509 Certificates May 2022
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Certificate-based Identification . . . . . . . . . . . . 4
1.2. Selection of Certificates . . . . . . . . . . . . . . . . 5
1.3. Combination of Verification Techniques . . . . . . . . . 5
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Different Types of Logotypes in Certificates . . . . . . . . 6
3. Logotype Data . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Logotype Extension . . . . . . . . . . . . . . . . . . . . . 8
4.1. Extension Format . . . . . . . . . . . . . . . . . . . . 8
4.2. Conventions for LogotypeImageInfo . . . . . . . . . . . . 12
4.3. Embedded Images . . . . . . . . . . . . . . . . . . . . . 12
4.4. Other Logotypes . . . . . . . . . . . . . . . . . . . . . 13
4.4.1. Loyalty Logotype . . . . . . . . . . . . . . . . . . 13
4.4.2. Certificate Background Logotype . . . . . . . . . . . 13
4.4.3. Certificate Image Logotype . . . . . . . . . . . . . 14
5. Type of Certificates . . . . . . . . . . . . . . . . . . . . 15
6. Use in Clients . . . . . . . . . . . . . . . . . . . . . . . 15
7. Image Formats . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Audio Formats . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Acknowledgments from RFC 3709 . . . . . . . . . . . . . 23
12.2. Acknowledgments from RFC 6170 . . . . . . . . . . . . . 23
12.3. Additional Acknowledgments . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. ASN.1 Modules . . . . . . . . . . . . . . . . . . . 26
A.1. ASN.1 Modules with 1988 Syntax . . . . . . . . . . . . . 27
A.2. ASN.1 Module with 2002 Syntax . . . . . . . . . . . . . . 29
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 32
B.1. Example from RFC 3709 . . . . . . . . . . . . . . . . . . 32
B.2. Issuer Logotype Example . . . . . . . . . . . . . . . . . 33
B.3. Embedded Image Example . . . . . . . . . . . . . . . . . 34
B.4. Embedded Certificate Image Example . . . . . . . . . . . 36
Appendix C. Changes Since RFC 3709 and RFC 6170 . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
Santesson, et al. Expires 25 November 2022 [Page 2]
Internet-Draft Logotypes in X.509 Certificates May 2022
1. Introduction
This specification supplements [RFC5280], which profiles public-key
certificates and certificate revocation lists (CRLs) for use in the
Internet, and it supplements [RFC5755] which profiles attribute
certificates for use in the Internet.
This document obsoletes RFC 3709 [RFC3709] and RFC 6170 [RFC6170].
Appendix C provides a summary of the changes since the publication of
RFC 3709 and RFC 6170.
The basic function of a certificate is to bind a public key to the
identity of an entity (the subject). From a strictly technical
viewpoint, this goal could be achieved by signing the identity of the
subject together with its public key. However, the art of Public Key
Infrastructure (PKI) has developed certificates far beyond this
functionality in order to meet the needs of modern global networks
and heterogeneous information technology structures.
Certificate users must be able to determine certificate policies,
appropriate key usage, assurance level, and name form constraints.
Before a relying party can make an informed decision whether a
particular certificate is trustworthy and relevant for its intended
usage, a certificate may be examined from several different
perspectives.
Systematic processing is necessary to determine whether a particular
certificate meets the predefined prerequisites for an intended usage.
Much of the information contained in certificates is appropriate and
effective for machine processing; however, this information is not
suitable for a corresponding human trust and recognition process.
Humans prefer to structure information into categories and symbols.
Most humans associate complex structures of reality with easily
recognizable logotypes and marks. Humans tend to trust things that
they recognize from previous experiences. Humans may examine
information to confirm their initial reaction. Very few consumers
actually read all terms and conditions they agree to in accepting a
service, rather they commonly act on trust derived from previous
experience and recognition.
A big part of this process is branding. Service providers and
product vendors invest a lot of money and resources into creating a
strong relation between positive user experiences and easily
recognizable trademarks, servicemarks, and logotypes.
Santesson, et al. Expires 25 November 2022 [Page 3]
Internet-Draft Logotypes in X.509 Certificates May 2022
Branding is also pervasive in identification instruments, including
identification cards, passports, driver&SIP servers within an autonomous domain can communicate between
themselves. This section contains system-level issues; a companion
document [15] addresses IPv6 parser torture tests in SIP.
3.1. Proxy Behavior
User agents typically send SIP traffic to an outbound proxy, which
takes care of routing it forward. In order to support both IPv4-only
and IPv6-only user agents, it is RECOMMENDED that domains deploy
dual-stack outbound proxy servers or, alternatively, deploy both
IPv4-only and IPv6-only outbound proxies. Furthermore, there SHOULD
exist both IPv6 and IPv4 DNS entries for outbound proxy servers.
This allows the user agent to query DNS and obtain an IP address most
appropriate for its use (i.e., an IPv4-only user agent will query DNS
for A resource records (RRs), an IPv6-only user agent will query DNS
for AAAA RRs, and a dual-stack user agent will query DNS for all RRs
and choose a specific network.)
Some domains provide automatic means for user agents to discover
their proxy servers. It is RECOMMENDED that domains implement
appropriate discovery mechanisms to provide user agents with the IPv4
and IPv6 addresses of their outbound proxy servers. For example, a
domain may support both the DHCPv4 [11] and the DHCPv6 [10] options
for SIP servers.
On the receiving side, user agents inside an autonomous domain
receive SIP traffic from sources external to their domain through an
inbound proxy, which is sometimes co-located with the registrar of
the domain. As was the case previously, it is RECOMMENDED that
domains deploy dual-stack inbound proxies or, alternatively, deploy
both IPv4-only and IPv6-only inbound proxy servers. This allows a
user agent external to the autonomous domain to query DNS and receive
an IP address of the inbound proxy most appropriate for its use
(i.e., an IPv4-only user agent will query DNS for A RRs, an IPv6-only
user agent will query DNS for AAAA RRs, and a dual-stack user agent
will query DNS for all RRs and choose a specific network). This
strategy, i.e., deploying dual-stack proxies, also allows for an
IPv6-only user agent in the autonomous domain to communicate with an
IPv4-only user agent in the same autonomous domain. Without such a
proxy, user agents using different networks identifiers will not be
able to successfully signal each other.
Proxies MUST follow the recommendations in Section 5 to determine the
order in which to contact the downstream servers when routing a
request.
Camarillo, et al. Standards Track [Page 4]
RFC 6157 IPv6 Transition in SIP April 2011
3.1.1. Relaying Requests across Different Networks
A SIP proxy server that receives a request using IPv6 and relays it
to a user agent (or another downstream proxy) using IPv4, and vice
versa, needs to remain in the path traversed by subsequent requests.
Therefore, such a SIP proxy server MUST be configured to Record-Route
in that situation.
Note that while this is the recommended practice, some problems
may still arise if an RFC 2543 [14] endpoint is involved in
signaling. Since the ABNF in RFC 2543 did not include production
rules to parse IPv6 network identifiers, there is a good chance
that an RFC 2543-only compliant endpoint is not able to parse or
regenerate IPv6 network identifiers in headers. Thus, despite a
dual-stack proxy inserting itself into the session establishment,
the endpoint itself may not succeed in the signaling establishment
phase.
This is generally not a problem with RFC 3261 endpoints; even if
such an endpoint runs on an IPv4-only node, it still is able to
parse and regenerate IPv6 network identifiers.
Relaying a request across different networks in this manner has other
ramifications. For one, the proxy doing the relaying must remain in
the signaling path for the duration of the session; otherwise, the
upstream client and the downstream server would not be able to
communicate directly. Second, to remain in the signaling path, the
proxy MUST insert one or two Record-Route headers: if the proxy is
inserting a URI that contains a Fully Qualified Domain Name (FQDN) of
the proxy, and that name has both IPv4 and IPv6 addresses in DNS,
then inserting one Record-Route header suffices. But if the proxy is
inserting an IP address in the Record-Route header, then it must
insert two such headers; the first Record-Route header contains the
proxy's IP address that is compatible with the network type of the
downstream server, and the second Record-Route header contains the
proxy's IP address that is compatible with the upstream client.
An example helps illustrate this behavior. In the example, we use
only those headers pertinent to the discussion. Other headers have
been omitted for brevity. In addition, only the INVITE request and
final response (200 OK) are shown; it is not the intent of the
example to provide a complete call flow that includes provisional
responses and other requests.
In this example, proxy P, responsible for the domain example.com,
receives a request from an IPv4-only upstream client. It proxies
this request to an IPv6-only downstream server. Proxy P is running
on a dual-stack host; on the IPv4 interface, it has an address of
Camarillo, et al. Standards Track [Page 5]
RFC 6157 IPv6 Transition in SIP April 2011
192.0.2.1, and on the IPv6 interface, it is configured with an
address of 2001:db8::1 (Appendix A contains a sample DNS zone file
entry that has been populated with both IPv4 and IPv6 addresses.)
UAC Proxy UAS
(IPv4) P (IPv6)
| (IPv4/IPv6) |
| | |
+---F1--------->| |
| +---F2-------->|
| | |
| |<--F3---------+
|<--F4----------+ |
... ... ...
| | |
V V V
F1: INVITE sip:alice@example.com SIP/2.0
...
F2: INVITE sip:alice@2001:db8::10 SIP/2.0
Record-Route: <sip:2001:db8::1;lr>
Record-Route: <sip:192.0.2.1;lr>
...
F3: SIP/2.0 200 OK
Record-Route: <sip:2001:db8::1;lr>
Record-Route: <sip:192.0.2.1;lr>
...
F4: SIP/2.0 200 OK
Record-Route: <sip:2001:db8::1;lr>
Record-Route: <sip:192.0.2.1;lr>
...
Figure 1: Relaying requests across different networks
When the User Agent Server (UAS) gets an INVITE and it accepts the
invitation, it sends a 200 OK (F3) and forms a route set. The first
entry in its route set corresponds to the proxy's IPv6 interface.
Similarly, when the 200 OK reaches the User Agent Client (UAC) (F4),
it creates a route set by following the guidelines of RFC 3261 and
reversing the Record-Route headers. The first entry in its route set
corresponds to the proxy's IPv4 interface. In this manner, both the
UAC and the UAS will have the correct address of the proxy to which
they can target subsequent requests.
Camarillo, et al. Standards Track [Page 6]
RFC 6157 IPv6 Transition in SIP April 2011
Alternatively, the proxy could have inserted its FQDN in the Record-
Route URI and the result would have been the same. This is because
the proxy has both IPv4 and IPv6 addresses in the DNS; thus, the URI
resolution would have yielded an IPv4 address to the UAC and an IPv6
address to the UAS.
3.2. User Agent Behavior
User agent clients MUST follow the normative text specified in
Section 4.2 to gather IP addresses pertinent to the network. Having
done that, clients MUST follow the recommendations in Section 5 to
determine the order of the downstream servers to contact when routing
a request.
Autonomous domains SHOULD deploy dual-stack user agent servers, or
alternatively, deploy both IPv4-only and IPv6-only servers. In
either case, the RR in DNS for reaching the server should be
specified appropriately.
4. The Media Layer
SIP establishes media sessions using the offer/answer model [4]. One
endpoint, the offerer, sends a session description (the offer) to the
other endpoint, the answerer. The offer contains all the media
parameters needed to exchange media with the offerer: codecs,
transport addresses, protocols to transfer media, etc.
When the answerer receives an offer, it elaborates an answer and
sends it back to the offerer. The answer contains the media
parameters that the answerer is willing to use for that particular
session. Offer and answer are written using a session description
protocol. The most widespread protocol to describe sessions at
present is called, aptly enough, the Session Description Protocol
(SDP) [2].
A direct offer/answer exchange between an IPv4-only user agent and an
IPv6-only user agent does not result in the establishment of a
session. The IPv6-only user agent wishes to receive media on one or
more IPv6 addresses, but the IPv4-only user agent cannot send media
to these addresses, and generally does not even understand their
format. Consequently, user agents need a means to obtain both IPv4
and IPv6 addresses to receive media and to place them in offers and
answers.
This IP version incompatibility problem would not exist if hosts
implementing IPv6 also implemented IPv4, and were configured with
both IPv4 and IPv6 addresses. In such a case, a UA would be able
Camarillo, et al. Standards Track [Page 7]
RFC 6157 IPv6 Transition in SIP April 2011
to pick a compatible media transport address type to enable the
hosts to communicate with each other.
Pragmatism dictates that IPv6 user agents undertake the greater
burden in the transition period. Since IPv6 user agents are not
widely deployed yet, it seems appropriate that IPv6 user agents
obtain IPv4 addresses instead of mandating an upgrade on the
installed IPv4 base. Furthermore, IPv6 user agents are expected to
be dual-stacked and thus also support IPv4, unlike the larger IPv4-
only user agent base that does not or cannot support IPv6.
An IPv6 node SHOULD also be able to send and receive media using IPv4
addresses, but if it cannot, it SHOULD support Session Traversal
Utilities for NAT (STUN) relay usage [8]. Such a relay allows the
IPv6 node to indirectly send and receive media using IPv4.
The advantage of this strategy is that the installed base of IPv4
user agents continues to function unchanged, but it requires an
operator that introduces IPv6 to provide additional servers for
allowing IPv6 user agents to obtain IPv4 addresses. This strategy
may come at an additional cost to SIP operators deploying IPv6.
However, since IPv4-only SIP operators are also likely to deploy STUN
relays for NAT (Network Address Translator) traversal, the additional
effort to deploy IPv6 in an IPv4 SIP network should be limited in
this aspect.
However, there will be deployments where an IPv4/IPv6 node is unable
to use both interfaces natively at the same time, and instead, runs
as an IPv6-only node. Examples of such deployments include:
1. Networks where public IPv4 addresses are scarce and it is
preferable to make large deployments only on IPv6.
2. Networks utilizing Layer-2's that do not support concurrent IPv4
and IPv6 usage on the same link.
4.1. Updates to RFC 3264
This section provides a normative update to RFC 3264 [4] in the
following manner:
1. In some cases, especially those dealing with third party call
control (see Section 4.2 of [12]), there arises a need to specify
the IPv6 equivalent of the IPv4 unspecified address (0.0.0.0) in
the SDP offer. For this, IPv6 implementations MUST use a domain
name within the .invalid DNS top-level domain instead of using
the IPv6 unspecified address (i.e., ::).
Camarillo, et al. Standards Track [Page 8]
RFC 6157 IPv6 Transition in SIP April 2011
2. Each media description in the SDP answer MUST use the same
network type as the corresponding media description in the offer.
Thus, if the applicable "c=" line for a media description in the
offer contained a network type with the value "IP4", the
applicable "c=" line for the corresponding media description in
the answer MUST contain "IP4" as the network type. Similarly, if
the applicable "c=" line for a media description in the offer
contained a network type with the value "IP6", the applicable
"c=" line for the corresponding media description in the answer
MUST contain "IP6" as the network type.
4.2. Initial Offer
We now describe how user agents can gather addresses by following the
Interactive Connectivity Establishment (ICE) [7] procedures. ICE is
protocol that allows two communicating user agents to arrive at a
pair of mutually reachable transport addresses for media
communications in the presence of NATs. It uses the STUN [18]
protocol, applying its binding discovery and relay usages.
When following the ICE procedures, in addition to local addresses,
user agents may need to obtain addresses from relays; for example, an
IPv6 user agent would obtain an IPv4 address from a relay. The relay
would forward the traffic received on this IPv4 address to the user
agent using IPv6. Such user agents MAY use any mechanism to obtain
addresses in relays, but, following the recommendations in ICE, it is
RECOMMENDED that user agents support STUN relay usage [6] [8] for
this purpose.
IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses
using the ICE procedures to generate all their offers. This way,
both IPv4-only and IPv6-only answerers will be able to generate a
mutually acceptable answer that establishes a session (having used
ICE to gather both IPv4 and IPv6 addresses in the offer reduces the
session establishment time because all answerers will find the offer
valid.)
Implementations are encouraged to use ICE; however, the normative
strength of the text above is left at a SHOULD since in some
managed networks (such as a closed enterprise network) it is
possible for the administrator to have control over the IP version
utilized in all nodes and thus deploy an IPv6-only network, for
example. The use of ICE can be avoided for signaling messages
that stay within such managed networks.
Camarillo, et al. Standards Track [Page 9]
RFC 6157 IPv6 Transition in SIP April 2011
4.3. Connectivity Checks
Once the answerer has generated an answer following the ICE
procedures, both user agents perform the connectivity checks as
specified by ICE. These checks help prevent some types of flooding
attacks and allow user agents to discover new addresses that can be
useful in the presence of NATs.
5. Contacting Servers: Interaction of RFC 3263 and RFC 3484
RFC 3263 maps a SIP or SIPS URI to a set of DNS SRV records for the
various servers that can handle the URI. The Expected Output, given
an Application Unique String (the URI) is one or more SRV records,
sorted by the "priority" field, and further ordered by the "weight"
field in each priority class.
The terms "Expected Output" and "Application Unique String", as
they are to be interpreted in the context of SIP, are defined in
Section 8 of RFC 3263 [5].
To find a particular IP address to send the request to, the client
will eventually perform an A or AAAA DNS lookup on a target. As
specified in RFC 3263, this target will have been obtained through
NAPTR and SRV lookups, or if NAPTR and SRV lookup did not return any
records, the target will simply be the domain name of the Application
Unique String. In order to translate the target to the corresponding
set of IP addresses, IPv6-only or dual-stack clients MUST use the
newer getaddrinfo() name lookup function, instead of gethostbyname()
[16]. The new function implements the Source and Destination Address
Selection algorithms specified in RFC 3484 [9], which is expected to
be supported by all IPv6 hosts.
The advantage of the additional complexity is that this technique
will output an ordered list of IPv6/IPv4 destination addresses based
on the relative merits of the corresponding source/destination pairs.
This will guarantee optimal routing. However, the Source and
Destination Selection algorithms of RFC3484 are dependent on broad
operating system support and uniform implementation of the
application programming interfaces that implement this behavior.
Developers should carefully consider the issues described by Roy
et al. [19] with respect to address resolution delays and address
selection rules. For example, implementations of getaddrinfo()
may return address lists containing IPv6 global addresses at the
top of the list and IPv4 addresses at the bottom, even when the
host is only configured with an IPv6 local scope (e.g., link-
local) and an IPv4 address. This will, of course, introduce a
delay in completing the connection.
Camarillo, et al. Standards Track [Page 10]
RFC 6157 IPv6 Transition in SIP April 2011
6. Security Considerations
This document describes how IPv4 SIP user agents can communicate with
IPv6 user agents (and vice versa). To do this, it uses additional
protocols (STUN relay usage [6], ICE [7], SDP [2]); the threat model
of each such protocol is included in its respective document. The
procedures introduced in this document do not introduce the
possibility of any new security threats; however, they may make hosts
more amenable to existing threats. Consider, for instance, a UAC
that allocates an IPv4 and an IPv6 address locally and inserts these
into the SDP. Malicious user agents that may intercept the request
can mount a denial-of-service attack targeted to the different
network interfaces of the UAC. In such a case, the UAC should use
mechanisms that protect confidentiality and integrity of the
messages, such as using the SIPS URI scheme as described in Section
26.2.2 of RFC3261 [3], or secure MIME as described in Section 23 of
RFC3261 [3]. If HTTP Digest is used as an authentication mechanism
in SIP, then the UAC should ensure that the quality of protection
also includes the SDP payload.
7. Acknowledgments
The authors would like to thank Mohamed Boucadair, Christine Fischer,
Cullen Jennings, Aki Niemi, Jonathan Rosenberg, and Robert Sparks for
discussions on the working group list that improved the quality of
this document.
Additionally, Francois Audet, Mary Barnes, Keith Drage, and Dale
Worley provided invaluable comments as part of the working group Last
Call review process. Jari Arkko, Lars Eggert, Tobias Gondrom, Suresh
Krishnan, and Tim Polk conducted an in-depth review of the work as
part of the IESG and Gen-ART reviews.
8. References
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Camarillo, et al. Standards Track [Page 11]
RFC 6157 IPv6 Transition in SIP April 2011
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
the Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Traversal
Utilities for NAT (STUN)", RFC 5766, April 2010.
[7] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", RFC 5245, April 2010.
[8] Camarillo, G., Novo, O., and S. Perreault, "Traversal Using
Relays around NAT (TURN) Extension for IPv6", RFC 6156, April
2011.
[9] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)'s licenses, credit cards,
gasoline cards, and loyalty cards. Identification instruments are
intended to identify the holder as a particular person or as a member
of the community. The community may represent the subscribers of a
service or any other group. Identification instruments, in physical
form, commonly use logotypes and symbols, solely to enhance human
recognition and trust in the identification instrument itself. They
may also include a registered trademark to allow legal recourse for
unauthorized duplication.
Since certificates play an equivalent role in electronic exchanges,
we examine the inclusion of logotypes in certificates. We consider
certificate-based identification and certificate selection.
1.1. Certificate-based Identification
The need for human recognition depends on the manner in which
certificates are used and whether certificates need to be visible to
human users. If certificates are to be used in open environments and
in applications that bring the user in conscious contact with the
result of a certificate-based identification process, then human
recognition is highly relevant, and may be a necessity.
Examples of such applications include:
* Web server identification where a user identifies the owner of the
web site.
* Peer e-mail exchange in B2B, B2C, and private communications.
* Exchange of medical records, and system for medical prescriptions.
* Unstructured e-business applications (i.e., non-EDI applications).
* Wireless client authenticating to a service provider.
Most applications provide the human user with an opportunity to view
the results of a successful certificate-based identification process.
When the user takes the steps necessary to view these results, the
user is presented with a view of a certificate. This solution has
two major problems. First, the function to view a certificate is
often rather hard to find for a non-technical user. Second, the
presentation of the certificate is too technical and is not user
friendly. It contains no graphic symbols or logotypes to enhance
human recognition.
Santesson, et al. Expires 25 November 2022 [Page 4]
Internet-Draft Logotypes in X.509 Certificates May 2022
Many investigations have shown that users of today's applications do
not take the steps necessary to view certificates. This could be due
to poor user interfaces. Further, many applications are structured
to hide certificates from users. The application designers do not
want to expose certificates to users at all.
1.2. Selection of Certificates
One situation where software applications must expose human users to
certificates is when the user must select a single certificate from a
portfolio of certificates. In some cases, the software application
can use information within the certificates to filter the list for
suitability; however, the user must be queried if more than one
certificate is suitable. The human user must select one of them.
This situation is comparable to a person selecting a suitable plastic
card from his wallet. In this situation, substantial assistance is
provided by card color, location, and branding.
In order to provide similar support for certificate selection, the
users need tools to easily recognize and distinguish certificates.
Introduction of logotypes into certificates provides the necessary
graphic.
1.3. Combination of Verification Techniques
The use of logotypes will, in many cases, affect the users decision
to trust and use a certificate. It is therefore important that there
be a distinct and clear architectural and functional distinction
between the processes and objectives of the automated certificate
verification and human recognition.
Since logotypes are only aimed for human interpretation and contain
data that is inappropriate for computer based verification schemes,
the logotype extension MUST NOT be an active component in automated
certification path validation.
Automated certification path verification determines whether the end-
entity certificate can be verified according to defined policy. The
algorithm for this verification is specified in [RFC5280].
The automated processing provides assurance that the certificate is
valid. It does not indicate whether the subject is entitled to any
particular information, or whether the subject ought to be trusted to
perform a particular service. These are authorization decisions.
Automatic processing will make some authorization decisions, but
others, depending on the application context, involve the human user.
Santesson, et al. Expires 25 November 2022 [Page 5]
Internet-Draft Logotypes in X.509 Certificates May 2022
In some situations, where automated procedures have failed to
establish the suitability of the certificate to the task, the human
user is the final arbitrator of the post certificate verification
authorization decisions. In the end, the human will decide whether
or not to accept an executable email attachment, to release personal
information, or follow the instructions displayed by a web browser.
This decision will often be based on recognition and previous
experience.
The distinction between systematic processing and human processing is
rather straightforward. They can be complementary. While the
systematic process is focused on certification path construction and
verification, the human acceptance process is focused on recognition
and related previous experience.
There are some situations where systematic processing and human
processing interfere with each other. These issues are discussed in
the Section 9.
1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Different Types of Logotypes in Certificates
This specification defines the inclusion of three standard logotype
types:
* Community logotype
* Issuer organization logotype
* Subject organization logotype
The community logotype is the general mark for a community. It
identifies a service concept for entity identification and
certificate issuance. Many issuers may use a community logotype to
co-brand with a global community in order to gain global recognition
of its local service provision. This type of community branding is
very common in the credit card business, where local independent card
issuers include a globally recognized brand (such as VISA and
MasterCard).
Santesson, et al. Expires 25 November 2022 [Page 6]
Internet-Draft Logotypes in X.509 Certificates May 2022
Issuer organization logotype is a logotype representing the
organization identified as part of the issuer name in the
certificate.
Subject organization logotype is a logotype representing the
organization identified in the subject name in the certificate.
In addition to the standard logotype types, this specification
accommodates inclusion of other logotype types where each class of
logotype is defined by an object identifier. The object identifier
can be either locally defined or an identifier defined in Section 4.4
of this document.
3. Logotype Data
This specification defines two types of logotype data: image data and
audio data. Implementations MUST support image data; however,
support for audio data is OPTIONAL.
There is no need to significantly increase the size of the
certificate by including image and audio data of logotypes when a URI
identifying the location to the logotype data and a one-way hash of
the referenced data is included in the certificate. Embedding the
logotype in the certificate (as defined in Section 4.3) can
significantly increase the size of the certificate.
Several image objects, representing the same visual content in
different formats, sizes, and color palates, may represent each
logotype image. At least one of the image objects representing a
logotype SHOULD contain an image with a width between of 60 pixels
and 200 pixels and a height between 45 pixels and 150 pixels.
Several instances of audio data may further represent the same audio
sequence in different formats, resolutions, and languages. At least
one of the audio objects representing a logotype SHOULD provide text-
based audio data suitable for processing by text-to-speech software.
A typical use of text based audio data is inclusion in web
applications where the audio text is placed as the "alt" atttribute
value of an html image (img) element and the language value obtained
from LogotypeAudioInfo is included as the "lang" attribute of that
image.
If a logotype of a certain type (as defined in Section 1.1) is
represented by more than one image object, then each image objects
MUST contain variants of roughly the same visual content. Likewise,
if a logotype of a certain type is represented by more than one audio
object, then the audio objects MUST contain variants of the same
Santesson, et al. Expires 25 November 2022 [Page 7]
Internet-Draft Logotypes in X.509 Certificates May 2022
audio information. A spoken message in different languages is
considered a variation of the same audio information. Compliant
applications MUST NOT display more than one of the image objects and
MUST NOT play more than one of the audio object for any logotype type
at the same time.
A client MAY simultaneously display multiple logotypes of different
logotype types. For example, it may display one subject organization
logotype while also displaying a community logotype, but it MUST NOT
display multiple image variants of the same community logotype.
Each logotype present in a certificate MUST be represented by at
least one image data object.
Client applications SHOULD enhance processing and off-line
functionality by caching logotype data.
4. Logotype Extension
This section specifies the syntax and semantics of the logotype
certificate extension.
4.1. Extension Format
The logotype extension MAY be included in public key certificates
[RFC5280] or attribute certificates [RFC5755]. 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. Client applications SHOULD 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 object.
Direct addressing supports cases where just one or a few alternative
images and audio objects are referenced.
Santesson, et al. Expires 25 November 2022 [Page 8]
Internet-Draft Logotypes in X.509 Certificates May 2022
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 object. Indirect addressing
supports cases where each logotype is represented by many alternative
audio or image objects.
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 from one URI, the client SHOULD try another URI in
the sequence. All direct addressing URIs SHOULD use either the HTTP
scheme (http://...) or the HTTPS scheme (https://...) or the DATA
scheme (data://...) [RFC3986]; however, the "data" URI scheme MUST
NOT be used with the indirect addressing. Clients MUST support
retrieval of referenced LogoTypeData with the HTTP
[I-D.ietf-httpbis-semantics] and the HTTP with TLS [RFC8446], or
subsequent versions of these protocols. Client applications SHOULD
also support the "data" URI scheme [RFC2397] for direct addressing
with embedded logotype data within the extension.
The logotype extension MUST have the following 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
Santesson, et al. Expires 25 November 2022 [Page 9]
Internet-Draft Logotypes in X.509 Certificates May 2022
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, 0=unspecified
xSize INTEGER, -- Horizontal size in pixels
ySize INTEGER, -- Vertical size in pixels
resolution LogotypeImageResolution OPTIONAL,
language [4] IA5String OPTIONAL } -- RFC 5646 Language Tag
LogotypeImageType ::= INTEGER { grayScale(0), color(1) }
LogotypeImageResolution ::= CHOICE {
numBits [1] INTEGER, -- Resolution in bits per pixel
tableSize [2] INTEGER } -- Number of colors or grey tones
LogotypeAudioInfo ::= SEQUENCE {
fileSize INTEGER, -- In octets, 0=unspecified
playTime INTEGER, -- In milliseconds, 0=unspecified
channels INTEGER, -- 0=unspecified,
-- 1=mono, 2=stereo, 4=quad
sampleRate [3] INTEGER OPTIONAL, -- Samples per second
language [4] IA5String OPTIONAL } -- RFC 5646 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 LogotypeData
-- image or audio object
HashAlgAndValue ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
hashValue OCTET STRING }
When using indirect addressing, the URI (refStructURI) pointing to
the external data structure MUST point to a resource that contains
the DER-encoded data with the syntax LogotypeData.
At least one of the optional elements in the LogotypeExtn structure
MUST be present.
When using direct addressing, at least one of the optional elements
in the LogotypeData structure MUST be present.
Santesson, et al. Expires 25 November 2022 [Page 10]
Internet-Draft Logotypes in X.509 Certificates May 2022
The LogotypeReference and LogotypeDetails structures explicitly
identify one or more one-way hash functions employed to authenticate
referenced image or audio objects. CAs MUST include a hash value for
each referenced object, calculated on the whole object. CAs SHOULD
include a hash value that computed with the one-way hash function
associated with the certificate signature, and CAs MAY include other
hash values. Clients MUST compute a one-way hash value using one of
the identified functions, and clients MUST discard the logotype data
if the computed hash value does not match the hash value in the
certificate extension.
A MIME type is used to specify the format of the image or audio
object containing the logotype data. The mediaType field MUST
contain a string that is constructed according to the ABNF [RFC5234]
provided in Section 4.2 of [RFC6838]. MIME types MAY include
parameters.
Image format requirements are specified in Section 7, and audio
format requirements are specified in Section 8.
When language is specified, the language tag MUST use the [RFC5646]
syntax.
Logotype types defined in this specification are:
Community Logotype: If communityLogos is present, the logotypes
MUST represent one or more communities with 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 a 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
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.
Santesson, et al. Expires 25 November 2022 [Page 11]
Internet-Draft Logotypes in X.509 Certificates May 2022
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 document.
4.2. Conventions for LogotypeImageInfo
When the optional LogotypeImageInfo is included with a logotype
image, the parameters MUST be used with the following semantics and
restrictions.
The xSize and ySize fields represent the recommended display size for
the logotype 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 from corresponding size values in the
referenced image object, then the referenced image SHOULD be scaled
to fit within the size parameters of LogotypeImageInfo, while
preserving the x and y ratio.
The resolution field is redundant for all logotype image formats
listed in Section 7. The optional resolution field SHOULD be omitted
when the image format already contains this information.
4.3. Embedded Images
If the logotype image is provided through direct addressing, then the
image MAY be stored within the logotype certificate extension using
the "data" scheme [RFC2397]. The syntax of the "data" URI scheme
defined 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" URI scheme, the following conventions apply:
quot;, RFC 3484, February 2003.
8.2. Informative References
[10] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers", RFC 3319, July 2003.
[11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCP-
for-IPv4) Option for Session Initiation Protocol (SIP)
Servers", RFC 3361, August 2002.
[12] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
April 2004.
[13] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[15] Gurbani, V., Boulton, C., and R. Sparks, "Session Initiation
Protocol (SIP) Torture Test Messages for Internet Protocol
Version 6 (IPv6)", RFC 5118, February 2008.
Camarillo, et al. Standards Track [Page 12]
RFC 6157 IPv6 Transition in SIP April 2011
[16] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro,
"Application Aspects of IPv6 Transition", RFC 4038, March 2005.
[17] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for
IPv6 Hosts and Routers", RFC 4213, October 2005.
[18] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[19] Roy, S., Durand, A., and J. Paugh, "IPv6 Neighbor Discovery On-
Link Assumption Considered Harmful", RFC 4943, September 2007.
Camarillo, et al. Standards Track [Page 13]
RFC 6157 IPv6 Transition in SIP April 2011
Appendix A. Sample IPv4/IPv6 DNS File
A portion of a sample DNS zone file entry is reproduced below that
has both IPv4 and IPv6 addresses. This entry corresponds to a proxy
server for the domain "example.com". The proxy server supports the
Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)
transport for both IPv4 and IPv6 networks.
...
_sip._tcp SRV 20 0 5060 sip1.example.com
SRV 0 0 5060 sip2.example.com
_sip._udp SRV 20 0 5060 sip1.example.com
SRV 0 0 5060 sip2.example.com
sip1 IN A 192.0.2.1
sip1 IN AAAA 2001:db8::1
sip2 IN A 192.0.2.2
sip2 IN AAAA 2001:db8::2
...
Camarillo, et al. Standards Track [Page 14]
RFC 6157 IPv6 Transition in SIP April 2011
Authors' Addresses
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Karim El Malki
Athonet
AREA Science Park
Padriciano 99
Trieste (TS) 34149
Italy
EMail: karim@athonet.com
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane
Rm 9C-533
Naperville, IL 60563
USA
Phone: +1 630 224 0216
EMail: vkg@bell-labs.com
Camarillo, et al. Standards Track [Page 15]