Internet Draft Richard Shockey
Peter C. Davis
Document: draft-shockey-ddds-pki-00.txt NeuStar, Inc.
Expires: April 2002 October 2002
Use of the DDDS System for Cryptographic Key Discovery and Retrieval
draft-shockey-ddds-pki-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
Conventions used in this document
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 [KEYWORDS].
Abstract
<Shockey> Expires û April 2003 [Page 1]
<draft-shockey-ddds-pki-00.txt> October 2002
This document discusses the use of the Dynamic Delegation Discovery
System [RFC 3401-6] for the discovery and retrieval of application
specific cryptographic objects.
This is a work in progress.
Comments are welcome on the following mail list.
keydist@cfax.se
To subscribe to this list send a message to keydist-
request@cafax.se
With subscribe in the body.
Table of Contents
1. Introduction...................................................2
2. REQUIREMENTS FOR APPLICATION SPECIFIC PUBLIC KEY INFRASTRUCTURE.
(NEEDS WORK)......................................................4
3. CURRENT USE OF DDDS AND NAPTR RECORDS..........................4
3.1 CURRENT EXAMPLE: ENUM [RFC2916BIS].........................6
3.2 CURRENT EXAMPLE SIP SERVER LOCATION- [RFC 3263]............7
4. POSSIBLE USES OF DDDS IN DISCOVERY AND RETRIEVAL OF PKI MATERIAL8
4.1 POSSIBLE USE: FINDING X.509 CERTIFICATES ASSOCIATED WITH A
FULLY QUALIFIED DOMAIN NAME....................................8
4.2 POSSIBLE USE: S/MIME PK'S IN SMTP..........................9
4.3 PGP KEYS IN SMTP..........................................11
5. SIP, S/MIME AND MEDIA SECURITY................................11
6. Other Possible Uses...........................................13
6.1 IPSEC û TBD Larger issue Is IPSEC an application or a
infrastructure issue..........................................13
6.2 UDDI Registers............................................13
7. Security Considerations.......................................13
8. References....................................................13
Acknowledgments..................................................14
Author's Addresses...............................................14
1. Introduction
Considerable discussion has occurred within the IETF on the question of
how or should applications use the DNS to store and retrieve a variety
of cryptographic and security related objects. Discussion has centered
on the desire to separate the management of the Public Key
Infrastructure required for the internal security of the DNS [DNSSEC]
vs. those that keys may be needed by specific applications such as
S/MIME.
<Shockey> Expires û April 2003 [Page 2]
<draft-shockey-ddds-pki-00.txt> October 2002
Actions by the DNS Extensions WG in bringing forward for Proposed
Standard "Limiting the Scope of the KEY Resource Record" [RESTRICT-KEY]
potentially signal a consensus in the IETF that applications SHOULD NOT
directly use the DNS for the storage of application specific keys.
Recently a Birds of Feather meeting was held at IETF 53 in Minneapolis
on the subject of how applications should store keys [SIKED]. No
consensus was reached but several approaches were outlined. [LEWIS-
SIKED], [JOSEFSSON-SIKED], [DAIGLE-NAPSTR]
There is a growing need for the discovery and retrieval of key material
in what has been referred to as "opportunistic encryption" environments.
Opportunistic encryption is defined as secure communications between
individuals on endpoints without any prior arrangement or knowledge of
the existence of the parties before secure communications is
established.
A more substantial argument in favor of placing application specific
keys and security objects outside the DNS infrastructure is that
typically DNS queries use UDP, however since most security keys or
digital certificates are large objects, which would require the use of
TCP, this then places a larger burden on the DNS infrastructure that in
the opinion of some observers is ônot a good thingö.
The problem of DNS infrastructure over load is well known.
[Randy Bush horses and saddlebags URI?]
The concept of a new DNS Resource Record for applications to store
public keys in was presented in [APPKEY]. DDDS offers a similar but more
flexible and definable infrastructure not only for keys but other forms
of cryptographic material, such as certificates by referencing to
pointers through a DDDS infrastructure and not storing those keys or
security material directly in the DNS.
In addition DDDS offers within the NAPTR RR structure a service-
parameter field that can be flexibly constructed to contain detailed
data about the nature and type of security object referenced.
This document outlines several examples on how the Dynamic Delegation
Discovery System [RFC 3401-6] is currently used now and how DDDS could
be used by specific applications to discover key material.
<Shockey> Expires û April 2003 [Page 3]
<draft-shockey-ddds-pki-00.txt> October 2002
It is recommended that readers of this document first familiarize
themselves with the core DDDS documents [RFC 3401-6] .
2. REQUIREMENTS FOR APPLICATION SPECIFIC PUBLIC KEY INFRASTRUCTURE.
(NEEDS WORK)
A. Keys and other cryptographic materials should be stored in trusted
locations other than in the DNS itself or the reverse DNS directory
(IN-ADDR.ARPA ûIPV6.ARPA)
B. Pointers to keys or other similar material SHOULD be flexible
enough to permit descriptive parameters of the nature and
application use of the key. Specifically
a. Application Usage
b. Key Type
c. Key Type Version
d. Key Length
C. Multiple applications should be able to store information about
keys associated with a single globally unique identifier such as a
URI, SMPT address, FQDN etc.
3. CURRENT USE OF DDDS AND NAPTR RECORDS
DDDS is a general purpose system for the retrieval of information based
on an application specific input string and applying well known rules to
transform that string until a terminal condition is reached requiring a
look up into a application specific defined database or execution of a
URL based on the application defined rules. DDDS defines a specific type
of definable DNS Resource Record, NAPTR records, for the storage in the
DNS of information necessary to apply DDDS rules.
The Generic Definition of DDDS can be described as follows (adapted from
[DAIGEL-SIKED])
A. Application Unique String
The Application Unique String is the globally unique name for an
endpoint authoritative for a particular service sought.
B. First Well Known Rule
<Shockey> Expires û April 2003 [Page 4]
<draft-shockey-ddds-pki-00.txt> October 2002
The "First Well Known Rule" is the construct of an application specific
sequence of transformations for which the identity or location for an
authoritative server for a particular service is sought.
C. Expected Output
The expected output of the DDDS application transformation is the
information necessary to connect to authoritative server(s) (host, port,
protocol) for an application service within a given a given domain.
D. Flags
DDDS flags defines the scope of the transformation. Currently two flags
are defined for DDDS applications Application.("S" and "A"). Both "S"
and "A" are for terminal lookups. This means that the Rule is the last
one and that the flag determines what the next stage should be.
The ôUö flag means that the output of the rule is a URL.
The "S" flag means that the output of this Rule is a domain name for
which one or more SRV records exist.
The "A" flag means that the output of the Rule is a domain name and
should be used to lookup address records for that domain.
E. Services Parameters
Service Parameters for DDDS can take the form of a string of characters
that follow an ABNF syntax:
service-parms =[ [app-service] *("+" app-protocol)]
app-service = 1*32(ALPHA / DIGIT)
app-protocol = token *[":" token ":" token]
token = 1*32(ALPHA / DIGIT)
The app-service and app-protocol fields are limited to 32 characters and
must start with an alphabetic character. Thus, the Service Parameters
may consist of an empty string, just an app-service, or an app-service
with one or more app-protocol specifications separated by the "+"
symbol.
F. Application Services
<Shockey> Expires û April 2003 [Page 5]
<draft-shockey-ddds-pki-00.txt> October 2002
The "app-service" must be a registered service, in an IANA defined
registry.
G. Application Protocols
The protocol identifiers that are valid for the "app-protocol"
production are any standard, registered protocols.
H. Valid Databases
At present only the DNS as a valid DDDS Database has been specified in
IETF protocols. [RFC 3403] specifies a DDDS Database that uses the
NAPTR DNS resource record to contain the rewrite rules. The Keys for
this database are can be encoded as domain-names.
The DDDS system requires ach application wishing to use DDDS defines its
application, application unique input string, rules for transformation,
list of valid databases and expected final output in an RFC.
Currently two IETF protocols use DDDS and NAPTR RR records for the
retrieval of application specific data. ENUM [RFC 2916] and SIP -
Locating SIP Servers [RFC 3263]. These applications should be considered
as valid examples of DDDS in use today.
3.1 CURRENT EXAMPLE: ENUM [RFC2916BIS]
RFC 2916bis takes as its input string a fully qualified E.164 telephone
number and by applying well known rules, creates a Fully Qualified
Domain Name which is then used to execute a lookup into the DNS for
services associated with that phone number defined as NAPTR records [RFC
2915/DDDS2].
Example:
A. Application Unique String = +4689761234
B. First Well Know Rule
1. Remove all characters with the exception of the digits
this step would simply remove the leading "+", producing
"4689761234"
<Shockey> Expires û April 2003 [Page 6]
<draft-shockey-ddds-pki-00.txt> October 2002
2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4
3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4
4. Append the string ".e164.arpa" to the end. Example:
4.3.2.1.6.7.9.8.6.4.e164.arpa
C. Query DNS
In this example the database is DNS and the query uses the FQDN to
discover the services associated with this E.164 number expressed as
NAPTR Resource Records.
Response from the DNS:
$ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa.
order pref flags enumservice regexp
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@network.foo!" .
IN NAPTR 102 10 "u" "E2U+smpt" "!^.*$!mailto:info@domain.bar!" .
Of particular note the NATRR flag "u" is defined as that the end result
of the transformation is a URI and the service field has been defined by
[RFC2916bis] through a enumservice field specific ABNF syntax defined
as:
service_field = "E2U" 1*("+" enum-service)
enum-service = token *[":" token ":" token]
token = 1*32(ALPHA / DIGIT)
Where tokens represent various capabilities, descriptions or protocols
supported an endpoint.
3.2 CURRENT EXAMPLE SIP SERVER LOCATION- [RFC 3263]
RFC 3262 defines how SIP applications can discover the various aspects
of SIP proxies in other domains. The use of DDDS by SIP is noteworthy
since SIP, unlike many other protocols can run over different transport
protocols, consequently is it necessary to discover and select the
<Shockey> Expires û April 2003 [Page 7]
<draft-shockey-ddds-pki-00.txt> October 2002
appropriate servers that can support those protocols before a
communications session can be established.
Example:
Input String [URI] = sip:calledparty@example.bar
First Well-known rule:
A. Decompose SIP URI to find SIP domain.
B. Query DNS
Response from the DNS for NAPTR records in the domain example.bar
; order pref flags service regexp replacement
IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.bar.
IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.bar.
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.bar.
The flag "s" is defined as the transformation of the replacement field
into a further look up for SRV records. This example indicates that the
domain supports TLS over TCP, TCP, and UDP, in that order of preference.
4. POSSIBLE USES OF DDDS IN DISCOVERY AND RETRIEVAL OF PKI MATERIAL
DDDS offer the opportunity for a much more varied and definable
infrastructure for PKI than other proposals.
4.1 POSSIBLE USE: FINDING X.509 CERTIFICATES ASSOCIATED WITH A FULLY
QUALIFIED DOMAIN NAME
Though the IETF has defined a Resource Record for the storage of
certificates, RFC 2538 it is conceivable that different applications
will have different requirements for certificates and that multiple
Certificate Authorities (CA) will need to reference their certs to a
single FQDN.
Example:
Input string [FQDN] = foobar.example.biz
Response from the DNS:
<Shockey> Expires û April 2003 [Page 8]
<draft-shockey-ddds-pki-00.txt> October 2002
order pref flags service regexp
IN NAPTR 100 10 "u" "5092U+di:http:s:" "!^.*$!http:pkidata.example.foo!".
IN NAPTR 102 10 "u" "5092U+appfoo:ldap:" "!^.*$!ldap:pkdata1.example.bar!" .
Where "di" might represent a digital identity application and ôappfooö
is something else
A general ABNF construct for 509 specific service fields could similar
to the one used in ENUM.
service_field = "5092U" 1*("+" certservice)
certservice = application *[":" label ":" label ":" label]
label = 1*32(ALPHA / DIGIT)
The label construct of the cert-service field could contain various
descriptive elements of the capabilities and character of the
certificate to be retrieved such as signed or unsigned, transport
mechanism.
TBD .. What labels are appropriate for 509 certificates?
4.2 POSSIBLE USE: S/MIME PK'S IN SMTP
The IETF has developed the S/MIME specification to permit the encryption
of MIME type objects. There has been considerable interest in use of
this technology in encrypting SMPT messages. The following example
describes a possible way DDDS could be used to discover and retrieve
PK's from an intended recipients PK repository without any prior
knowledge of the recipient Public Key Infrastructure.
Example Bob wishes to send secure email to Alice. Bob knows Alice's
email address. Bob's mail user agent uses the email address as the input
string for a DDDS query to the DNS to obtain Alice's public key.
Example:
A. Input String [SMTP address] = alice@example.us
C. First Well Known Rule =
<Shockey> Expires û April 2003 [Page 9]
<draft-shockey-ddds-pki-00.txt> October 2002
a. Take the SMPT address and decompose it into the user part and
the domain.
b. Perform a DNS query requesting all NAPTR records the domain [
example.foo ]
c. Search response from DNS NAPTR pkservice field records for
available PK repositories supported
Response from the DNS:
order pref flags service regexp replacement
IN NAPTR 100 10 "n" "PK2U+smime:pkcs7:https" "" ôpkinfo.example.bar/[input]ö.
IN NAPTR 90 10 "n" "PK2U+smime:pkcs7:ldaps" "" ôpkinfo2.example.bar/[input]ö.
d. Perform a transformation of the hostname and transport type
required.
e. Apply user part of the input string to the input portion of
the regular expression to
f. Construct the appropriate URL from the transport portion of
the PK service field
In this example the flag "n" is defined as the transformation of the
replacement field is non-terminal and requires an additional
substitution of the username "recipient" into the [input] field of the
replacement the preference as well as a rewrite into a URL based on the
transport in the pkservice field.
One possible ABNF construct of the pkservice field could be:
service_field = "PK2U" 1*("+" pkservice)
pkservice = application *[":" type ":" transport ":" label]
type = 1*32(ALPHA / DIGIT)
transport = 1*32(ALPHA / DIGIT)
label = 1*32(ALPHA / DIGIT)
The final output to retrieve the pkcs7 key for alice@example.us would
be:
https://pkinfo.example.bar/alice
Alternatively the output result should LDAP transport be selected would
be
<Shockey> Expires û April 2003 [Page 10]
<draft-shockey-ddds-pki-00.txt> October 2002
ldaps://pkinfo2.example.bar// (what the heck would the string look like
since I'm no LDAP guru)
4.3 PGP KEYS IN SMTP
PGP uses its own infrastructure to distribute keys in trusted circles,
however most PGP key exchange is out of band.
A. Input String [SMTP address] = bob@example.us
B. First Well Known Rule =
a. Take the SMPT address and decompose it into the user part and
the domain.
b. Perform a DNS query requesting all NAPTR records the domain
[example.us]
c. Search response from DNS NAPTR pkservice field records for
available PK repositories supported
Response from the DNS:
order pref flags service regexp replacement
IN NAPTR 100 10 "n" "PK2U+pgp:rsa-x:https" "" ôpkinfo.example.foo/[input]ö.
IN NAPTR 90 10 "n" "PK2U+pgp:rsax:ldaps" "" ôpkinfo2.example.foo/[input]ö.
Where the application type in the pkservice field is now ôpgpö and the
key type is ôrsa-xö denoting a form or RSA key and perhaps key size.
Questions ..is the following examples an appropriate use of the
replacement field outlined in RFC 3401-6????
5. SIP, S/MIME AND MEDIA SECURITY
SIP [RFC3261] recommends the usage of S/MIME to protect the bodies of
SIP requests. Many forms of sensitive information can appear in SIP
message bodies, including the Session Description Protocol [RFC 2327]
and even instant messages.In order to encrypt such bodies before
transmitting a SIP message, one must know the public key of the intended
recipient of the request.
There are a number of reasons why encrypting SDP is desirable. If
arbitrary third-parties can inspect SDP, they may learn the IP addresses
and ports used for media by endpoints that are participating in a SIP
<Shockey> Expires û April 2003 [Page 11]
<draft-shockey-ddds-pki-00.txt> October 2002
session, and may use this knowledge to attempt attacks such as
eavesdropping on session media or denying service by flooding these
resources.
Also, several proposals have been made to carry session keys used for
encrypting media traffic within SDP or in other SIP bodies. S/MIME can
secure SDP in order to prevent these session keys from being learned by
potential eavesdroppers.
While S/MIME keys can be exchanged in SIP as described in RFC 3261, this
method is only secure if the keys are contained in a certificate that
has been issued by an authority recognized by the participants in the
SIP dialog. Exchange of self-signed certificates or unsigned public keys
would be vulnerable to a man-in-the-middle attack.
The DNS provides one way that the public key of the destination could be
ascertained before an initial SIP request is sent, one that potentially
has a higher degree of security than the exchange of self-signed
certificates in SIP. The Request-URI of a SIP request could be resolved
via the DNS to discover a NAPTR record specific to the user in question.
Note that the SIP specificationÆs mechanism for locating SIP servers
[RFC3263] already entails support for NAPTR records (as do popular SIP
applications such as ENUM).
As an example, given a Request-URI of æsip:joe@example.fooÆ, when the
NAPTR RRs for æexample.fooÆ are returned, they might contain the
following:
order pref flags service regexp
IN NAPTR 100 10 "u" "5092U+di:sip:http:" "!^joe(.*)$!https:pkidata.example.foo!"
.
Once this NAPTR record has been received by the client, it can make a
secure HTTP connection to pkidata.example.foo in order to download the
key for joe. Once the key has been learned, it can be used to apply
security properties to the body of the first SIP request sent to joe.
This sort of access to public keys is most secure when the keys are
distributed within certificates. Otherwise, the host from the which the
public key is downloaded (in the example above, pkidata.example.foo)
must have some other reference integrity with the URI that the
originator is attempting to reach. For example, if the originator is
attempting to reach æsip:joe@example.fooÆ, the host from which the key
is downloaded must be in the domain of æexample.fooÆ. In order for this
<Shockey> Expires û April 2003 [Page 12]
<draft-shockey-ddds-pki-00.txt> October 2002
process to be secure, both DNSSEC and strong security on the HTTP
download (such as TLS, which is prescribed by the HTTPS URI scheme) are
necessary.
6. Other Possible Uses
6.1 IPSEC û TBD
Larger issue Is IPSEC an application or a
infrastructure issue.
6.2 UDDI Registers
UDDI is an emerging technology for the discovery of services associated
with a business or enterprise. There has been some suggestion that DNS
TXT files could be used to discovery of UDDI directories. DDDS offers a
more robust and flexible method for the discovery of these servers.
Input String: business.biz
Response to query in DNS for NAPTR records for business.biz:
order pref flags service regexp
IN NAPTR 100 10 "u" "UDDI2U+https" ô!^.*$!https://business.biz/commerce/WebServDir!" .
IN NAPTR 100 10 "u" "UDDI2U+ldaps" ô!^.*$!ldaps:uddiweb.business.biz!" .
7. Security Considerations
No unique security considerations are associated with application
specific PKI using DDDS or NAPTR records over and above those already
associated with the DNS infrastructure itself. Well-known attacks, such
as man-in-the-middle are possible against any of these examples in the
absence of DNSSEC and other methods. Attack against the security object
servers themselves is also possible.
A variety of security issues are involved in multiple roundtrips for the
discovery of data. TBD
8. References
<Shockey> Expires û April 2003 [Page 13]
<draft-shockey-ddds-pki-00.txt> October 2002
[RFC 2916bis] Faltstrom,P.and Mealling,M. ôThe E.164 to URI DDDS
Applicationsö,draft-ietf-enum-rfc2916bis-01.txt, (work in
progress), May 2002
[RFC 3263] Rosenberg,J.and Schulzrinne,H., ôSession Initiation
Protocol (SIP) : Locating SIP Serversö, RFC 3263, June 2002
[SIKED] Secure Internet Key Distribution BOF (siked) Agenda IETF 53;
http://www.ietf.org/mail-archive/ietf-
announce/Current/msg17495.html
[LEWIS-SIKED] Lewis,E. ôDiscussing Application Public Keys in the
DNSö, http://www.ietf.org/internet-drafts/draft-lewis-siked-
dnsargs-00.txt (work in progress), February 2002
[DAIGEL-SIKED] Daigel,L.and Newton,A., ôNAPSTR: A constrained use of
NAPTR and SRV RRs for domain-based service locationö,
http://www.ietf.org/internet-drafts/draft-daigle-napstr-
00.txt,(work-in-progress),Feburary 2002
[JOSEFSSON-SIKED] Josefsson,S.and Griffin,W., ôNotes on Application
Key Distributionö, http://www.ietf.org/internet-drafts/draft-
josefsson-siked-framework-00.txt (work in progress),Feburary 2002
[APPKEY] Schlyter,J., ôStoring application public keys in the DNSö,
draft-schlyter-appkey-02.txt (work in progress) Feburary 2002
[RFC 3401-6] Mealling, M., "Dynamic Delegation Discovery System
(DDDS) RFC 3401-6 inclusive, October 2002.
[KEYWORDS] Bradner,S., "KEY WORDS FOR USE IN RFCS TO INDICATE
REQUIREMENT LEVELS", RFC 2119, March 1997.
[RESTRICT-KEY] Massey,D.and Rose,S., ôLimiting the Scope of the KEY
Resource Recordö, draft-ietf-dnsext-restrict-key-for-dnssec-04.txt
(work in progress), September 2002
Acknowledgments
The author(s) gratefully acknowledges the comments and suggestions of
Jon Peterson on issues involving S/MIME and SIP and William Sylvester
both of NeuStar. That said, the numerous errors and omissions in this
document are the sole responsibility author(s) Shockey in particular.
Author's Addresses
<Shockey> Expires û April 2003 [Page 14]
<draft-shockey-ddds-pki-00.txt> October 2002
Richard Shockey
NeuStar, Inc.
4600 Center Oak Plaza
Sterling, VA 20166 US
Phone: + 1 571.434.5651
EMail: richard.shockey@neustar.biz
http://www.neustar.biz/
Peter C Davis
NeuStar, Inc.
4600 Center Oak Plaza
Sterling, VA 20166 US
Phone: + 1 571.434.5516
EMail: peter.davis@neustar.biz
http://www.neustar.biz/
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 assigns.
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
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
<Shockey> Expires û April 2003 [Page 15]
<draft-shockey-ddds-pki-00.txt> October 2002
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
<Shockey> Expires û April 2003 [Page 16]