Subject: [dnsext] DNSKEY / multiprecision number format?

From: Dean Anderson <[email-masked]>
Date: Sat, 30 Aug 2008 23:14:44 -0400 (EDT)

[ Note: Post was moderated. ] 

I'm wondering how the exponent and modulus are stored in a DNSKEY record 
for RSASHA1.  RFC3110 just makes some vague references to where things 
go, but does not define their precise format: 

         exponent length   1 or 3 octets (see text)
         exponent          as specified by length field
         modulus           remaining space

The format of large binary numbers is never specified in RFC3110, and no
standard exists that I can find. I notice that BIND tools just use the
openssl library calls bn2bin, which produces an undefined and
non-standardized openssl format.  GMP and presumably other
multiprecision libraries have their own format. GMP's mpz_import
function has a number of parameters for importing from different binary
multiprecision number formats:

  count, 
  order, 
  size, 
  endian, 
  nails

http://gmplib.org/manual/Integer-Import-and-Export.html#Integer-Import-and-Export
 "The parameters specify the format of the data. /count/ many words are 
  read, each /size/ bytes. order can be 1 for most significant word
  first or -1 for least significant first. Within each word /endian/ can
  be 1 for most significant byte first, -1 for least significant first,
  or 0 for the native endianness of the host CPU. The most significant
  /nails/ bits of each word are skipped, this can be 0 to use the full
  words. "

The only one that can be inferred from an instance of an DNSKEY RR is
count.

So, can anyone say what the remaining 4 parameters should be for DNSKEY
and other DNSSEC records?

Is there an RFC that defines these parameters?

Thanks,

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

--
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: Eric Rescorla <[email-masked]>
Date: Fri, 05 Sep 2008 08:26:07 -0700

At Sat, 30 Aug 2008 23:14:44 -0400 (EDT),
Dean Anderson wrote:
> non-standardized openssl format.

As I recall, it's simply the bytes laid out in bigendian order with 
no sign bits. I.e., given the bytes on the wire laid out as:
 
B[0] B[1] B[2] .... B[n]

This translates to:

(B[0] * 2^n-1)  +  (B[1] * 2^n-2)  +  (B[2] * 2^n-3) + ... B[n]

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 08 Sep 2008 20:47:03 -0700

At Mon, 8 Sep 2008 22:37:52 -0400 (EDT),
Dean Anderson wrote:
> 
> On Fri, 5 Sep 2008, Eric Rescorla wrote:
> 
> Is there an RFC that specifies this? (that there are no sign bits, no
> nails, that the number is cannot be a series of 2byte or 4byte
> 'bigendian'? [there are different notions for 4byte bigendian, too],
> etc)?  Shouldn't this be specified somewhere? 

A number of documents that use this style of encoding do specify it,
with varying degrees of clarity:

E.g.,
RFC 5246 S 4.4.
RFC 2436 S 4.1, 4.2
RFC 4306 S 3.1

I haven't taken the time to check whether the DNSSEC specs are
equally clear. I agree that they should explicitly state the
representation, however this is more or less the standard
representation that people use for public key math, so it's
not enormously confusing in any case.

> BTW, taking a 4 byte number, n=3, your formula doesn't give a very
> meaningful result:
> 
> (B[0] * 2^2) + (B[1] * 2^1)  +  (B[2] * 2^0) + ... B[3]

Sure. Chalk that up to the difference between a specification and an
email message.

-Ekr

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 9 Sep 2008 12:08:00 +0200

> Sure. Chalk that up to the difference between a specification and an

Dean,

For what its worth.

When implementing Net::DNS::SEC I followed the above mentioned  
interpretation. And for NSD, Unbound and ldns that interpretation was  
also followed. The later mentioned code bases are somewhat related,  
the first mentioned code was developed independently (albeit now also  
maintained at NLnet Labs). All 4 are developed independently from BIND  
and the whole mesh seems to interoperate.

More importantly there is a document with updates and clarifies DNSSEC- 
bis based on implementation experience: http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates-07

That is a perfect place to add some text about the format. I'd suggest  
you supply text.

--Olaf

---

From: Dean Anderson <[email-masked]>
Date: Mon, 8 Sep 2008 22:37:52 -0400 (EDT)

I think I know what you mean, but nowhere is it well specified.

Thanks,

		--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 9 Sep 2008 10:09:40 -0400

On Tue, Sep 09, 2008 at 12:08:00PM +0200, Olaf Kolkman wrote:

> That is a perfect place to add some text about the format. I'd suggest you 
> supply text.

Excellent idea!  Thanks, Olaf.  Dean, can we expect some text from
you?

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 10 Sep 2008 12:09:16 +0200

> Sure. Chalk that up to the difference between a specification and an

I think the "problem" is that the base should be 256 and not 2, as it is about 
bytes and not bits.

Regards,

Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Wed, 10 Sep 2008 12:12:10 +0200

Klaus Malorny wrote:
> I think the "problem" is that the base should be 256 and not 2, as it is
> about bytes and not bits.
>

And, sorry, for the additional e-mail, n is 4 for a 4 byte number.

Klaus

---

From: Mark Andrews <[email-masked]>
Date: Thu, 11 Sep 2008 07:19:34 +1000

They are just n byte integers in network byte order.  Note
	to get the size of the exponent you had to know about 2
	byte integers in network byte order.  Just because n was
	not a power of two doesn't make them special.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Fri, 12 Sep 2008 14:57:21 -0400 (EDT)

> Excellent idea!  Thanks, Olaf.  Dean, can we expect some text from

Yes. I'll supply text.  Monday Ok?

		--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Sep 2008 15:56:21 -0400

> Yes. I'll supply text.  Monday Ok?

Sure, whenever you have a chance.  (Note, however, that I'm not the
document editor, so they'll be the ones who will be reviewing your
proposed text.)

A