RE: Minutes: Security Subteam 10/01/01

["Patil, Sanjay" <SPatil@iona.com>]

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

The top Message level Content-Type header with "Multipart/Related" 
value is what I was referring to as MIME type.
The content of each part in the Multipart message (whether the part
contains the content or signature) can then be identified by using 
either a standard value for Content-Type  header, or some other 
header (ex. RosettaNet uses Content-Location header) of that part.

An alternative for identifying the content of each part is to
have the spec to prescribe the order of payload content and
signature parts in the MIME message. Since we were going ahead with
mandating a signature for each message, this would work too.

These above options  are to meet the objective of low barrier 
of entry as these options will work with a standard MIME software
(of course the XML Signature handling software will also be needed).

The option 3 is much cleaner as it uses the standard RFC 1847 
Multipart/signed MIME type. However, it will require a 
"Multipart/signed; protocol=application/xml-signature" aware software.
We are also assuming here that the "application/xml-signature"
or such type is registered and solutions are available for the same.

The above is what I understood in the discussion. If this
is incorrect, please treat it as Scribe's negligence and make
corrections.

thanks,
Sanjay Patil
----------------------------------------------------------------------------
------------------------------
IONA
Total Business Integration (TM) 
Phone: 408 350 9619                                 http://www.iona.com


-----Original Message-----
From: sekhar vajjhala [mailto:sekhar.vajjhala@Sun.COM]
Sent: Tuesday, October 02, 2001 1:02 PM
To: Patil, Sanjay
Cc: 'regrep-security@lists.oasis-open.org'
Subject: Re: Minutes: Security Subteam 10/01/01


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