OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-security message

[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