I intend to have a document ready for Atlanta on this subject.

[Richard Shockey <rshockey@ix.netcom.com>]

One . I certainly support another BOF on the subject.

Two I will have a draft ready on the use of DDDS and NAPTR records for the 
discovery of public keys and other cryptographic materials shortly.

It will not be perfect but I hope it will be "pretty good".

If anyone would like help on the BOF proposal I'd be delighted to lend a 
hand...

This is part of the Introduction to my ( to be posted ID ) if the text is 
useful .. steal it.

When the draft is ready I will add text to have discussion of it posted to 
this list.

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 
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.

Actions by the DNS Extensions WG in bringing forward for Proposed Standard 
"Limiting the Scope of the KEY Resource Record" [RESTRICT-KEY] clearly 
signal the consensus in the IETF that applications SHOULD NOT directly use 
the DNS for the storage of 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 
large burden on the DNS infrastructure that in the opinion of most 
observers is "not a good thing"tm.

The problem of DNS infrastructure over load is well known. [Randy Bush 
horses and saddlebags ?]

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 [DDDS 1-5] is currently used now and how DDDS could be 
used by specific applications to discover key material





 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:richard@shockey.us> or <mailto:richard.shockey@neustar.biz>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<