[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AS#1 draft-ietf-ediint-as1-01.txt comments
Carl, I know all of this...I was trying to keep it short since almost no
one reads long messages!
The mic should only be over the (I am only talking signature here..not
encryption)
Message:== smtpHeader+rfc1847(mime(data),signature(mic))
the mime(data). It should not be over anything else. This example's logic
holds for pkcs7 format also.
> receipt_message_content = rfc1847_multipart(receipt_data,
> signature(receipt_data))
>
> receipt_data = mdn_multipart(text_message,
> mdn_headers+x-mic(????),
> message_abstract)
>
> message_abstract = null | rfc822_headers | message
Below the question marks (????) are the mic from the initial message which
looks like
initial_message= rfc822+rfc1847(mime(data,..,rfc1767,...),signature(mic))
This logic holds for both the pkcs7 and pgp/mime stuff.
Now, I forget, should the question marks be the mic or the signature(mic)?
I think the signature(mic) but I think I was talked out of that.
later...Rik
>>From drummond@onramp.net Fri Nov 1 02:24:40 1996
>>
>>Are we saying?
>>
>>
>>
>>
>>Or
>>
>> Message:==smtpHeader+rfc1847(mime(data))+signature(mic)
>
>Neither-- your terms are not quite appropriate or clear.
>
>RFC1847 specifies a multipart signature-- i.e. the first case only.
>However, S/MIME allows PKCS7 encrypted, signed data, called
>"SignedAndEnvelopedData", which is a simple MIME application type (not a
>multipart). An equivalent, is a two step process, a PKCS7
>EnvelopedData encryption of an RFC1847 multipart containing a PKCS7
>detached data signature. This equivalent is the process illustrated in
>AS#1, Mats mentions as the agreement.
>
>The RFC1847 support for detached signatures in S/MIME is relatively new
>to S/MIME, so some S/MIME software may not even support this. However, I
>consider this a serious bug with the original S/MIME, and software that
>creates SignedData only should be withdrawn.
>
>We need to define some terms so we don't get confused. Using a function
>notation, we could say:
>
> socket_data = smtpHeader+Message+smtpTrailer
>
>SMTP is a transfer protocol on top of the message, and not necessarily
>the only transfer protocol possible. The internet-EDI really applies to
>RFC822 email, not SMTP. The "message" usually refers to what you see in
>your email reader (unless you have a proprietary email system which munges
>the headers), which is the data passed to the "User Agent" (UA) from
>the "Mail Transfer Agent" (MTA). SMTP is a protocol MTA's use to communicate
>with each other.
>
> message = rfc822_headers+message_content
>
> message_content = edi_message_content | receipt_message_content
>
> edi_message_content = content_encode(encrypt(signed_data)) |
> rfc1847_multipart(encrypt_info,
> content_encode(encrypt(signed_data)))
>
> signed_data = rfc1847_multipart(rfc1767_data,signature(rfc1767_data))
>
> rfc1767_data = mime_header+edi_interchange
>
>The signature algorithm includes a MIC calculation, so it isn't usual
>to consider the MIC as a separate piece of data. A MIC may be used
>outside of a signature in a receipt or transfer protocol (e.g. HTTP uses
>Content-MD5 as an integrity/update check), and in this context, is independent
>of a signature. A receipt for non-repudiation must either contain the
>original message, or a MIC can be used in lieu of the message. The MIC
>embedded within the receipt signature is not the same as the MIC used
>in lieu of the original message. (The former is calculated on the receipt
>and the latter is calculated on the original message.)
>
>With PGP/MIME, the encoded, encrypted data is further wrapped in
>a rfc1847 multipart to get the edi_message_content.
>
> receipt_message_content = rfc1847_multipart(receipt_data,
> signature(receipt_data))
>
> receipt_data = mdn_multipart(text_message,
> mdn_headers+x-mic(????),
> message_abstract)
>
> message_abstract = null | rfc822_headers | message
>
>For privacy, the receipt_message_content could be further encrypted.
>A signed receipt is required for non-repudiation, which is not illustrated
>in the AS#1 example. There really is no information of sensitivity in
>the receipt, however. (Which is not already in the headers).
>
>----
>
>The real issue is the x-mic(???). I belive that ??? should be the
>message_content, not rfc1767_data. This means that the same receipt
>process works for any message_content, not just a single signed_data item,
>encrypted and encoded. The receipt process should be independent from all
>decoding and processing, other than passing back a status. Normally,
>receipts would be created and processed by the mailers.
>
>Also, I believe the message_abstract should normally be the rfc822_headers.
>
>The layering of independent pieces of software is roughly:
> - smtp transfer
> - smtp mail queuing/forwarding, Delivery Status Notification processing
> - message logging, MDN receipt processing, message retransmission
> - encryption/decryption/signature processing
> - message display or application data processing (X12/EDIFACT processing)
>
>---
>
>One of the advantages of using separate signature and encryption processes,
>is that the decrypted signed data can be logged and processed independently.
>For example, the original encrypted message (or headers+MIC) can be logged
>plus the results of the decryption can be logged, which contains the RFC1847
>signature multipart. All secret keys can be destroyed at some time in the
>future, but given the saved public keys, the encrypted message can be
>recreated/authenticated and the signature can be authenticated.
>--------------------------------------------------------------------------
>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
------------------------------------------------------
| Rik Drummond - The Drummond Group |
| 5008 Brentwood Ct., Ft. Worth, TX 76132 USA |
| Voice: 817 294 7339 Fax: 817 294 7950 |
------------------------------------------------------