Hi Stephen,
> On Mar 9, 2016, at 6:19 AM, Stephen Farrell <[email protected]> wrote: > > (1) 4.2: Why didn't you just mandate one way of calculating a > fingerprint as being mandatory to implement? (E.g. a sha256 hash of > the DER encoded SPKI?) I don't think that was intentional. Happy to add it as a requirement. Implementations of this privacy profile MUST support the calculation and representation of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded ASN.1 representation of the Subject Public Key Info (SPKI) of an X.509 certificate. Additional fingerprint types MAY also be supported. > and why is the "don't pin to a CA" rule in > appendix A not a MUST in the body of the document? The appendix essentially says "service-specific private CA: good. public CA: bad" I don't think we can make it a MUST because (a) how do you enforce that and (b) we don't expect the DNS client to differentiate between private/public CAs. > Wouldn't it be > better to do both of those? Sorry, I'm not sure what you mean by "do both of those"? > (Or to say why you're not doing them, > e.g. if current implementations do different things.) Given that > recursives publishing PINs will pick something, having that > something supported by all clients would seem like a fine thing. I agree that it might be better to move the sentence below from the appendix to the main body. Operators of a DNS-over-TLS service in this profile are expected to provide pins that are specific to the service being pinned (i.e., public keys belonging directly to the end-entity or to a service-specific private CA) and not to public key(s) of a generic public CA. > > (2) Section 5: Is it ok to (almost:-) recommend TLS false start like > that? Don't you need to at least point out that that has additional > requirements over and above RFC7525? I've not checked those in > detail though, as I'm waiting for the TLS WG to do their publication > request for false start. If you've done that checking, then you > might be just able to say "yeah, that's not a problem" but I'd like > to know since implementers here are likely to read this as saying > "Do RFC7525 and you're good." I don't know. I need to defer to TLS experts on this one. This may be a case where the risks (of getting it wrong) outweigh the benefits (of sometimes lower latency) so maybe it should be removed? DW _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
