Sebastien observes>
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.
Canonicalization of _headers_ (mainly the MIME entity headers for MIC
calcs, of course)
For uniformity, canonicalization of MIME headers is always required.
Implementations could optimize whether they need to run a check in some
cases, though. Canonicalization of headers means, then, that they must
have CRLF at the end of lines and as a separator between header and
body. This iz just the MIME ABNF rules (RFC 2822, section 2.1, 2.2), 821
appendix, 2045, etc.
message = fields *( CRLF *text ) ; Everything after
; first null line
; is message body
field = field-name ":" [ field-body ] CRLF
[...]
entity-headers := [ content CRLF ]
[ encoding CRLF ]
[ id CRLF ]
[ description CRLF ]
*( MIME-extension-field CRLF )
Sebastien observes>
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.
Well, the MIME conventions of HTTP and SMTP messages differ
in several ways previously discussed in this group, and elsewhere, and
in various contexts. RFC 1848 (1995) is oriented toward "SMTP-style"
MIME. It would be misleading to reference it for HTTP, and this is not
done, nor is it necessary or desirable. It would introduce more
confusion over what is really a very simple point.
Sebastien observes>
By the way, RFC 2376 has been obsoleted by 3023, shouldn't AS2 RFC use
references to this document instead?
Yes.
Sebastien observes>
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.
An implementation may choose to optimize this case. Nevertheless, for
uniformity, the specese is that for MIC calculations MIME headers must
be canonicalized (CRLF), and
what are MIME headers will be syntactically clear in HTTP MIME.
Sebastien observes>
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.
Yes, very few people have found it unclear what canonicalization of MIME
headers means. Are you saying that we should be more explicit here and
mention CRLF as end of line and as header/body separator? We can do so
in a parenthetical remark. I personally see no real need to cite a
spec. This is more a warning to implementers that CRLF may get munged,
so always calculate the MIC over the ABNF-correct MIME headers. I guess
the syntax for headers is the reference you hanker to have? Would RFC
2822 suffice?
> - 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.
Caro Sebastien observes>
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.
Yes, and alteration [other than change of line endings!] should be
detectable when signatures exist.
|
