[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AS#1 draft-ietf-ediint-as1-01.txt comments
Here are some comments on the new draft:
[I disagree with the calculation of signatures (MIC) in a receipt. I think
this improper, and is an inappropriate nesting/combination of MIME
wrappers. The MIC calculation should be at the same level as the
receipt-- not nested within MIME wrappers. The receipt process fails or
changes when corresponding MIME contents are not present. Thus is a MUST
CHANGE in my opinion. See below.]
[There are some major errors with the S/MIME examples (doesn't conform
to the S/MIME spec).]
[If you get bored with the details below, skip to the end for some
additional items I think would be good to add to the document.]
It would be better to structure the document so the encryption and
signature algorithms can be readily be extended. Initially, only
S/MIME and PGP can be mentioned as supported, but the extensibility
mechanism can be defined.
There are two mechanisms supported:
a) A Content-Type: header with the top level RFC822 headers indicates a
MIME identified encryption and signature format. The encrypting
format specification determines encoding and decoding of a data
message containing MIME headers and body, as illustrated by the &
lines in 3.4.1 S/MIME.
b) The MOSS multipart format is used. The Content-Type in the first
part of a multipart/encrypted identifies the algorithm. The second
part of a multipart/signed message identifies the signature algorithm.
Encrypted and signed messages are nested as shown in 3.6.2 PGP/MIME.
(There is a third, which uses separate MIME wrappers for encryption and
signatures distinct from a combined sign/encrypt format. Some algorithms
combine encryption and signature, where others may use encryption of a
MIME message containing signed data, e.g. as is done for PGP/MIME here.)
By defining this extensible mechanism with this RFC, designers of software
can architect the systems to permit easy addition of future algorithms,
e.g. just like the MIME viewers in WWW browsers permit extensible types.
I agree that it is useful to state that a conformant application to the
RFC support either S/MIME or PGP, and no other formats need be mentioned.
(The DMS/MSP MIME type would be a logical extension useful for DOD
internal EDI. Many DOD employees only have Fortezza cards, and can't
decode or sign PGP or certain S/MIME formats with mandated hardware
security. Gateways might be required with a proxy encryption/signature to
support these people.)
---
2.3.2 Flexibility assumptions
-Use of receipt or not (signature required for "Signed Receipt")
I suggest adding:
A signed receipt may be returned for messages containing EDI data even
though the original message does not include a receipt request.
[Some mailers munge the message headers, and might lose a receipt
request. Thus a receipt would always be returned for TP-TP messages
other than a receipt message. A receipt would not normally be used for
1-many message broadcasts, e.g. an RFQ.]
---
3.1.9 RSA Specifications - S/MIME (RSA Security, Inc.) [8]
include the internet-drafts/draft-dusse-mime-msg-spec-00.txt
reference(?)
---
3.2 Vocabulary
<EDI Object> ANSI X12 or EDIFACT EDI Interchange, or
mutually agreed electronic commerce file
I suggest defining:
<encoded EDI Object> The <EDI Object> encoded in Quoted-printable
or Base64 Content-Transfer-Encoding.
then using <encoded EDI Object> where applicable.
---
The blank line preceeding a terminating --separator is wrong, and should
be removed. The --separator directly follows the last line of the
data it terminates. This is wrong in several places.
---
3.4.2 PGP/MIME
&Content-Transfer-Encoding: <encoding>
&
&<EDI object>
The Content-Transfer-Encoding should not be required for ASCII EDI objects,
and in fact, Quoted-printable is undesirable.
---
-The text preceeded by "&" indicates that it is really encrypted,
but presented as text for clarity
I suggest changing the note to:
-The text preceeded by "&" indicates that it is really encrypted and
encoded according to the Content-Transfer-Encoding, but presented as
text for clarity
---
I suggest adding another indicator character besides * and & to denote
the body as per PKCS7. Specifically, the "ContentType" is the first
part of the PKCS data, part of MIME.
---
3.5.1 S/MIME
This is incorrect S/MIME:
PKCS #7 has a provision for "detached data", where, for example, the
SignedData in the ContentInfo contains only the signature information,
but not the actual data which is signed (which is transferred
separately). Application/x-pkcs7-mime explicitly disallows the use of
detached data and requires the data to be present within the
ContentInfo. The "detached data" provision is, however, used by the
multipart/signed construct described in Section 6.
You are incorrectly mixing the two ways of transmitting signed data. The
first way, using Application/x-pkcs7-mime with ContentType = SignedData
should be explicitly prohibited for use in EDI case 3.5.1 (as well as
everything else in my opinion), since the MIME-EDI contents are binary
encoded and cannot be read by non S/MIME systems. The RFC1847
multipart/signed should be the only method allowed.
The correct syntax is to remove the outer layer application/x-pkcs7-mime
wrapper from 3.5.1 S/MIME, so the RFC822 headers contain the
Content-Type: multipart/signed header. (The Version header is wrong too.)
You should be consistent, and show the ContentType= header in <encoded
signature>.
---
3.6.1 S/MIME
ContentType = SignedAndEnvelopedData
*MIME-Version: 1.0
*Content-Type: multipart/encrypted; boundary="separator";
*protocol="application/x-pkcs7-mime"
*
*--separator
I believe this is incorrect, as per S/MIME. SignedAndEnvelopedData contains
the &&& marked data directly, wrapped in the ASN.1 binary data. It does
not contain MIME pkcs headers as indicated in the example. If you plan
on using the scheme illustrated (which is contrary to PKCS7), the
ContentType would be ContentType = EnvelopedData, same as 3.4.1 S/MIME.
(This is according to the current internic draft, September, 1996.)
---
4. Receipts
Should the signature format (PGP or S/MIME) of the receipt be required to
be the same as the original message, except by prior agreement?
---
4.1 Introduction
3). The sender's public key is then used to decrypt the received
message integrity check (MIC or Message Digest) calculated by
the sender using a one-way hash function, and digitally signed
by the sender. The decryption of the MIC authenticates the
sender of the EDI Interchange to the receiving trading partner.
....
The wording of these paragraphs is obtuse, and may be confusing to
many readers. I suggest rewording 3-5, e.g.
3). The receiving trading partner authenticates signatures in a
message using the sender's public key. The authentication
algorithm performs the following:
a) The message integrity check (MIC or Message Digest)
contained within the signature is decrypted using the
sender's public key for signatures.
b) A MIC on the signed contents (the MIME header and encoded
EDI object, as per RFC1767) in the message received is
calculated using the same one-way hash function that the
sending trading partner used.
c) The MIC extracted from the signature is compared with the
MIC calculated from the message received.
---
I disagree with the following:
6). The receiving trading partner then digitally signs the MIC that
was calculated on the received EDI Interchange and the RFC 1767
MIME content header information.
This is innappropriate nesting of MIME. The receipt is for a message,
and the MIC should be the _message_ contents, not some decoded portion
of the message, dependent on MIME headers. The signed MDNs should apply
to *any* RFC822 message containing a "Disposition-notification-to"
header, not just this MIME-EDI protocol.
The proper MIC is the MIME content, i.e. the first nonblank line following
the message headers, up to the last line, or the --boundary-- terminator.
Note that the secure mailer UA should compute and log the message MIC,
and can then check and log MICs in receipts.
The rfc1864 Content-MD5 header could be useful, except that this RFC
explicitly doesn't define the semantics for multipart messages. (Groan! :-/)
Besides proper layering of MIME, the Content MIC provides some additional
benefits. The receipt includes verification of the signature (and it's
timestamp) included with the message. Also, the Content MIC replaces the
message/rfc822 body part, so the receipt can include just the message
headers (which aren't included in the MIC), altered as received by the
recipient's MTA.
---
- disposition-field - for EDI use:
* autoprocessed - when the received content(s) are
successfully processed
I suggest adding:
* autoprocessed_failed - when the received content(s) have been
processed but an error occurred
also:
* autoprocessed_warning - when the received content(s) have been
processed successfully, but problems were detected which
may require attention
In the case of errors or warnings, the first part of the report should
contain an explaination.
---
4.3 Message Disposition Notification Format
- extension field - the following extension field will be added in
order to support signed-receipts for RFC 1767 specified content
types and multi-part specified content types which includes RFC
1767 content types. The extension field is sent only when the
received contents are successfully processed.
- extension field = "X-" "Received-MIC" ":" MIC
This should be changed to indicate that the Received-MIC is computed
over the contents of the Received _message_. Also, the MIC algorithm
should be specified along with the MIC value. Alternatively, the
algorithm could be fixed as MD5, and a Content-MD5 header supplied.
A better name might be
"Content-MIC" ":" <micalgid> "," MIC
This header could be inserted into the originating message, which would
allow MTAs and UAs, etc. to validate the message integrity.
---
4.4.1 Large File Processing
It is also recommended that very large EDI files not be sent via
SMTP and a file transfer protocol be used instead.
This paragraph should be deleted. There is no file transfer protocol
defined for EDI. *IF* you want to support such an alternative, then use
an RFC2017 external URL.
There is no reason why SMTP is necessarily any more limiting on large
files than FTP. Also, "large" is not defined. Some PC mailers split
messages larger than 32KB (MFC text object limit), whereas I regularly
get 1MB files via UUCP on my 9600b modem.
See comments below for Content-Encoding, for a better approach to large
files. Many large files can be compressed into a resonable size. EDI
messages should typically have a very high compression ratio.
---
As specified by RFC 1892. Returning the original message is not
necessary. This is an optional body part.
A typical case would be to include the message headers but not the
contents in a receipt. The MIC in the message/disposition covers the
contents, but headers contain additional information not in the original
message which may be useful for debugging
---
4.4.2 Example
..., the example is wrong.
This is correct, the example is wrong. :-)
The receipt should be signed, as indicated by the Subject. In other words,
the "To: Edi Sender <Edi_Sender@othercorp.com>" headers should contain a
"Content-Type: multipart/signed", where the "Content-Type: multipart/report"
follows the initial --signed separator.
---
5. Public key certificate handling
5.1 Near term approach
I suggest rewording the paragraph, and eliminate the reference, which
doesn't really say much, except for X.509 which is not directly applicable to
PGP. How about,
In the near term, the exchange of public keys and certification of
these keys must be handled as part of the process of establishing a
trading partnership. The UA and/or EDI application interface must
maintain a database of public keys used for encryption or signatures,
in addition to the a mapping betweeen EDI trading partner ID and
RFC822 email address. The procedures for establishing a trading
partnership and configuring the secure EDI messaging system might vary
among trading partners and software packages.
For systems which make use of X.509 certificates, it is recommended
that the trading partners self-certify each other if an agreed upon
certification authority is not used.
In designing the key management and interface with EDI applications,
it may be useful to include the ability to associate a transaction
value limit with a particular signature key. This feature, included
in X.509 certificates, would support a requirement that high valued
transactions have a special approval signature.
5.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 authentication of trading partners. For example, a
process including the exchange of X.509 certificates, authenticated by
a Certification Authority (CA) would allow secure automated vendor
registrations, updates of public keys, associating signature keys
with approved purchase value limits, etc.
Many people are confused about CA requirements, and I think the wording
above makes it more clear about the function of a CA, and how secure
EDI works without a CA.
---
A "Content-Encoding" (e.g. same as RFC1945-HTTP) than permits compression
is more important. For S/MIME, this is very useful. For PGP, the encryption
already compresses, but for signed catalogs, etc. which are unencrypted,
the Content-Encoding could substantially shrink the message size.
To recap:
Content-Encoding = "Content-Encoding" ":" content-coding
content-coding = "x-gzip" | "x-compress" | token
---
I suggest adding another section (4.5?) describing the other function
of receipts, namely delivery assurance. Besides the functions described
in section 4.1, the sender should use a lack of receipt to detect lost
messages. Following the successfull message transmission via SMTP or
other protocol, if a receipt has not arrived within some period, the
message may be resent. Typically, the timeout period would vary widely
for different trading partners, depending on the type of network connection
and hours of operation.
In the case of a retransmitted message, the same RFC822 Message-ID: header
should be used. Messages with duplicate Message-ID values can be ignored.
However, a duplicate message arriving long after a receipt has been
transmitted probably indicates that the receipt has been lost, and the
receipt should be resent with the same Message-ID as the original receipt.
Repeated failure to receive a receipt or repeated duplicate Message-IDs
should be handled with manual intervention.
Other than retransmission of a possibly lost message, all Message-ID
values should be unique. The contents of a retransmitted message with
the same Message-ID shouldbe unaltered.
---
I think it might be useful to mention the use of Gateway systems, e.g.
a VAN which might interface existing EDI networks with the general SMTP
based EDI messaging described in this document. The VAN might act simply
as an ISP with additional services, e.g. message logging, in the case
where a TP generates MIME signed or encrypted messages. Some VAN services
might require analysis of the outgoing or incoming messages, in which
case the VAN would encrypt or decrypt contents signed by the TP.
To interface with existing EDI networks which use private data links
passing unsigned/unencrypted messages, the VAN may perform the MIME
encryption and signature processing on behalf of a client for exchange
with a TP or VAN. Messages to be received by such a client would be
encrypted using the VAN's public key. The VAN would sign the messages
(typically with a separate key per client) as a proxy for the client.
Likewise, a VAN might use X12.58 security protocols between itself
and a client, and might use similar proxy encryption and signatures
to exchange messages with a TP that does not support X12.58.
---
When the processing of an EDI message is immediate and a 997 or other
reply message is generated from the EDI subsystem, it may be useful to
return the reply with the receipt. In this case, a MIME multipart/mixed
Content-Type would be used to combine an RFC1767 labelled EDI Object
with the report MDN, which is then signed and encrypted.
---
It would also be useful to mention the possible use of the message/digest
content type to receive collections of EDI messages, possibly from
different senders, as a single message. For example, an RFQ filtering
service might scan collections of messages and select a subset which meet
certain criteria, returning a batch of RFQs as a single message digest.
--------------------------------------------------------------------------
Carl Hage C. Hage Associates
<email:carl@chage.com> Voice/Fax: 1-408-244-8410 1180 Reed Ave #51
<http://www.chage.com/chage/> Sunnyvale, CA 94086