> On Mar 10, 2016, at 12:41 AM, Stephen Farrell <[email protected]> > wrote: > > > Hiya, > > On 09/03/16 22:24, Wessels, Duane wrote: >> 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. > > That's great thanks. You maybe want to mention the base64 encoding > too if you want that to end up exactly as per Appendix A.
Okay, it says this now: Implementations of this privacy profile MUST support the calculation 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. Implementations MUST support the representation of a SHA-256 fingerprint as a base 64 encoded character string [RFC4648]. Additional fingerprint types MAY also be supported. >> >>> (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. >> > > Fair enough. That sentence has now been moved to the opening paragraph of 4.2. > >> >> >>> >>> (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? > > Some people will prefer the latency gain though as we know. > > I think in this case all you need to do is highlight that false > start has requirements over and above 7525, e.g. by saying: > > "Implementations supporting TLS false start need to be aware > that imposes additional constraints on how one uses TLS, > over and above those stated in BCP195. It is unsafe to use > false start if your implementation and deployment doesn't > adhere to these specific requirements. See [false-start] > for details of those additional constraints." I've added this with just minor edits, thanks. > PS: If the above changes are acceptable then my DISCUSS will > be sorted. > The link below will take you to an rfcdiff of all the changes since starting IESG evaluation http://goo.gl/Wwsr7M DW _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
