[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