I do like the dnssec-chain-extension.
I think the server should stick to one chain, from the root to itself, so it does not have to deal with variable chain blobs per client. That will allow server code to stick to something like hourly regenerating the blob for use with all clients. I do strongly prefer the binary blob to be in raw dns format. That will make parsing easier with existing code, and over time we will not run into issues where dns libraries support newer algorithms but this specific dnssec parsing code isn't updated. The DNS answer packet format can contain many DNS records in the Additional Section, without requiring any new DNS data format (and note edns-query-chain also does not specify a new format). I would be fine with stating the order of the additional records should be top down, to make validation easier, although probably the TLSA record and RRSIG itself should appear in the DNS Answer Section. As for ekr's question on why not stuff this inside X.509, that would not be compatible with tls raw pulic keys that only contain a SBKI, and drag back into the protocol more ASN.1 parsing and containers. Paul _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
