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: RE: Minutes: Security Subteam 10/01/01


Guys,

	ACL would be a very appealing feature for private registries, even for
public registries. Controlling visibility based on roles would be a big win
for ebXML registry.

	just my 2c

cheers

  |-----Original Message-----
  |From: Patil, Sanjay [mailto:SPatil@iona.com]
  |Sent: Monday, October 01, 2001 6:59 PM
  |To: 'regrep-security@lists.oasis-open.org'
  |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
  |
  |
  |----------------------------------------------------------------
  |To subscribe or unsubscribe from this elist use the subscription
  |manager: <http://lists.oasis-open.org/ob/adm.pl>
  |



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC