I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-gennai-smime-cnipa-pec-05 Reviewer: Ben Campbell Review Date: 2009-11-03 IETF LC End Date: 2009-11-10 IESG Telechat date: (if known) Summary: This draft has significant open issues. I am not sure if it lands in the "open issues but on the right track", or "serious issues and needs to be rethought" category. The answer to that depends on the outcome of my "why is this standards track?" comments below. *** Note: I have concerns (below) about whether this should be a standards track or informational document. I have, however, continued the review it under the assumption that it will remain standards track. If it is decided that it should not be standards track, then many if not most of my "issue" comments will no longer apply. *** Major issues: -- Why is this standards track? If I understand it correctly, this is a restatement of a specification produced by the government of Italy, and standardized there by an act of law. It's not a standard produced by the IETF per se. It seems to me that this should at best be an informational, and might even belong in the independent submission stream. Furthermore, I assume that the Italian document on which this is based is the authoritative statement of this standard, and that the government of Italy has change authority, not the IETF. One wonders why we need to publish anything more than a reference to the base document(s). If we publish this as a PS, does that imply that the IETF thinks that the security properties are adequate for the purpose? -- Normative Requirements concerning Matters of Policy This draft has a number of normative requirements that I think are more matters of law and provider business policies than technical requirements. For example, providers MUST keep a log of all activities. This sort of thing might belong in a BCP, but seems not appropriate in an IETF standards track document. (It is reasonable to describe matters of law for motivational purposes, but that should not be in the form of normative requirements.) -- Virus Checking This spec has MUST level normative requirements for PEC elements to perform virus checking. It offers, however, no description, or references to descriptions, of how one does that. Nor does it offer any criteria of what sort of virus checking systems might meet the requirements of the overall system. But given the realities of the virus checking arms race, I don't think this is appropriate as a normative requirement in a proposed standard even if was adequately specified. (See previous comment about conflating technical standards and matters of policy). Minor issues: -- Copyright notice: What is the copyright status of the Italian document on which this is based? Does it have implications on the copyright status for this document? -- Section 2.1, paragraph 7: I am concerned about directing anyone to create a display name that does not describe the address itself. Also, the example loses the original display name completely. -- section 2.1.1.1: Why use "X-" headers in a proposed standard? Usually that denotes a proprietary or otherwise non-standard header field. -- section 2.2.1, Paragraph 3, "if a formal exception is detected, the access point refuses the message and emits the relevant non-acceptance PEC notification (see section 3.1.1);" It's not clear to me if you mean for the SMTP transaction itself to be rejected, or to succeed but result in a non-acceptance notification. I have the same question for several other areas where you talk about a PEC element refusing a message. -- same section, paragraph 7: "The identifier (from now on PEC msgid) of accepted original messages within the PEC infrastructure MUST be unambiguous in order to consent correct tracking of messages and relative PEC notifications." I _think_ you are saying the PEC msgid must be globally unique, right? If so, you need to say something more about how it's guaranteed to be unique. Also, what does "…consent correct tracking…" mean? -- same section, general discussion about Message-ID: "Therefore, both the original message and the corresponding PEC transport envelope MUST contain the following header field: Message-ID: <[unique identifier]> " I'm confused. Are you saying the PEC msgid _is_ the Message-ID: header field? If so, is the SMTP requirement for this field not sufficient? "When an email client that is interacting with the access point has already inserted a Message ID (from now on msgid) in the original message, that msgid SHALL be substituted by a PEC msgid." I'm more confused. Won't Message-ID _always_ be in the original message? Isn't it already guaranteed unique? Why do you need to change it? I am concerned about a system rewriting the original message-id of an email. If the access-point rewrote the original Message-ID with something else, how will the sender's client learn of it in order to correlate? -- section 2.2.2, "Signature Origin" bullet point: I'm a little surprised that one determines that a domain is a PEC provider by looking up the hash of its certificate in a directory. Couldn't this be more easily accomplished by some assertion in the certificate itself, signed by a designated CA? Could someone impersonate a provider if they could find a SHA1 collision for the provider? -- same section, bullet starting with " check what virus typologies..." I don't understand this paragraph--how can it know about viruses it didn't detect? -- section 2.2.4: Are the details of this storage specified somewhere? How is it accessed? -- section 3.1.2, first paragraph: I'm confused--this seems to say that a message that exceeds the size limit will get a non-acceptance notification, unless the message exceeds the size limit? Are there 2 limits here? -- section 3.1.4: Does the acceptance notification imply the message has been _successfully_ forwarded to the recipients? I.e. does the AP need to delay acceptance notification until it has successfully handed off the message to the downstream MTA for each recipient? What if some fail and some succeed? (I suspect the answer is no--in which case the text should say something like "…will be forwarded…" instead of "has been forwarded") -- section 3.1.5: What is the root MIME type for a PEC envelope? -- section 3.2.1, Paragraph 2: "The header of a take in charge PEC notification contains the following fields:" Is it _limited_ to those fields? -- same section, notification body: I assume the listed recipients are only those for which the receiving point has taken responsibility, right? That is, not necessarily the same as the original recipient list? If so, it would help to clarify this. -- section 3.3.2.2: I find this entire section confusing, as it seems to mix general processing requirements with requirements specific to S/MIME source documents. How does the sending user request brief delivery notifications? I see how the access point puts a the value in the PEC envelope, but that doesn't give the sender himself a way to request it, does it? Also, is there a normative requirement for the delivery point to honor "X-TipoRicevuta: breve"? Also, I'm concerned about any new protocol that uses SHA1 without offering an extensibility mechanism for integrating more modern hash algorithms. -- same section, 2nd paragraph: "The brief delivery PEC notification contains the original message and a ciphered hash value of each attachment." Please clarify what you mean by "original message". Were the attachments not part of the original message? -- same section, paragraph starting with " When the original message has an S/MIME format, it is necessary not to alter the integrity of the message structure." Should that be a normative statement that PEC elements MUST NOT... -- same section, last paragraph: Where, specifically, is the filename to which ".hash" is added? -- Section 3.3.2.3, first paragraph: Do you really mean to send this to the recipients, rather than the sender? Is that different than for the full and brief versions? -- section 3.4: "PEC messages MUST be processed even if both sender and receiver(s) belong to the same PEC domain." Even take-in-charge? -- section 4.2: Can you include an ABNF or other spec for date/time? Does this use a preexisting format that can be referenced? (and if not, why?) -- section 4.3.1: Please clarify--these restrictions are only for bodies of messages generated by PEC elements? I.e. these restrictions do not apply to the original message body? -- section 4.5, first paragraph: The process of downloading LDIF files into the master directory seem underspecified. How long does the provider need to host the LDIF file? Will the central directory try to download it more than once? How are errors handled? Are there privacy concerns for the LDIF files? Do I understand correctly that there's up to a 2 day delay before a PEC domain learns about changes in another domain's directory entry? -- same section, 2nd paragraph: What is a "secondary operating environment? How are they used? -- section 5.1: The use of hardware crypto acceleration is an implementation detail--why does it need to be in the spec? -- section 5.2, first paragraph I suspect the sense of this is reversed--did you mean to say the user MUST be authenticated before he can access PEC services? Or is the intend really to say a PEC provider cannot deny services to authenticated users? -- section 5.3, third paragraph: This seems to say that the incoming point MUST accept ordinary mail over unprotected channels. Did you really mean that as a _requirement_? -- same section, 4th paragraph: "To guarantee complete traceability in the flow of PEC messages, these MUST NOT transit on systems external to the PEC circuit." Can you elaborate on what procedures providers must follow to achieve this? -- section 5.5, general: Are there really no requirements concerning certificate authorities and certificate validation? It may be that the various PKCS and S/MIME docs specify this sufficiently--but it would be worth a mention to that effect. -- section 5.6: This implies a requirement for TLS mutual authentication, right? This should be mentioned explicitly. ALso, do you assume any relationship between TLS certs and S/MIME certs for a provider? Is the cert hash in the directory expected to also match the TLS cert? -- section 7: I think you need more meat here, since this is fundamentally a security protocol. What are the potential attacks on the system? How can they be mitigated? Are there known weaknesses? -- references: I didn't find a reference for the document(s) that this is based on--is it possible to add? -- IANA considerations: This draft specifies several new header fields. Do those not require IANA registration? Nits/editorial comments: -- General terminology: There are a lot of references to the "user", the "system", etc that are rather vague as to _which_ user or system. I think it would be helpful to globally change those to things like "sender", "recipient", "access point", etc. -- section 2.1, paragraph 6: "...systems MUST abide by the profile found in section 6.5." Is that section 6.5 of this document, or 6.5 of [SMIMEV3]? -- Section 2.1.1.1 s/"They"/"PEC notifications" -- section 2.1.1.1.1, first paragraph First sentence is a fragment. This pattern occurs quite a bit through the document. Keep in mind the section title is not part of the sentence, or even an antecedent for an upcoming pronoun--the body text should still stand alone. -- section 2.2.1, paragraph 6: s/typology/type. (same for other occurrences of "typology" elsewhere in the doc.) -- section 2.2.2, first paragraph: s/"This point"/"The incoming point" s/"inserted within"/"inserted into" -- section 2.2.5, first paragraph, first sentence: Sentence fragment. -- section 3.1.5, 2nd to last paragraph Can you provide an internal reference to "… what has been said regarding the Message ID"? -- section 3.1.6: The bullet list at end of section seems mostly redundant with opening paragraph. -- section 4.5, end of paragraph 1: Is "HAVE TO" intended as normative? That's not defined in RFC 2119. I suggest "MUST". -- section 5.1 is "It is suggested..." meant to be a normative "it is RECOMMENDED…"? -- section 5.5, first paragraph: s/done/sent _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf