[dnsext] DNSKEY / multiprecision number format?
Dean Anderson
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 namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Olaf Kolkman
--Apple-Mail-4--17971841
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
On Sep 9, 2008, at 5:47 AM, Eric Rescorla wrote:
> At Mon, 8 Sep 2008 22:37:52 -0400 (EDT),
> Dean Anderson wrote:
>>
>> On Fri, 5 Sep 2008, Eric Rescorla wrote:
>>
>>> At Sat, 30 Aug 2008 23:14:44 -0400 (EDT),
>>> Dean Anderson wrote:
>>>>
>>>> [ 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.
>>>
>>> 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]
>>
>> 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.
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
--Apple-Mail-4--17971841
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: This message is locally signed.
iEYEARECAAYFAkjGSwAACgkQtN/ca3YJIofmdQCeJUzjFC4/blX+Jetvn1E9T8xZ
0L8AoIn4BHDX9qDkmYVNtnq9aUwhtD3X
=ofYJ
-----END PGP SIGNATURE-----
--Apple-Mail-4--17971841--
Dean Anderson
On Fri, 5 Sep 2008, Eric Rescorla wrote:
> At Sat, 30 Aug 2008 23:14:44 -0400 (EDT),
> Dean Anderson wrote:
> >
> > [ 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.
>
> 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]
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?
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]
I think I know what you mean, but nowhere is it well specified.
Thanks,
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000