[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AS#1 comments
Hi Graham. I have talked to the other editor about your comments. The paper
has been done, being held up for s/mime v3.0 for almost a year. 6 companies
have implemented it.. They were able to read/understand it ok. Unless you
have major heartburn, I would just like to publish it the way it is....
please let me know... rik
> -----Original Message-----
> From: owner-ietf-ediint@xxxxxxx [mailto:owner-ietf-ediint@xxxxxxx]On
> Behalf Of Graham Klyne
> Sent: Wednesday, October 14, 1998 3:28 AM
> To: ietf-ediint@xxxxxxx
> Subject: AS#1 comments
>
>
> I've only just looked at this draft for the first time, so my comments may
> come late in the day.
>
> My general feeling is that this is not ready for last call, even if only
> for reasons of presentation: there is a lot of repetition and material
> which duplicates detail from other standards, etc. Also, I think
> there are
> several instances of ambiguous or over-wordy phrasing that combine to make
> the document quite difficult to read.
>
> #g
>
> [...]
> >1. Introduction
> >
> [...]
> > With an enhancement in the area of "receipts", as described below
> > (3.1.8), secure Internet MIME based EDI can be accomplished by
> ......[-----]
> The section reference here is wrong. I assume that it should be somewhere
> in section 5: is there a particular sub-section you mean to indicate?
>
> > using and complying with the following RFCs:
> >
> > -RFC 821 SMTP
> > -RFC 822 Text Message Formats
> > -RFC 1767 EDI Content Type
> > -RFC 1847 Security Multiparts for MIME
> > -RFC 1892 Multipart/Report
> > -RFC 2015 MIME/PGP
> > -RFC 2045 to 2049 MIME RFCs
> > -RFC 2298 Message Disposition Notification
> > -RFC 2311 S/MIME Specification
>
> I notice there is no reference here or later to S/MIME V3 work.
> Is it your
> intention to exclude that from your allowable profile? Similarly,
> Open/PGP. I understand both are close to last-call.
>
> [...]
> > 2.2.2 The secure transmission loop
> >
> > The functional requirements document, [9] "Requirements for Inter-
> > operable Internet EDI" (can be found at www.ietf.org), provides
> > extensive information on EDI security and the user/business related
> > processes surrounding the need for and use of EDI security. In
> > this document, it is assumed that the reader is familiar with the
> > requirements document.
>
> That document appears to be an expired Internet draft, and as far as I can
> tell is not included in the last call which covers this document. Also, I
> note that there seems to be a large amount of duplicated text between this
> document and that, which is both unecessary and not reader-friendly if you
> intend the audience to read both.
>
> > This document's focus is on the formats and protocols for
> > exchanging EDI content that has had security applied to it using
> > the Internet's messaging transport.
>
> I had to read this several times before it made any sense to me. I think
> you may mean something like:
>
> # This document focusses on formats and exchange protocols for
> # EDI content with security applied, which may be transferred
> # using the Internet's messaging transport.
>
> > -The receiving organization then sends a signed receipt in the
> > form of a signature over the hash of a message disposition
> ........[---------------------------------------------------------
> > notification, which contains a hash of the received message.
> ........------------]
>
> My reading of the later sections was that the signed receipt was "in the
> form of a signed message disposition notification" (the 'signature over
> hash' being implicit in the formulation of the signature, per the security
> mechanism applied).
>
> > The above describes functionality which if implemented, would
> > satisfy all security requirements. This specification, however,
> > leaves full flexibility for users to decide the degree to which
> > they want to deploy those security features with their EDI
> > trading partners.
>
> I did not spot any reference to how the set of security features
> to be used
> would be decided. I assume it would be some out-of-band mechanism.
>
> > 2.2.3 Definition of receipts
> >
> > The term used for both the functional activity and message for
> > acknowledging receipt of an EDI/EC interchange is receipt, or
> > signed receipt. The first term is used if the acknowledgment is
> > for an interchange resulting in a receipt which is NOT signed.
> > The second term is used if the acknowledgment is for an interchange
> > resulting in a receipt which IS signed.
>
> The above seems very awkwardly phrased (i.e. difficult to read). Why not
> just define "receipt" and then define "signed receipt"
>
> > [...] The "rule" is: If a
> > receipt is requested, explicitly specifying that the receipt be
>
> > signed, then the receipt MUST be returned with a signature.
>
>
> This appears to require that a message disposition notification
> be returned.
>
> We have had some similar discussions in the Fax WG, and have been told in
> no uncertain terms by the AD and particpating IAB member that an IETF
> standard will not be permitted to mandate a response to an MDN request.
>
> (Keith, are you here?)
>
> Or do you mean "if a receipt is returned, it MUST be signed"?
>
> > If a receipt is requested, explicitly specifying that the receipt
>
> > be signed, but the recipient cannot support the requested protocol
>
> > format or requested MIC algorithms, then a receipt, either signed
> > or unsigned SHOULD be returned.
>
> This sentence seems at odds with the previous one. To say that something
> MUST happen under some circumstance, then to go on and say that if the
> software cannot do that then it merely SHOULD happen seems to be, er,
> perverse.
>
> > [...] If a signature is not explicitly
> > requested, or if the signed receipt request parameter is not
> > recognized by the UA, all bets are off -- a receipt may or may not
> > be returned. This behavior is consistent with the MDN RFC 2298.
>
> Which behaviour? The final sentence or the whole paragraph?
>
> > A term often used in combination with receipts is "Non-repudiation
> > of Receipt (NRR). NRR refers to a legal event which occurs only
> > when the original sender of an interchange has verified the sender
> > and content of a signed receipt. Note that NRR is not possible
> > without signatures.
>
> This is, IMO, unnecessary repetition. I feel there is a lot of
> unnecessary
> repetition in this document
>
> >3. Referenced RFCs and their contribution
>
> [...]
> > 3.4 RFC 1892 Multipart/report [10]
> >
> > This RFC defines the use of the multipart/report content type,
> > something that the MDN RFC 2298 builds upon.
>
> I would say that RFC 1892 defines the *format* rather than *use* of
> multipart/report.
>
> > 3.6 RFC 2015 PGP/MIME [4]
> >
> > This RFC defines the use of content types
> > "multipart/encrypted", "multipart/signed", "application/pgp
> > encrypted" and "application/pgp-signature" for defining MIME PGP
> > content.
>
> "... for defining MIME PGP content"?
>
> [...]
> > 3.8 RFC 2298 Message Disposition Notification [5]
> >
> > This Internet RFC defines how a message disposition notification
> > (MDN) is requested, and the format and syntax of the MDN. The MDN
> > is the basis upon which receipts and signed receipts are defined
> > in this and the "Requirements" specification.
>
> Hang on, exactly *where* are signed receipts defined? In this document or
> in the requirements document? It's not really useful to have them defined
> in two places.
>
> [...]
> >4. Structure of an EDI MIME message - Applicability
> >
> > 4.1 Introduction
> >
> > The structures below are described hierarchically in terms of which
> > RFC's are applied to form the specific structure. For details of
> > how to code in compliance with all RFC's involved, turn directly to
> > the RFC's referenced. The "requirements document" has several
> > examples described in an Appendix for those interested.
> >
> > Also, these structures describe the initial transmission only.
> > Receipts, and requests for receipts are handled in section 5.
> >
> >
> > 4.2 Structure of an EDI MIME message - PGP/MIME
> >
> > 4.2.1 No encryption, no signature
> >
> > -RFC822/2045
> > -RFC1767 (application/EDIxxxx)
> >
> >
> > 4.2.2 No encryption, signature
> >
> > -RFC822/2045
> > -RFC1847 (multipart/signed)
> > -RFC1767 (application/EDIxxxx)
> > -RFC2015 (application/pgp-signature)
>
> I think that should be:
>
> # -RFC822/2045
> # -RFC2046
> # -RFC1847 (multipart/signed)
> # -RFC1767 (application/EDIxxxx)
> # -RFC2015 (application/pgp-signature)
>
> or
>
> # -RFC822/2045/RFC2046
> etc.
>
>
> [...]
> >5. Receipts
> >
> >5.1 Introduction
> >
> [...]
> >The following support for signed receipts is REQUIRED:
> >
> > 1). The ability to create a multipart/report; where the report-type
> > = disposition-notification.
> > 2). The ability to calculate a message integrity check (MIC) on the
> > message disposition notification.
> > 3). The ability to digitally sign the MIC.
> > 4). The ability to create a multipart/signed content with the message
> > disposition notification as the first body part, and the signed
> > MIC calculated on the message disposition notification as the
> > second body part.
> > 5). The ability to return the signed receipt to the sending
> trading partner.
>
> I would say that (2)-(4) are fully covered by the process of creating a
> signed receipt message in a multipart/signed structure. I think there are
> many comments here and later in this section that needlessly duplicate
> material that is in your requirements document and in the
> relevant security
> documents.
>
> [...]
> >5.2 Requesting a signed receipt
> >
> >Message Disposition Notifications are requested as per RFC 2298,
> >"An Extensible Message Format for Message Disposition
> >Notification". A request that the receiving user agent issue a
> >message disposition notification is made by placing the following header
> >into the message to be sent:
> >
> > MDN-request-header = "Disposition-notification-to" ":" mail-address
> >
> >The mail-address field is specified as an RFC 822 user@domain address,
> >and is the return address for the message disposition notification.
>
> Why repeat all this detail from RFC2298?
>
> I think the following paragraphs are one of the more important parts of
> this document, and could do with clearer, more precise presentation...
>
> >In addition to requesting a message disposition notification, a message
> >disposition notification that is digitally signed, or what has been
> >referred to as a signed receipt, can be requested by placing the
> >following in the message header following the "Disposition-
> >notification-to" line.
>
> Do you really mean for "Disposition-notification-options" to immediately
> follow "Disposition-notification-to"? This would be contrary to RFC822
> (see note at start of section 4.1 that says header fields are not required
> to occur in any particular order). I would suggest something like the
> following:
>
> # Further, a signed receipt (a digitally-signed disposition notification)
> # can be requested by including "Disposition-notification-options" field
> # (per RFC2298) in the message header containing a
> "signed-receipt-protocol"
> # parameter value.
>
> At this point, I would suggest simply listing a complete formal syntax
> definition for the new parameter values rather than repeating information
> from RFC2298. What follows seems to be an uncomfortable mix of prose and
> formal syntax specification.
>
> > Disposition-notification-options =
> "Disposition-notification-options" ":"
> > disposition-notification-parameters
> >
> >where
> >
> > disposition-notification-parameters = parameter *(";" parameter)
> >
> >where
> >
> > parameter = attribute "=" importance ", " 1#value "
> >
> >where
> >
> > importance = "required" | "optional "
>
> At this point, the document seems to jump, without warning from a
> description of the syntax to examples of its use. If you are going to
> place examples here, I sugegst complete ones with the
> Message-disposition-to *and* the Disposition-notification-options fields.
>
> >So the the Disposition-notification-options string could be either
> >
> > optional, signed-receipt-protocol, <protocol symbol>;
> >
> > optional, signed-receipt-micalg, <micalg1>, <micalg2>,...;
>
> These are quite long names for the 'value' keywords: in this context,
> where they appear as part of a longer header field, I'd suggest trying to
> shorten them to (say) "signing-protocol" and "signing-micalg"?
>
> More importantly, I'd suggest aligning the corresponding values with those
> defined for multpart/signed parameters in RFC1847. You have already done
> this for 'micalg'; to do the same for 'protocol' (i.e. use the MIME type
> corresponding to the signature) would, I think, result in a more generic
> and more easily extended protocol.
>
> >The currently supported values for <protocol symbol> are "pkcs7-
> >signature", for the S/MIME detached signature format, or "pgp-signature",
> >for the pgp signature format.
> >
> >The signed-receipt-micalg is a list of MIC algorithm values defined in
> >RFC1847, an IANA registered MIC algorithm ID token.
>
> Do you mean "... list of MIC algorithm values from those defined in
> RFC1847, ..."?
>
> [...]
> >The semantics of the "signed-receipt-protocol" parameter is as follows:
> >
> >1). The "signed-receipt-protocol" parameter is used to request a signed
> > receipt from the recipient trading partner. The "signed-receipt-
> > protocol" parameter also specifies the format in which the signed
> > receipt should be returned to the requester.
>
> > The "signed-receipt-micalg" parameter is a list of MIC algorithms
> > preferred by the requester for use in signing the returned receipt.
> > The list of MIC algorithms should be honored by the recipient from
> > left to right.
>
> "honored by the recipient from left to right" doesn't make a lot of sense
> to me.
>
> >2). The "importance" attribute of "Optional" is defined in the MDN RFC
> 2298 and
> > has the following meaning:
>
> Again, why repeat so much detail from RFC2298?
>
> [...]
> >5.2.1 Additional Signed Receipt Considerations
>
> >
> > The "rules" stated in Section 2.2.3 for signed receipts are as
> > follows:
> >
> > 1). When a receipt is requested, explicitly specifying that
> the
> > receipt be signed, then the receipt MUST be returned with a
> > signature.
>
> See comments above about mandatory MDNs.
>
> > 2). When a receipt is requested, explicitly specifying that the
> > receipt be signed, but the recipient cannot support either
> > the requested protocol format, or requested MIC algorithms,
> > then either a signed or unsigned receipt SHOULD be returned.
>
>
> Again, see comments above about MUST and SHOULD with the same
> precondition.
> Also, why is this detail stated twice (here and previously in
> this document)?
>
> [...]
> > When a request for a signed receipt is made, but there is an
> error in
> > processing the contents of the message, a signed receipt MUST still
> > be returned. The request for a signed receipt SHALL still be honored,
> > though the transaction itself may not be valid. The reason
> for why the
> > contents could not be processed MUST be set in the
> "disposition-field".
>
> This looks like another case of mandatory MDN response.
>
> > When a request for a signed receipt is made, the
> "Received-content-MIC"
> > MUST always be returned to the requester. The "Received-content-MIC"
> > MUST be calculated as follows:
>
> Where is this "Received-content-MIC" defined? You describe how it is
> calculated but it is not clear where it is to be returned, and in
> what format.
>
> [Later: I see now. I think a forward reference to section 5.3.1
> should be
> placed here.]
>
> > When a request for a signed receipt is made, the
> "Received-content-MIC"
> > MUST always be returned to the requester. The "Received-content-MIC"
> > MUST be calculated as follows:
> >
> > - For any signed messages, the MIC to be returned is calculated
> > on the RFC1767 MIME header and content, or the multipart MIME
> > header and content. Canonicalization as specified in RFC 1848 MUST
> > be performed before the MIC is calculated, since the sender
> > requesting the signed receipt was also REQUIRED to canonicalize.
>
> I would have thought that for any signed message, the MIC should simply be
> calculated as defined by RFC1847, using the indicated MIC algorithm. I
> suspect that reference to RFC1848 canonicalization here could prove
> problematic, as different security protocols used (PGP or S/MIME) may have
> their own canonicalization rules.
>
> [...]
>
> >5.3 Message Disposition Notification Format
> >
> >The format of a message disposition notification is specified in
> >RFC 2298 For use in Internet EDI, the following format will be used:
> >
> > - content-type - per RFC 1892 and the RFC 2298 specification
> >
> > - reporting-ua-field - per RFC 2298 specification
> >
> > - MDN-gateway-field - per RFC 2298 specification
> >
> > - original-recipient-field - per RFC 2298 specification
> >
> > - final-recipient-field - per RFC 2298 specification
> >
> > - original-message-id-field - per RFC 2298 specification
> >
> > - disposition-field - the following "disposition-mode"
> > values SHOULD be used for
> > Internet EDI:
> >
> > "automatic-action" - The disposition described by the disposi-
> > tion type was a result of an
> automatic
> > action, rather than an explicit instruc-
> > tion by the user for this message.
> >
> > "manual-action" - The disposition described by the disposi-
> > tion type was a result of an explicit
> > instruction by the user rather than some
> > sort of automatically performed action.
> >
> > "MDN-sent-automatically" - The MDN was sent because the UA
> had
> > previously been configured to do so.
> >
> > "MDN-sent-manually" - The user explicitly gave permission for
> > this particular MDN to be sent. "MDN-
> > sent-manually" is meaningful with
> > "manual-action", but not with "automatic-
> > action".
> >
> > - disposition-field - the following "disposition-type" values SHOULD
> > be used for Internet EDI:
> >
> > "processed" - The message has been processed in some manner
>
> > (e.g., printed, faxed, forwarded, gatewayed)
> > without being displayed to the user. The user may
> > or may not see the message later.
> >
> > "failed" - A failure occurred that prevented the proper
> gener-
> > ation of an MDN. More information about the
> cause of
> > the failure may be contained in a Failure
> field. The
> > "failed" disposition type is not to be used
> for the
> > situation in which there is some problem in
> > processing the message other than
> interpreting the
> > request for an MDN. The "processed" or other
> dis-
> > position type with appropriate disposition
> modifiers
> > is to be used in such situations.
> >
> > - disposition-field - the following "disposition-modifier" values
> > SHOULD be used for Internet EDI:
> >
> > "error" - An error of some sort occurred
> > that prevented successful
> > processing of the message.
> > Further information is contained
> > in an Error field.
> >
> > "warning" - The message was successfully
> > processed but some sort of
> > exceptional condition occurred.
> > Further information is contained
> > in a Warning field.
>
> Again, there seems to be a lot of duplication of detail from other
> standards. I think this section would work better if it focussed on
> details specifically relevant to EDI.
>
> > 6.2 Long term approach
> >
> > In the long term, additional Internet-EDI standards may be
> > developed to simplify the process of establishing a trading
> > partnership, including the third party authentication of trading
> > partners, as well as attributes of the trading relationship.
>
> I think a reference to the PKIX work might be relevant here.
> That seems to
> provide reasonably near-term standards for dealing with X.509 certificates
> on the Internet.
>
> [...]
>
> --end--
>
>
> ------------
> Graham Klyne
> (GK@xxxxxxx)
>
>