[dane] AD review of draft-ietf-dane-openpgpkey-03

[Stephen Farrell <[e-mail]>]

Hiya,

I've done my AD review of this one too. In this case I do
have a few questions I'd like to chat about before starting
IETF LC, four of 'em actually;-) But they should be quickly
dealt with.

And of course I've a bunch of nitty comments too, below,
but those can just be handled as last call comments.

Cheers,
S.

Stuff I'd like to chat about before starting IETF LC:

(1) Given the email-addr-in-DNS issues with this, would
this not be better as experimental? I think the WG did
consider that, but I forget, and in any case even if you
did, I want to ask again, to be sure to be sure:-) My
concern is that we not end up arguing against other
folks who may want to standardise some form(s) of key
server on the basis that this is *the* standard way to
do it. One way to handle that would be for this to be
experimental and for us to see if it gets deployed or
not. Another could be to just say in the text that this
proposed standard is one way of distributing keys, but
that others can be equally valid.

(2) The intro is very wordy. It could really lose the
editorialising generally. (Various examples below.)
Is that fair comment? Are the opinionated bits really
needed in the RFC?

(3) Can you briefly convince me that sections 2.1 and
2.2 are sufficient to write interoperable code.  Section
5.5.1.1 of 4880 does not seem to be the right place at
which to point for that, to me. But I've not implemented
PGP so I may be wrong.

(4) 6.2 still refers to sha-224, which is wrong now
isn't it?


---- detailed comments/nits/etc.

- intro: HKP needs a reference

- intro: "Worse, ..." the value judgement isn't needed.
Say (exactly) why it's worse or say nothing. And the
IETF does not have consensus that TOFU is "worse" unless
you say what it is "worse" than.

- intro: "have no method" - how do you know? It could be
they make no claims of validating things but that they
do internal stuff, who knows.

- intro: lack of secure lookup does not "prevent"
encryption, that's just wrong. I send encrypted mail all
the time without that.

- intro: "forcing...unencrypted" is also wrong given
S/MIME - while this is about PGP, please don't deny
reality.

- intro: "This document describes..." - you could delete
almost all the text before this para. And some after
it;-)

- intro: "Trust Signature model" needs a reference

- intro: "otherwise have to be" is false (same as above)

- Appendix A: This would be much better work a worked
example, incl. a public key one could import to
re-generate the outputs required.

- section 3: do you really need 28 octets? wouldn't
fewer be good enough and not risk collisions? Just
wondering.

- 4.2 - that MUST fail if local/DNS differ is a shame.
Did the WG consider adding a label or key version to the
RR that might allow for some update cases to work?

- section 5: is "recommended" there meant as a 2119
thing? If so, it's usually better in uppercase.

- 6.2 - in theory using the mail author's email address
might not mean publishing that I guess. But your text is
fine as-is, just noting that possibility.

- 6.3 - what if an application has no user? Does this
section apply then?