As best I can recall, it was either Pittsburgh in 2000 or Minneapolis in 2001.
If you follow the reference chains, you find that draft-ietf-tls-oob-pubkey-04.txt ends up pointing to RFC 3279 anyway, so really it comes down to, do we use DNS formatting or x509 formatting? Since parsing and formatting code for both is pretty much ubiquitous and the packet space is dominated by the key itself, I see no real reason to change. That DNSKEY is supposed only to be used for DNSSEC is a distraction, we have our own RR and reusing the wire format is merely a convenience. Andrew On 20/10/2012, at 1:05 AM, Robert Moskowitz <[email protected]> wrote: > 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 _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
