Re: Minutes: Security Subteam 10/01/01

[sekhar vajjhala <sekhar.vajjhala@Sun.COM>]

Sanjay,

I need a clarification on option b in Packaging of signature and
content.
Please see inline.

"Patil, Sanjay" wrote:
> 
> Attendees:
>   Suresh Damodaran
>   Farrukh Najmi
>   Sekhar Vajjhala
>   Sanjay Patil
> 
> - Message Signature
>   Is it required at this point of time to consider supporting or leaving the
>   specification forward compatible for digital signature technologies other
> than
>   XML Signature? Specially, does the scenario of thin Vs. fat Registry
> Client
>   brings forth any such requirements?
>   Resolution: For the purposes of V2, it would be sufficient to say -
>   The V2 spec requires compliance with XML Signature specification for
>   message signatures. In future versions, other digital signature related
>   specifications might be brought into picture, however for V2, the Registry
>   behavior is undefined if specifications other than XML Signature are
>   used for message signing.
> 
> - Packaging of Signature and Content
>   Three alternatives were considered.
>   a> Content and Signature are separate parts, with identification of each
>        part and the blob that is signed handled by Content-Type and
> Content-URI
>        MIME headers
>   b> Content and Signature are separate MIME parts. The MIME type being used
>        is multipart/related. The order of MIME parts and probably
> Content-Type
>        to be used for identifying Signature from Content. Any other details
> essential
>        for Signature to identify the blob in the content that is signed, etc
> are to
>        be clearly specified in the V2 spec.

What is the distinction between MIME type and Content-Type ? I have
found only one type i.e. Content-Type which has to be mulitpart/Related.

So now I am not sure how the packaging can be done to indicate the 
presence of a XML signature.

Can you clarify ?

Sekhar

>   c> Make use of Multipart/Signed type, register a new MIME type for XML
> Signature
>        (RFC 1847)
> 
>    Resolution: Using Multipart/Signed will require more than general-MIME
> infrastructure.
>       In order to keep low barrier of entry, handling of Multipart/related
> which is handled
>       by general-MIME infrastructure is preferred.
>       Assumption: All messages are required to be signed. Otherwise,
> differentiating
>           between signed and unsigned Multipart/related introduces
> complexity in specification
>           and thereby implementations.
> 
> - Access Control Policies
>   Suresh presented and walked the attendees through a first cut of ACL
> support proposal.
>   After discussion and exploring several possibilities for minimum support
> for ACL, it was
>   considered to either postpone or phase out work on ACL in order to meet
> specification
>   deadlines.
> 
> thanks,
> Sanjay Patil
> ----------------------------------------------------------------------------
> ------------------------------
> IONA
> Total Business Integration (TM)
> Phone: 408 350 9619                                 http://www.iona.com
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

-- 
Sekhar