There has been a side converstation going on about the use of DNSKEY RR
format for RSA/DSA HOST_IDs per sec 5.2.9.
I am bringing the discussion to a larger audience so we can get a
'decide' and put this one to bed.
Historically speaking, this was a good quick choice made at a lobby
meeting way back when (Andrew, I believe you were part of the meeting,
do you remember what year it was? :) ). It had everything needed to
define the Host ID and had existing code not tied into 'certficate
stuff'. While we were developing HIP, we decided to ignore RFC 4043, as
we are NOT using DNSKEY RR to store HIP information, only how to format
it. We have our own RR.
Now it is choice time. Do we stay the course as currently shown in
5.2.9 or do we use:
RFC3279 as mentioned below
or do we follow with those that are following us with
draft-ietf-tls-oob-pubkey-04.txt
Do either of these provide all that we need for RSA/DSA Host ID
representation and are they more compact?
Note that for ECDSA (and ECDH in HIP DEX) we use a very simple format
that carries the (x,y) coordinate for the key (compact notation WOULD be
nicer for DEX, but there seems to be security concerns around it).
-------- Original Message -------- That started to discussion from Miika...
Hi René,
sorry for the belated response. I recall that we discussed about the use
of SRV records but I do not have a recollection of the DNSKEY issue you
mentioned.
On 09/23/2012 07:16 PM, René Hummen wrote:
Hi Miika,
I found one more issue that I did not yet report to the mailing list. As
I am not completely sure about the consequences of this issue and the
necessary changes, I would like some feedback from you first. Is it
still worth mentioning this at such a late state of the standardization
process?
Thanks for having a look at the following few line!
René
--------------------- TEXT FOR WG ----------------------
While going through draft-ietf-hip-rfc5201-bis-09, I stumbled across an
old issue that came up in a discussion with Stefan Götz at our
chair. The issue concerns the serialization format for HI public keys.
5.2.9
<http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-09#section-5.2.9>.
HOST_ID
"The Host Identity is derived from the DNSKEY format for RSA and DSA. For these, the Public Key
field of the RDATA part fromRFC 4034 <http://tools.ietf.org/html/rfc4034> [RFC4034
<http://tools.ietf.org/html/rfc4034>] is used."
This implies that public keys in HIP are stored in the "DNSKEY RDATA
Wire Format" as defined in RFC 4043 Section 2.1 [1].
However, RFC 4043 Section 2 states:
"The DNSKEY RR is not intended as a record for storing arbitrary public
keys and MUST NOT be used to store certificates or public keys that do
not directly relate to the DNS infrastructure."
While HIs can be stored in DNS, they do not have a direct relation to
the DNS infrastructure. Still there seems to be no harm in using this
serialization format in practice. The question is, do we want to move
to a different serialization format? A good candidate seems to be
ASN.1/DER encoding as detailed in RFC 3279 with a compact binary
representation for data in a cryptographic context.
BR,
René
[1] http://tools.ietf.org/html//rfc4034#section-2.1
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
