[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Minutes: Security Subteam 10/01/01
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. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC