Re: [keyassure] publishing the public key

[Ilari Liusvaara <[e-mail]>]

On Tue, Feb 15, 2011 at 12:12:08AM -0500, Paul Wouters wrote:
> 
> I understand, but there IS a relationship here. With DANE, you have an
> alternative to PKIX-TLS. So such a change would affect TLS, but would
> require DANE. Similarly, the TLS group could say "we won't add bare
> public key because there is no validation for it" and they'd send me
> back to DANE.
> 
> So please don't call bare public key out of scope yet.

There are actual technical reasons why putting raw TLS keys in DNS
is a bad idea.

- The problems it causes with TLS library APIs.
- The problems it causes with multiple A/AAAA records.
- The problem of not being able to use the sceme for client-to-server.

You need a new TLS certtype anyway. I say it is much better way to
define new raw key TLS certtype and then assure those via DANE.



BTW: Here's one format for raw keys (no ASN.1):

General conventions:
* uint<n> is n-bit (padding by zeroes on most signficant bits of
first octet to be next multiple of an octet) big-endian number.
* poly<L> is an element of GF(2^L) given in polynomial basis
(again padding on most signficant bits of the first octet with zeroes to be
next multiple of an octet).


struct rawkey_certificate {

//TLS HashAlgorithm registry, MUST NOT be 0 (unhashed) nor 1 (MD5). SHOULD
//NOT be 2 (SHA-1).
	uint<8> tls_hash_algorithm; 

//Key type
	uint<16> key_type;

	switch(key_type)
	{
	case 0:
		//RSA
		uint<16> L_rsa_n;
		uint<16> L_rsa_e;
		uint<L_rsa_n> rsa_n;
		uint<L_rsa_e> rsa_e;
	case 1:
		//DSA
		uint<16> L_dsa_p;
		uint<8> L_dsa_q;
		uint<L_dsa_p> dsa_p;
		uint<L_dsa_p> dsa_g;
		uint<L_dsa_p> dsa_y;
		uint<L_dsa_q> dsa_q;
	case 2...20:
		//Prime ECDSA public key (see the table of curves).
		uint<L> ecdsa_Y_x;
		uint<L> ecdsa_Y_y;
	case 21...30:
		//Binary ECDSA public key (see the table of curves).
		poly<L> ecdsa_Y_x;
		poly<L> ecdsa_Y_y;
	//Other key_types to be defined.
	}
}

Constraints for certificate length (L_cert) with different keytypes:

RSA: L_cert >= 7 + ceil(L_rsa_n / 8) + ceil(L_rsa_e / 8)
DSA: L_cert >= 6 + 3 * ceil(L_dsa_p / 8) + ceil(L_dsa_q / 8)
fixed-curve ECDSA: L_cert >= 3 + 2 * ceil(L / 8).


The reason why I did not define arbitrary ECDSA curves is that PKIX forbids
those and defining full elliptic curve format is actually much more
involved than just using a slew of ready-made curves (it could be done, just
allocate a key_type for that).


I didn't do point compression because ECC points are small anyway and
unpacking those if p = 4k + 1 (like NIST P-curves have) is a bit nasty.


Table of curves:

Keytype:	Type:	L:	Curve:
--------	-----	--	------
2		Prime	192	NIST P-192
3		Prime	224	NIST P-224
4		Prime	256	NIST P-256
5		Prime	384	NIST P-384
6		Prime	521	NIST P-521
7		Prime	160	Brainpool P160r1
8		Prime	192	Brainpool P192r1
9		Prime	224	Brainpool P224r1
10		Prime	256	Brainpool P256r1
11		Prime	320	Brainpool P320r1
12		Prime	384	Brainpool P384r1
13		Prime	512	Brainpool P512r1
14		Prime	160	Brainpool P160t1
15		Prime	192	Brainpool P192t1
16		Prime	224	Brainpool P224t1
17		Prime	256	Brainpool P256t1
18		Prime	320	Brainpool P320t1
19		Prime	384	Brainpool P384t1
20		Prime	512	Brainpool P512t1
21		Binary	163	NIST B-163
22		Binary	233	NIST B-233
23		Binary	271	NIST B-271
24		Binary	409	NIST B-409
25		Binary	571	NIST B-571
26		Binary	163	NIST K-163
27		Binary	233	NIST K-233
28		Binary	271	NIST K-271
29		Binary	409	NIST K-409
30		Binary	571	NIST K-571


[1] (EC)DSA has no indication what hash type is used.


-Ilari