Hi, Stephen, As to the process issue, I see absolutely no rationale for not opening this to a -bis style editing cycle except the hope of clinging to a already issued RFC number. As I've pointed out to others, there are cases where standards-track docs have been promoted or demoted as-is because changing the doc would mean changing the protocol. That's not an issue here. As to the content: On 8/11/2015 2:17 PM, Stephen Farrell wrote: ... >> ---- >> >> - the fact that lazy programming is the cause of a large >> amount of security issues (buffer overrun) > > Off topic. This is not a document trying to cover all vulnerabilities > nor important ones, nor rank vulnerabilities. It's a statement on "cryptographic technology and the Internet". AFAICT, the biggest holes we have in that technology are in the sloppy implementation. >> - the concept that "crypto everywhere" is as vacuously useful >> as "crypto nowhere" > > I don't find that concept in the document at all, nor in any relevant > IETF document. You seem to be knocking down a non-existent strawman. I'm saying that the document, as a BCP, ought to discuss how crypto is used, and make the case that crypto should be used where needed. It is not a panacea. The subtext of the current document hints otherwise. >> - it makes no direct key size recommendation (as a BCP should) > > Off topic. This is not recommending use of specific algorithms (where > key size/strength becomes an issue) but the non-use of a class of > crypto that forces one to do key escrow of the kind described. This > is not a generic crypto primer nor HOWTO nor a BCP about how to use > crypto in IETF protocols. You seem to be criticising some document > which is not RFC1984 that you would prefer was the subject of an IETF > last call, but the detail of what is not here but in that non-existent > document is not useful in the context of this IETF last call I believe. > (Note I refer back to this point a number of times below when I say > "see above.") Point taken, but my counterpoint is that a document that speaks to governments and voters is "off topic" for the IETF. But let's concede that we've both made that point and omit the remainder that fall into that class... ... >> - it makes a claim about certification authorities being >> both legitimate and necessary, when they are the antithesis >> of some valid and useful crypto systems > > Legitimate is fine, necessary is ok in that context and both are > actually about the abstract concept of a PKI which I think is > still considered basically correct. While we might use the work > "necessary" there were we to write this today, that I think is > ok. certification authorities are legitimate and necessary *for PKI*. There are other systems, though (I would not consider PGP based on "PKI"). >> - it fails to address the slipshod way in which public keys >> are often signed by others, e.g., using a "government issued ID" >> as proof (who of us would know an invalid ID if we saw one?) > > That is not a quote from 1984. You seem to be criticising text that > is not there? Or are you postulating some other BCP about PKIs? I'm claiming the document is flawed in not addressing this issue. If you think it's OK to claim that certificate authorities are necessary, then why is it OK for PGP to use haphazard keysigning parties? >> (i.e., "key signing parties are a hazard to public key crypto" >> IMO) > > Same problem as above - the quoted text above is not a quote from > 1984. Same thing - flawed by omission. I consider this issue to be distinct from the more technical, specific ones you claim are "off topic". >> The list goes on. > > The problem with your list is that it is not dealing with this last > call of the status change of RFC1984 I think. It really looks to me > like you're saying that there is some other document that you would > prefer be written. That's a fine wish, but I don't think the details > of what you think ought be in that document are very useful in terms > of helping the IESG evaluate this last call. A document that clearly indicates the technical reasons why certain policies are ineffectual or inappropriate is fine. This document might be a step in that direction, but it has problems that ought to be fixed. A document that pontificates on those reasons has no purpose in the IETF. I recognize that there are many others on this list who prefer to waste their time endorsing such proclamations, but I will not. Joe