[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IPSECKEY] Generic algorithm test



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 IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.