Having reviewed the document, I would suggest the following issues be addressed:
1. The introduction nicely restricts the problem to dealing with encryption and not signatures. I think it would be wise to have a brief paragraph about why the signature side is not dealt with. I think it would be as simple as saying that the document is not doing anything about changing the trust model, so the fact that one could obtain a signature key ring for a sender does not give any additional security on the trust of the signature. This might prevent a future update to the document that extended to deal with signatures. 2. The abstract should probably make a statement that the trust model is not changing for keys, and this is targeted towards doing optimistic encryption rather than secure encryption. 3. Minor point - if you lost the public key you probably lost the pre-signed key revocation. Not sure that it is worth updating the paragraph to reflect that this value can be lost as well. s/pre-sign a key revocation/pre-sign and retained a key revocation/ 4. In section 3, I strongly urge that the problem of case folding of user names be acknowledged. I don't insist that the problem be solved. (I believe that it is not really solvable.) However I strongly field that the existence of the problem needs to be stated along with the fact that there is no intention to solve it. The problem statement can also easily state that this is a problem ONLY for US ASCII systems and not for UNICODE systems as these are less likely to allow for case folding in the first place. (Does not need to be in section 3, but that seems to be the logical place to put it.) 5. Did I miss someplace a statement that this record type MUST be used only if DNSSEC is present? Or are you willing to use it w/o DNSSEC for opportunistic encryption? If so then that should probably be stated. Jim _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
