Subject: [IPSECKEY] Generic algorithm test

From: Sam Weiler <[email-masked]>
Date: Wed, 4 Jun 2003 23:04:55 -0400 (EDT)

On Fri, 30 May 2003, Sam Weiler wrote:

> >     Sam> Section 2.4: Needs to have generic text for any value, then the
> >     Sam> expansion for RSA and maybe mention the DSA doc, but not in it's own
> >     Sam> subsection.
> 
> This is now 2.6/2.7.  The new section 2.3 isn't clear on how (or if) 
> IPSECKEY automatically incorporates newly defined public key formats.
> This needs to be clarified. 
> 
> 2.6 Should have generic text specifying how any key format is included,
> with RSA and DSA given as examples, assuming that we want this to be
> extensible.  If we want to limit it to RSA/DSA, that should be made more
> explicit.

I've been having second thoughts about the wisdom of inheriting from
the DNS Algorithm registry.  Are all of the defined alogirthm types
appropriate for IPSECKEY use?  Is it likely that future ones will be?
Remember that DNSSEC algorithms specify a hash, too, which is why
RSA/MD5 and RSA/SHA1 have different algorithm values even though the
data format is exactly the same.  Do we want to prohibit use of type 1
(RSA/MD5)?  What about the private formats?

Assuming that inheritance is desired, here's some proposed text:

RFC2535 established an IANA registry for DNS Security Algorithm
Numbers, and subsequent documents have specified algorithms and
associated KEY RR formats for use with DNSSEC.  Rather than respecify
those formats, this document reuses that registry and the associated
KEY RR formats.  

The algorithm type field identifies the public key's cryptographic
algorithm and determines the format of the public key field.  

The public key field contains the algorithm-specific portion of the
KEY RR RDATA, omitting the first four octets of the KEY RR RDATA.
This is the same portion of the KEY RR that must be specified by
documents that define a DNSSEC algorithm.  Those documents also
specify a message digest to be used for generation of SIG RRs; that
specification is not relevant to the IPSECKEY usage of the public key
format.

Example: RSA public keys

Per the DNS Security Algorithm registry, an algorithm type of 5
identifies an RSA public key, encoded as described in section 2 of
RFC3110.  [The encoding of RSA/MD5 KEYs (type 1) specified in RFC2537
is the same as that defined in RFC3110.  For simplicity and in keeping
with RSA/MD5 being NOT RECOMMENDED for DNSSEC, type 1 SHOULD NOT be
used in the IPSECKEY algorithm type.]

The earlier definition of RSA/MD5 (algorithm type 1) in RFC2065
limited the exponent and modulus to 2552 bits in length.  RFC3110
extended that limit to 4096 bits for RSA/SHA1 keys (type 5).  The
IPSECKEY RR imposes no length limit on type 5 public keys, other than
the 65535 octet limit imposed by the two-octet length encoding.  This
length extension is applicable only to IPSECKEY and not to KEY RRs.

And in the IANA considerations:

This document updates the IANA Registry for DNS Resource Record Types
by assigning type X to the IPSECKEY record.  

The values for the algorithm type field in the IPSECKEY record are
inherited from the DNS Security Algorithm Numbers registry, and this
document makes no changes to that registry.

-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Jun 2003 10:58:34 -0400

>>>>> "Sam" == Sam Weiler <[email-masked]> writes:
    Sam> I've been having second thoughts about the wisdom of inheriting from
    Sam> the DNS Algorithm registry.  Are all of the defined alogirthm types
    Sam> appropriate for IPSECKEY use?  Is it likely that future ones will be?

  If there are future public key algorithms defined, they would be appropriate.
  
    Sam> Remember that DNSSEC algorithms specify a hash, too, which is why
    Sam> RSA/MD5 and RSA/SHA1 have different algorithm values even though the

  Yes, as does IKE, for the same reason.
  If we do not want to use DNSSEC values, then we can use IKE values:

http://www.iana.org/assignments/ipsec-registry

  It doesn't matter to me.
  Or we can create a new space.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-
This is the [email-masked] list.
Email to [email-masked] to be removed.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Jun 2003 10:59:42 -0400

Well, I take that back. IKE values do not specify the format of the public
key. That's really what we care about - that the bits-on-the-wire format
is "well known"

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 10 Jun 2003 14:13:59 -0400

>key. That's really what we care about - that the bits-on-the-wire format

I think that separate registry is in order, the requirements for
registration are reference to IKE algorithm, reference to DNS key wire
format or specification of wire format.
Adding new algorithm requires IETF [consensus, standards action] ?

Value 1 is IKE authentication method 3 and format is RSA/MD5
         specified in RFC2536.
etc.

         Olafur

-