Re: I believe that AS2 is now ready to be submitted to IETF as a RFC...
Richard Scott <[email protected]> Wed, 07 Jan 2004 10:33:34 -0600
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <[email protected]> |
--------------CADADACBC3E4AFB25D9FF01F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------CADADACBC3E4AFB25D9FF01F
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello, Nicolas.
<p>The changes you noted were made after a review of the previous draft
revealed that the unintentional changes had been introduced which made
it inconsistent with RFC 3335 ("as1"). That, as I believe you
will agree, would not be a good thing; hence the updated text again
brings them into synchrony.
<p>Note that the signed-receipt-micalg parameter is still honored for signed
messages: the "algorithm used to calculate the MIC" refers to the
digest returned inside the signed MDN as the "received-content-MIC", which
may be different from the algorithm used to sign the MDN itself.
The signed-receipt-micalg parameter refers to the algorithm used to sign
the MDN.
<p>For an unsigned message that requested a signed MDN, a digest will be
computed using SHA-1 and returned as the "received-content-MIC".
<p>In either of the above cases where a signed MDN is requested, the MDN
is signed using the algorithm specified in the signed-receipt-micalg parameter
in the disposition-notification-options header (left-to-right precedence
if more than one algorithm specified) , or SHA1 if not specified.
<p>Hope that clarification resolves the issue to your satisfaction.
<p>Regards,
<br>Richard
<br>
<p>Nicolas Bielza wrote:
<blockquote TYPE=CITE> <span
class=529030415-07012004><font face="Arial"><font color="#0000FF"><font size=-1>in </span>draft-ietf-ediint-as2-14.txt<span
class=529030415-07012004>,
section 7.4.3:</font></font></font></span> <i><font face="Arial"><font color="#0000FF"><font size=-1>For
signed messages, the algorith used to calculate the</font></font></font></i>
<br><i><font face="Arial"><font color="#0000FF"><font size=-1>MIC MUST
be the same as the algorithm that was used on the</font></font></font></i>
<br><i><font face="Arial"><font color="#0000FF"><font size=-1>message that
was signed.</font></font></font></i> <span class=529030415-07012004><font face="Arial"><font color="#0000FF"><font size=-1>Then
if the message is signed, the signed-receipt-micalg parameter is not taken
into account;</font></font></font></span><span class=529030415-07012004><font face="Arial"><font color="#0000FF"><font size=-1>But
the draft continues with:</font></font></font></span><span class=529030415-07012004></span><i><font face="Arial"><font color="#0000FF"><font size=-1>If
the message is not signed, then</font></font></font></i>
<br><i><font face="Arial"><font color="#0000FF"><font size=-1>the SHA-1
algorithm should be used.</font></font></font></i> <span class=529030415-07012004><font face="Arial"><font color="#0000FF"><font size=-1>So
the signed-receipt-micalg parameter is never taken into account ? (And
there's no way of requesting a MD5 MIC for an unsigned message).</font></font></font></span><span class=529030415-07012004></span>
<blockquote dir=ltr style="MARGIN-RIGHT: 0px">
<blockquote dir=ltr style="MARGIN-RIGHT: 0px">
<blockquote dir=ltr style="MARGIN-RIGHT: 0px"><font face="Arial"><font size=-1></font></font> </blockquote>
</blockquote>
</blockquote>
</blockquote>
</html>
--------------CADADACBC3E4AFB25D9FF01F--