One document matched: draft-jennings-sipping-certs-02.txt
Differences from draft-jennings-sipping-certs-01.txt
Sipping C. Jennings
Internet-Draft Cisco Systems
Expires: August 14, 2004 February 14, 2004
Certificate Discovery for SIP
draft-jennings-sipping-certs-02
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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-Drafts.
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 http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This draft describes a scheme in which a SIP user agent can create
self signed certificate for use with the SIP S/MIME mechanism and can
store the certificate on a web server associated with the address of
record (AOR) for the user. Other user agents that want to call that
AOR can retrieve these certificates from the web server.
The result of this system is that, with no extra expense or effort
for the end user, it is possible to have a reasonable degree of
confidence about the identities of the parties in a SIP session.
Jennings Expires August 14, 2004 [Page 1]
Internet-Draft Cert Discovery February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Location and Retrieval . . . . . . . . . . . . . . . . . . . . 5
4.1 Location with HTTP . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Location with SIP . . . . . . . . . . . . . . . . . . . . . . 6
4.3 Retrieval with HTTP . . . . . . . . . . . . . . . . . . . . . 6
4.4 Multiple UAS for a Single AOR . . . . . . . . . . . . . . . . 7
4.5 Steps to Locate and Retrieve a Certificate . . . . . . . . . . 7
5. Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Steps to Enroll . . . . . . . . . . . . . . . . . . . . . . . 9
6. Delegated Crypto with Content Indirection . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7.1 Security Analysis . . . . . . . . . . . . . . . . . . . . . . 10
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Comparison with Identity . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Normative References . . . . . . . . . . . . . . . . . . . . . 13
Informational References . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Jennings Expires August 14, 2004 [Page 2]
Internet-Draft Cert Discovery February 2004
1. Introduction
SIP RFC 3261 [1] defines an S/MIME based PKI mechanism for achieving
end to end security. Among other things, it allows users to be
confident that the party they are communicating with is likely the
person they want. Like all PKI based schemes, distribution of the
public keys is a hard problem. Failure to have a good and widely
supported scheme for distributing public keys will result in users
not using the S/MIME capabilities of SIP. Not knowing the identities
of the other parties in a SIP session greatly reduces the usefulness
of encrypted media such as SRTP.
This document describes an approach to using and combining existing
schemes to build a trustworthy way of distributing certificates for
SIP. An example use case makes this easier to understand. Say Alice
meets Bob at a party and Bob says "Call me some time. Here is my
AOR." Then Bob writes bob@example.com on the back of a napkin and
hands it to Alice. Later Alice makes a call to bob@example.com but
she wants to be sure that she really is talking to the person who
owns the AOR bob@example.com. This document refers to Alice as the
Caller, Bob as the Subscriber, and example.com as the Service.
The overall approach is fairly simple and is illustrated in the
figure below. The "store" element in the network is an HTTP web
server that is run by the same administrative domain as the proxy.
+---------+ +---------+
+---+ Store A +--- --| Store B +--+
| +---------+ \ / +---------+ |
| \ / |
0 | \ / |
| 2 +-------+ 3 X +-------+ |0
| +--+Proxy A+------/-\---|Proxy B+-+ |
| | +-------+ / \ +-------+ |4 |
| | / \ | |
+------+ / \ +------+
| UA A |---------/ \-------+ UA B |
+------+ 1 5 +------+
The goal is for UA A to sign and encrypt a message to UA B using
securely acquired self signed certificates. Both sides save their
public certificates in a well known store associated with their
domain and get the other's certificate from the other domain's store.
There are several steps.
o Step 0: At some point in time, both the UA generate a self signed
certificate and store it in the the Store for their domain. This
is done with a PUT over HTTPS that is digest challenged with the
Jennings Expires August 14, 2004 [Page 3]
Internet-Draft Cert Discovery February 2004
same credentials that are used to register with the proxy in the
domain.
o Step 1: UA A fetches the certificate for UA B from Store B. This
is done using a GET over HTTPS.
o Step 2,3,4: UA A uses its certificate to sign and UA B's
certificate to encrypt and sends a message across the proxies in
steps 2,3,and 4 to UA B. This is done using the normal SIP S/MIME
bodies.
o Step 5: UA B needs to get UA A's certificate to check the
signature. It gets this from Store A using a HTTPS GET. UA B can
now decrypt the message and check the signature.
When one of the UA gets a certificate from a Store, the UA must check
that the domain name in the AOR in the certificate matches the domain
of the Store it is getting the result from. The UA knows this from
the certificate presented in the TLS handshake. This one little part
makes this scheme significantly different from a typical self signed
certificate system. In a classical systems, such as SSH, the first
time a certificate is received, there is no automatic way to validate
it so the systems must make a "leap of faith" or provide manual out
of bound validation which users are typically unwilling to do. This
system does not require the leap of faith because the certificate in
the TLS session with the store validates that the UA is getting the
certificate for UA B from a trustworthy source.
The scheme described in this document meets the goal of allowing
Alice to be confident she is communicating with the person with the
AOR bob@example.com. It also has the following very desirable
properties:
o Trivial to use, requiring no extra effort from the part of the
Caller or Subscriber.
o Free in that it does not require any extra expense to the Caller
or Subscriber.
o No requirement for a third party to know the Subscriber's private
key.
o Allows the Subscriber to have more than one communication device
associated with a single AOR.
o Does not require the Service to deploy additional equipment with
strict security requirements beyond what they are already running.
Jennings Expires August 14, 2004 [Page 4]
Internet-Draft Cert Discovery February 2004
None of the problems or ideas presented in this document are new.
This presents work going on in the PKIX, SACRED, and SIP working
groups in a SIP context and describes an approach to putting the
parts together for SIP.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
The term Subscriber refers to an end user that receives calls and has
an AOR in a domain that is managed by the Service. The Service
provides the SIP proxy and certificate Store. The term Caller refers
to the UA that is trying to call the Subscriber. The Caller is often
not in the same administrative domain as the Subscriber and therefore
has no pre-existing relationship with the Service.
3. Overview
The approach is broken down into Enrollment, Location, and Retrieval
phases. The general architecture is that the Service not only
provides a SIP registrar service for the Subscriber but also provides
certificate storage. In the Enrollment phase, the Subscriber puts
their public certificate somewhere that others can find it. In the
Locating phase, the Caller discovers where the person they are
calling has stored their certificates. Finally in the Retrieval
phase, the Caller gets a copy of the Subscriber's certificates. To
meet the goal of being free, the certificates are assumed to be self
signed.
4. Location and Retrieval
The goal of this stage is to allow the Caller to locate where the
Subscriber stores their certificates. The only thing the Caller has
is an AOR such as bob@example.com. The obvious solution is to use the
host portion of the AOR to find a directory to look up the user
portion.
4.1 Location with HTTP
The mechanism for location using HTTP is described in
draft-ietf-pkix-certstore-http [2]. The approach first does a SRV
lookup and if that fails, it tries a well known host formed from the
AOR directly. For the AOR bob@example.com, first an SRV lookup of
_certificates._tcp.example.com would be done. If this was successful
and returned an address of a.example.com and a port of 7000 then the
URL would be:
Jennings Expires August 14, 2004 [Page 5]
Internet-Draft Cert Discovery February 2004
https://a.example.com:7000/search-cgi?email=bob%40example.com
If the SRV lookup was not successful, then the URL would be formed by
adding the host name "certificates" to the domain. In this case the
URL would be:
https://certificates.example.com/search-cgi?email=bob%40example.com
4.2 Location with SIP
An alternative scheme to locate the certificates could be based on
SIP. The Caller would send an OPTIONS message to the Subscriber
proxy. The reply to this would contain a content indirection body [6]
or message/external type as defined in RFC 2017 [9] that references a
MIME type of application/pkix-cert that could be retrieved using an
https URL. The Caller would include a similar content indirection
body pointing to their certificate in the messages sent to the
Subscriber. This would avoid the need to have some well known URL for
locating certificates, and each administrative domain could set up
the certificates' locations as it wished.
4.3 Retrieval with HTTP
Once a URL for the certificate is known, the Caller needs to get it.
There are several potential protocols that could work for this: HTTP,
LDAP, FTP, SNMP, ACAP, and others. The existing tools for making HTTP
scale and be reliable, the tools for managing attacks on servers, and
the existing support for hardware acceleration of HTTPS make this a
good choice from the server point of view. The ease of working
through NATs and firewalls along with the fact that most SIP UAs need
to implement HTTP for other reasons make it a good match on the
client end. The MIME types in HTTP are useful for dealing with the
various types of certificates. These points led to the selection of
HTTPS as defined in draft-ietf-pkix-certstore-http [2] as a mechanism
for getting the certificates. Getting the certificate with HTTP is
defined in RFC 2585 [5] and will be in a MIME type of application/
pkix-cert and contain a DER encoded X509 certificate./
Since the certificates may be self signed, the Caller needs to be
sure that they were not tampered with and that they came from the
Service that was authorized to provide them. This means that the
Caller MUST use HTTPS to get the certificate and the Service MUST
present a certificate in the TLS handshake that has a domain name in
the SubjectAltName field that matches the domain name in the AOR in
the SubjectAltName in the retrieved certificate. In this example the
original is example.com, not the result of any SRV lookup. The names
are considered to match if the SubjectAltName matches the host
Jennings Expires August 14, 2004 [Page 6]
Internet-Draft Cert Discovery February 2004
portion of the AOR using a case insensitive comparison. Sub-domains
do not match. IP addresses do not match host names.
4.4 Multiple UAS for a Single AOR
It is possible to retrieve a list of several certificates for the
same AOR when there are several different UA that may receive
messages for this AOR. In this case the UA sending the messages needs
to use every valid certificate it received for the public key
operations. A certificate Store SHOULD not provide certificates that
have become invalid.
4.5 Steps to Locate and Retrieve a Certificate
Both the Caller and Subscriber UA need to retrieve the other's
certificate from the appropriate Store. This is done with the
following steps:
o Determine the AOR of the certificate that is needed - for example,
alice@example.com.
o Do a DNS SRV lookup for the service _certificates with a protocol
of _tcp in the domain of the AOR. (In this example this would
result in a DNS SRV query in the domain example.com). If this is
found, form a URL using the hostname and port returned. If not,
form the URL by using the default port for HTTPS and a hostname of
certificates prepended to the the domain from the AOR. (In this
example this would result in a hostname of
certificates.example.com)
o Use the host and port found in the previous step to form a URL of
the form "https:://host:port/serach-cgi?email=aor" where the "aor"
is replaced with an appropriately escaped version of the AOR. For
this example, this would become "https://certificates.example.com/
search-cgi?email=alice%40example.com"
o Open a TLS connection to this URL. TLS extended hellos to indicate
the requested domain SHOULD be used. The server MUST return a
certificate with a SubjectAltName that matches the domain portion
of the original AOR (example.com in this example). The UA MUST
check this matches and if it does not, it must close the
connection and not proceed.
o The UA then performs an HTTP GET on the URL. The Store returns the
one or more bodies or an error if it has no certificates for this
Subscriber. Each certificate is in an DER encoded X509 certificate
and is in a body of type application/pkix-cert. A transfer
encoding of binary is used.
Jennings Expires August 14, 2004 [Page 7]
Internet-Draft Cert Discovery February 2004
o The UA MUST check that all the SubjectAltNames in all the
certificates have a user and host portion that matches the
original AOR. Schemes other than SIP are acceptable. In this
example, a SubjectAltName that contained two URIs,
"im:alice@example.com" and "sip:alice@example.com" would be
acceptable. Any certificates that do not match MUST be discarded.
o The UA MUST check the expiry dates on the certificates. Any
expired certificates MUST be discarded.
The UA now has a usable list of certificates for the AOR. If the UA
is using them to decrypt, it uses the serial number and issuer to
find the certificate it needs to decrypt the information. If it is
using the certificates to encrypt some information, it must encrypt
the CEK with each of the certificates so that the a UA in possession
of the private key from any one of the certificates can decrypt the
material.
5. Enrollment
The Subscriber must be able to authenticate to the Service and must
be able to transfer the certificate in an integrity protected way to
the Service. In SIP, the Service and the Subscriber already have a
shared secret that is used for authentication during SIP
registration; or the Service knows the certificate of the Subscriber
by some out of band mechanism. This shared secret can be leveraged
for enrollment of the Subscriber's public certificates.
The Subscriber would transfer acertificate to the Service using an
HTTPS PUT with the same URL that would be used to get their
certificate. This MUST happen over HTTPS so the transfer is integrity
protected. The client MUST also check that the server's certificate
name matches the name of the Subscriber's AOR. This matching follows
the same rules as matching in retrieval of certificates. The client
MUST authenticate to the server using DIGEST authentication with some
shared secret. The same shared secret that is used for SIP
registration SHOULD be used. This allows any Subscriber to generate a
self signed certificate and store it at the Service. Note that
authorization with TLS mutual authentication is not considered
because in that case the Service already has the Subscriber's
Certificate and there is no need to transfer it.
There is an additional problem of how to allow a user that has
several communication clients to associate them all with the same AOR
and still get the certificates to work. There are at least two
approaches to this problem. One would be to upload a different
certificate for each UA associated with the AOR and just let the
Caller use all of them. This is the approach that is chosen here. The
Jennings Expires August 14, 2004 [Page 8]
Internet-Draft Cert Discovery February 2004
other approach would be to use the work from the SACRED working
group[8] which is solving the problem of security getting the same
credential on all the clients.
In the chosen approach of using many certificates for a single AOR,
the Caller would first get all the certificates from the Service. It
would then send an INVITE to the Subscriber and sign it with its own
certificate and encrypt the SDP (or whatever part of the messages was
being encrypted) with each of the certificates retrieved. No matter
which of the Subscribers UA's received the message, that UA would be
able to decrypt the information.
The Service MUST provide some other authenticated, out of band
mechanism for the Subscriber to revoke certificates. A web page
accessed over HTTPS with digest authentication would work fine for
this. A HTTPS DELETE with digest could work but there needs to be a
way to tell which certificate needs to be deleted when the AOR has
multiple certificates.
It is RECOMMENDED that the clients use fairly short-lived
certificates (in the order of days to months) and enroll a new
certificate before the old one expires. The Caller MAY cache the
certificates that they retrieved for an AOR and use them in future
calls. This cached result MUST expire after some short but
configurable amount of time so that certificate revocation works. It
MUST be possible to configure this time to be zero. If the Caller is
using cached information and receives a certificate in the SIP
signaling that is not cached, the Caller MUST update the cache and
check that the certificate was not recently added to the Service.
When a UA registers, it SHOULD retrieve the certificates for its AOR
and check that this UA's certificate is correctly enrolled. The HTTPS
server MUST support a profile of TLS_RSA_WITH_AES_128_CBC_SHA as
described in RFC 3268 [4] or a profile of TLS_RSA_WITH_3DES_CBC_SHA .
5.1 Steps to Enroll
The Subscriber UA needs to generate a self signed certificate and
save it in the store. This is performed in the following steps:
o When the UA starts up, it needs to fetch its own certificate and
check that it matches the certificate stored on the UA. If it does
not, it should warn the user and generate a new certificate.
o The UA should check the expiration and arrange to generate a new
certificate before the old one expires.
o TODO: Describe details of generating a self signed certificate.
Jennings Expires August 14, 2004 [Page 9]
Internet-Draft Cert Discovery February 2004
o The UA forms a URL in the same way as locating a certificate but
using its own AOR.
o The UA opens a a TLS connection and verifies the certificate
returned in the TLS the same way as retrieving a certificate.
o The UA then does a HTTPS PUT of the certificate. The server MUST
digest challenge this request. The UA computes the response to
this digest and MAY use the same username and password as it would
use to register with the proxy in this domain.
o The server must check that, for each URI in the SubjectAltName in
the certificate, the user portion matches the username used in the
digest authentication and the host portion matches the domain used
for the TLS connection.
o When the certificate is close to expiring, the UA should create
and store a new certificate.
At this point the UA has successfully stored its certificate in the
Store. The Store may discard any certificates that have expired.
6. Delegated Crypto with Content Indirection
If the Subscriber or Caller wishes to use an authentication service
to insert and verify S/MIME bodies on their behalf, they can do so by
using content indirection [6] to specify URLs for the S/MIME bodies
that can be filled in by the authentication service.
TODO - This needs significantly more detail if it is to be used
7. Security Considerations
This whole document is focused on security and must be considered
from a security point of view.
It is important to remember that the scheme relies upon the
Subscriber choosing a Service that does not lie. The Subscriber may
wish to use contractual obligations to enforce this.
7.1 Security Analysis
This whole scheme is made possible because the Subscriber has a
shared secret with the Service, the Service has a certificate that is
signed by a well known certificate authority, and the Caller knows
how to find the Service for the Subscriber they are calling.
To look at the security of this scheme one must consider the existing
Jennings Expires August 14, 2004 [Page 10]
Internet-Draft Cert Discovery February 2004
SIP S/MIME trust model and what the trust relationships are. If Alice
tells a secret to Bob, Bob can tell anyone. If Bob signs something
and sends it to Alice, Alice can only believe this signature as much
as she believes that Bob has securely managed his private key and has
not posted it on an IRC channel. If Bob tells Alice that his AOR is
bob@example.com, that may change in the future and someone else may
get that AOR. Just because Alice manages to get a valid certificate
bound to the AOR bob@example.com does not mean that Alice is going to
talk to the right Bob. This last point is important in understanding
why the scheme presented here is not significantly less secure than
the use of S/MIME certificates in SIP that are signed by a well known
certificate authority. All SIP has is the AOR - SIP can check that
the name in the certificate matches the AOR but it can not check
other things that are likely to make the identity unique. If the
Service example.com gave the AOR bob@example.com to a new Bob, they
would likely give away the email address bob@example.com to the new
Bob as well. Furthermore, the certificate authority, after revoking
the old certificates, would probably give the new Bob a new
certificate if the new Bob could read email sent to the AOR. Alice
would be talking to bob@example.com - but the new Bob instead of the
old Bob.
The point of this is that you have to trust that the person providing
your AOR will not give your AOR to someone else. Bob has some ability
to choose a Service he trusts. He can enforce this contractually with
the Service and by choosing one worthy of trust. Alice has to trust
Bob on many things including that he picked a trustworthy party to
manage his AOR and that he manages his private key appropriately.
If the Subscriber can trust the Service to manage the Subscriber's
AOR, then the Subscriber can trust the Service not to lie about
certificates they store for the Subscriber. If the Service wants to
subvert Bob's communications, they can likely do this by getting a
certificate authority to give them a certificate masquerading as Bob.
The security of this scheme relies on the Service not lying about
what Bob's public certificates are. If you buy this, the rest is
fairly simple.
Only Bob's UAs have the shared secret to authenticate to the Service
to upload a certificate. The UA will not accidentally authenticate to
a rogue service because the UA checks the certificate the Service
presents in TLS. The certificate is not tampered with because the
HTTPS connection is integrity protected. When the Caller retrieves a
certificate they know it is coming from the correct Service because
the Service must have the certificate for the domain that represents
the host portion of the AOR. The Caller knows the certificate was not
tampered with in transit because the connection is integrity
protected.
Jennings Expires August 14, 2004 [Page 11]
Internet-Draft Cert Discovery February 2004
Certificates can be quickly revoked because the Caller gets the
certificates on each new call to the Subscriber. This side steps some
thorny CRL issues. The impact of getting these each time will
probably make a relevant difference on the load of the Service's
servers but does not make the scheme unworkable.
The Subscriber's UAs can use short lived self signed certificates. In
fact UAs could upload a new certificate each time they boot. This
would eliminate the need for UAs to store the private keys in NVRAM
which might be a security advantage.
8. Open Issues
Is there a need for a SIP response code that indicates that a bad
certificate was used and that the user should flush this certificate
from their cache and try again?
It is likely that SIP requires a certificate separate from the one
used for email. This would require an HTTP get of:
https://a.example.com:7000/search-cgi?sip=bob%40example.com
This is likely needed.
9. Comparison with Identity
The ietf-sip-identity [7] draft is about allowing the Service to
assert the identity of a Subscriber to others. It does not deal with
signing or encrypting messages from one user to another which is the
focus of this draft. It does make the same primary assumption that
the Service is trusted by the Subscriber and that the service is
trustworthy enough to adequately authenticate the Subscribers.
10. IANA Considerations
There are no IANA considerations.
11. Conclusion
The procedure described in this document is easy and it can happen
automatically with no extra expense or intervention from the
Subscriber or Caller. It is easy for the Service to provide and does
not require them to do much beyond running a normal HTTPS web service
suitable for e-commerce application. It achieves about as good a job
of identifying the participants of a call as the SIP S/MIME mechanism
is capable of achieving. It does not require any modification of
existing protocols or the invention of any new ones.
Jennings Expires August 14, 2004 [Page 12]
Internet-Draft Cert Discovery February 2004
12. Acknowledgments
Many thanks to Eric Rescorla, Peter Gutmann, Rohan Mahy and Jason
Fischl for comments.
Normative References
[1] 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.
[2] Gutmann, P., "Internet X.509 Public Key Infrastructure
Operational Protocols: Certificate Store Access via HTTP",
draft-ietf-pkix-certstore-http-05 (work in progress), March
2003.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[5] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP", RFC 2585,
May 1999.
Informational References
[6] Olson, S., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-03 (work in progress), June
2003.
[7] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-01 (work in progress), August 2003.
[8] Gustafson, D., Just, M. and M. Nystrom, "Securely Available
Credentials - Credential Server Framework",
draft-ietf-sacred-framework-07 (work in progress), November
2003.
[9] Freed, N. and K. Moore, "Definition of the URL MIME
External-Body Access-Type", RFC 2017, October 1996.
Jennings Expires August 14, 2004 [Page 13]
Internet-Draft Cert Discovery February 2004
Author's Address
Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Jennings Expires August 14, 2004 [Page 14]
Internet-Draft Cert Discovery February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Jennings Expires August 14, 2004 [Page 15]
Internet-Draft Cert Discovery February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings Expires August 14, 2004 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 09:22:35 |