X-RT-Interface: Web Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary References: X-RT-Original-Encoding: utf-8 X-Mailer: MIME-tools 5.508 (Entity 5.508) MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: RT-Send-CC: Content-Length: 957 Dear Massimiliano, thank you for the heads up, I would recommend simply submitting your proposal as I-D and send the announcement message to DNSOP and TLS WG @ IETF. That way this will get much more attention than from just us. Or I would rather recommend going to CAB Forum first - because it would be useless to spend time working on a standard nobody would implement. From myself, I would add just initial thoughts on the DNS side: a) I would strongly recommend making this DNSSEC only and tackling the error modes when DNSSEC Validation fails (e.g. similar to situation when OCSP retrieval via HTTP(S) fails). Without DNSSEC, you are prone to OCSPRR striping, with DNSSEC, you are tackling the same problem as DANE (TLSA RR) has - the resistance to implement DNSSEC-validating resolver in the browser. b) drop the TXT fallback, getting a new RR is simple (compared to getting this to be approved as a model of operation in PKIX WG Good luck, Ondrej