[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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)