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
