Subject: Eliminating KEY Algorithms

From: Daniel Massey <[email-masked]>
Date: Tue, 19 Mar 2002 23:29:34 -0500

Hi,

draft-ietf-dnsext-restrict-key-for-dnssec-01.txt, which has
passed WG last call, did not change any KEY algorithm types.  
In hindsight, it would have been nice to eliminate types 
252, 253, and 254. 

  Type 252 is an "indirect key".  
  Type 253 is "private - domain name".
  Type 254 is "private - OID".

After eliminating these types, the KEY Algorithm Table would be:

   VALUE   Algorithm                   Defining RFC          
    0      Reserved                    -            
    1      RSA/MD5                     RFC 2536
    2      Diffie-Hellman              RFC 2539
    3      DSA                         RFC 2536
    4      Elliptic Curve              -       
    5      RSA/SHA1                    RFC 3110
    6-254  available for assignment    -
    255    reserved                    - 

This was discussed in Minneapolis, and there were no objections.
Any list objections are requested by 5pm GMT on Sat Mar 23.
If there are no objections, this will be added to the
restrict-key draft without restarting the WG last call.  

Dan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Mar 2002 09:06:06 -0500

>  Type 254 is "private - OID".

Since indirect keys are not useful within DNSSEC, removing that type of key
is allowable.  The other two algorithms do have utility in a just-DNSSEC
realm.  (There is no sense throwing away functionality unless it causes
operational or functional problems.)

While there are changes afoot, can an algorithm number be reserved for
testing - such as for an algorithm that hasn't been developed enough to
warrant an IANA assigned number?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

---

From: Scott Rose <[email-masked]>
Date: Wed, 20 Mar 2002 10:01:13 -0500

> operational or functional problems.)

I agree with Ed here.  252 could be obseleted and freed up, but there is still
some use to 253 and 254.  I don't know if anyone actually is using them, but
there isn't any harm in keeping them in, is there?

> warrant an IANA assigned number?

Maybe redefinition of the 253 number?  for "private" instead of "private -
domain name"?  either way, private is private.  Most servers would not
understand experimental algorithms anyway.

Scott

---

From: Chris Thompson <[email-masked]>
Date: Wed, 20 Mar 2002 15:43:16 +0000 (GMT)

[email-masked] (Scott Rose) writes
> Edward Lewis wrote:
[...]
> understand experimental algorithms anyway.

This is how I read RFC 2535 section 3.2 in the first place. The "domain
name" is just there to (maybe) ensure uniqueness, and has no other semantic 
content. To use

  test42.bizarre-ideas.cet1.ucs.cam.ac.uk

for this purpose, I just have to persuade those responsible for
ucs.cam.ac.uk that they will tell other people to use somthing
not under cet1.ucs.cam.ac.uk for such a purpose. Or if I am lazy,
maybe I don't actually bother to do that negotiation, and just
hope for the best: it's only for testing ... :)

Perhaps the really slovenly can just use the root domain "." ?

Chris Thompson
Email: [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Mar 2002 10:03:09 -0600

> operational or functional problems.)

for we the uneducated, you might enumerate the specific utility they
have.

> warrant an IANA assigned number?

there is a generic draft afoot to address this issue in many of the iana
number spaces.  so per-space solutions might not be useful and might
confuse folk down the pike.

randy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Mar 2002 11:37:42 -0500

>for we the uneducated, you might enumerate the specific utility they

talk about needing to dust off old memories...

Back in the DNSSEC WG days I seem to recall (but haven't had time to
research the archives) that we wrote off indirect keys as not being usable
for the on-line problem of protecting zone data.  Because of that, I paid
no more attention to the indirect keys.  Donald or Olafur probably have a
clearer understanding of what the indirect keys were for.

As I say, this is a recollection.  I need to find out if this is documented
somewhere.  It isn't in the 2535-2540 or so RFCs, nor 3008.

PS, 2535 contains this passage at the bottom of page 43:

>Algorithm code point 252 is designated to indicate "indirect" keys, to be
> defined in a separate document, where the actual key is elsewhere.

Elsewhere is not defined anywhere, making tracking of this difficult.  Not
to pick on Donald, but this is an example of why I pound on documents for
inclusion of (detailed) rationale, and if a topic is "out of scope" at
least indicate where the topic might be found.

BTW, the DNSSEC WG archives are still on-line:
ftp client (not web) to ftp.tislabs.com
cd /pub/lists/dns-security

---

From: Randy Bush <[email-masked]>
Date: Wed, 20 Mar 2002 10:41:32 -0600

> least indicate where the topic might be found.

sounds to me like it would be a good test of the iana key alg number
allocation process when we find the justification and need.

randy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Mar 2002 11:44:54 -0500

>allocation process when we find the justification and need.

I agree.

---

From: Josh Littlefield <[email-masked]>
Date: Wed, 20 Mar 2002 11:53:23 -0500

I would think that indirect keys might have utility for SIG(0).  SIG(0) is
the only remaining use of keys aside from zone signing, but it has
requirements somewhat different from zone signing.  I would think indirect
keys could be useful for key management of keys used for secure updates and
other transactions.  Perhaps private algorithms would also be useful for
this, in some tightly controlled deployments.

-- 
=====================================================================
Josh Littlefield                                  Cisco Systems, Inc.
[email-masked]                                      250 Apollo Drive
tel: 978-497-8378  fax: same               Chelmsford, MA  01824-3627

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Mar 2002 12:29:28 -0500

>>> for we the uneducated, you might enumerate the specific utility they

Culled from the archives.  indirect-key is mentioned off and on until the
agenda for the Oslo meeting, but then disappears from the archives,
although I didn't locate the minutes of that meeting, "indirect" does not
appear in any greps after that.  (dns-security was shut down in Spring
2000.)

>Date: Wed, 10 Dec 1997 22:51:51 -0500 (EST)
>From: "Donald E. Eastlake 3rd" <[email-masked]>
>To: [email-masked]
>Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt
>
>On Sun, 7 Dec 1997, John Gilmore wrote:
>
>> Date: Sun, 07 Dec 1997 21:10:02 -0800
>> From: John Gilmore <[email-masked]>
>> To: [email-masked], [email-masked]
>> Subject: Re: WG Last Call: draft-ietf-dnssec-indirect-key-01.txt
>>
>> It is not clear what problem this draft is trying to solve.
>
>This draft is based on the assumption that key distribution via DNS
>becomes reasonably common.  At least common enough that people go look
>first in the DNS for user/host keys.  Then it seems like there would be a
>number of cases where you would want to use this because they have a
>bunch of keys/certificates elsewhere and want to tell the people looking
>in DNS to go use their existing key/certificate server.
>    The impetus for writing the draft came from an actual large ISP that
>indicated it didn't want to have to put a bunch of user keys into the DNS
>and keep them updated there but would find it much easier to just have
>DNS entries pointing to its key server.
>
>> The "target type" field seems to be encoding numerous separate kinds
>> of information (e.g. the format of the location data (URL or domain
>> name); the format of the data to be retrieved there (KEY RDATA,
>> CERT RDATA, PKCS #1, etc); and the "type" of certificate that might
>> be found there (PKIX, PGP, etc).  Rather than encode various
>> combinations of these, wouldn't separate fields be better?
>
>The -00 draft had this more orthogonal.  But the total number of
>combinations just doesn't seem that high and if you make these things
>orthogonal, there are number of combinations that don't make sense.  I
>guess I'd be willing to change back if people want.
>
>>   John
>
>Donald

---

From: Edward Lewis <[email-masked]>
Date: Wed, 20 Mar 2002 15:09:58 -0500

At 11:53 AM -0500 3/20/02, Josh Littlefield wrote:
>I would think that indirect keys might have utility for SIG(0).

My later posting of the archived rationale isn't meant to dispute
that...perhaps you have something here, I just haven't spent enough time on
SIG(0).

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sat, 23 Mar 2002 00:47:00 -0500

Hi,

If I recall correctly there were a couple of drafts related to
indirect keys. Or at least an initial draft and then later some other
ideas that someone IBMer other than myself had while I was at IBM and
which were presented to some *dns* WG. But given that all such drafts
have timed out and been garbage collected without protest and, as far
as I know, no one ever used indirect keys and would not be justified
in depending on something from a work in progress, it's OK with me if
you want to free up algorithm coee 252.

Thanks,
Donadl

From:  Edward Lewis <[email-masked]>
Message-Id:  <v0313030bb8be758ca7cd@[166.63.190.161]>
In-Reply-To:  <[email-masked]>
References:  <[email-masked]>
	     <v03130301b8be468791a9@[166.63.190.161]>
	     <v03130304b8be66741be7@[166.63.190.161]>
Content-Type:  text/plain; charset="us-ascii"
Date:  Wed, 20 Mar 2002 12:29:28 -0500
To:  Randy Bush <[email-masked]>
Cc:  Edward Lewis <[email-masked]>, [email-masked]
Sender:  [email-masked]

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sat, 23 Mar 2002 00:46:45 -0500

Exactly. These algorithm codes, 253 and 254, are intended for any use
that doesn't care about interoperability. The requirement to put in an
OID or domain name is just to guarantee non-collision of different
private/experimental/test uses. No semantic content is implied by the
OID or domain name other than that whoever allocates the domain name
or OID for this purpose have adequate control over that OID or domain
name.

I think these codes should be retained. Who knows who may be depending
on their currently documented natures? Admittedly, at the glacial pace
algorithm codes are being used, it might be a long time before a
conflicting use was assigned to 253 or 254 but for the same reason
there is very little benefit to freeing them up.

While the current specification is only a Proposed Standard, there is
clearly some desire for such codes for experimental or test use so why
take them away to just have to give them back?

Thanks,
Donald

From:  Chris Thompson <[email-masked]>
To:  [email-masked] (Scott Rose)
Date:  Wed, 20 Mar 2002 15:43:16 +0000 (GMT)
Cc:  [email-masked], [email-masked]
In-Reply-To:  <[email-masked]> from "Scott Rose" at Mar 20, 2 10:01:13 am
Message-Id:  <[email-masked]>