OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wss] SwA Profile Comments


At 12:35 PM 7/12/2004, Michael McIntosh wrote:




>lines 152-154 explain that MIME Headers must be canonicalized, but does not
>provide an algorithm for doing so.


What S/MIME says is


    The exact details of canonicalization depend on the actual MIME type
    and subtype of an entity, and are not described here. Instead, the
    standard for the particular MIME type should be consulted. For
    example, canonicalization of type text/plain is different from
    canonicalization of audio/basic. Other than text types, most types
    have only one representation regardless of computing platform or
    environment which can be considered their canonical representation.
    In general, canonicalization will be performed by the non-security
    part of the sending agent rather than the S/MIME implementation.

I think we should say essentially the same thing.  In other words, 
canonicalization is the responsibility of the agent that constructs the 
entity before security processing is applied. For "text" (which is the 
important type) these is a discussion of canonical form in the MIME spec 
(RFC 2045) itself.


MIME types need to be registered and RFC 2048 which defines what must be in 
a registration includes a section on "Canonicalization and Format Requirements"



>lines 161-166 explain that MIME Part canonicalization algorithms are
>dependant on the content-type, but does not explain how to find the details
>for any content-types.
>
>lines 197-203 explain that digests are computed over MIME Parts after
>decoding any Content-Transfer-Encoding, but it is unclear whether you can
>sign the Content-Transfer-Encoding header itself.

I think we should say that the Transfer-Encoding header is not included. 
The idea has always been that the content-transfer-encoding could be 
changed along the path without affecting the security processing.

This would need to be specified as part of the specification of the 
"Attachment-Complete" transform.


>Thanks,
>Mike
>
>
>To unsubscribe from this mailing list (and be removed from the roster of 
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]