AS2 canonicalization for MIC calculation ?
"Caro Sebastien" <[email protected]> Fri, 16 Jan 2004 11:11:14 +0100
| Newsgroups | gmane.ietf.ediint |
|---|---|
| Message-ID | <[email protected]> |
It is said in AS2 section 7.3.1 (Signed receipt considerations) that in some cases canonicalization must be performed before the MIC is calculated. No reference is given on where to find the canonicalization process: - AS1 refers to RFC 1848 - MIME defines canonical form as the result of steps where one of them rely on media type specific representation (RFC 2049 section 4) - S/MIME refers to MIME RFC 1848 (section 2.1.1) isn't very clear, but it says that the originator must replace local line terminators by CRLF before computing the digital signature and then send data with the local line terminators. If such a thing is done to transfer data between 2 different systems, it is obvious that the receiver will not know the originator line terminator, and he will therefore not be able to re-insert CRLF at the right places. RFC 1767 and RFC 2376 do not introduce any canonical representation. By the way, RFC 2376 has been obsoleted by 3023, shouldn't AS2 RFC use references to this document instead? S/MIME says that 'The data to be secured is always a canonical MIME entity'. So, signed or ciphered data is sent already canonicalized and it doesn't seem necessary for the receiver to canonicalize once more the received data. Still in AS2 section 7.3.1, > - For any signed messages, the MIC to be returned is > calculated on the RFC1767/RFC2376 MIME header and content. > Canonicalization on the MIME headers MUST be performed > before the MIC is calculated, since the sender requesting > the signed receipt was also REQUIRED to canonicalize. > - For encrypted, unsigned messages, the MIC to be returned > is calculated on the decrypted RFC 1767/RFC2376 MIME header > and content. The content after decryption MUST be > canonicalized before the MIC is calculated. The MIME header is supposed to be in a canonical form, containing CRLFs. The sent data is contained in a MIME entity which is itself inside the request body. HTTP request bodies are not to be altered. I am a bit confused by the amount of information I found and would appreciate clarification. Sebastien