[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC