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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: RE: Security Signatures


A few comments below marked with ## ...


-----Original Message-----
From: Miller, Robert (GEIS) [mailto:Robert.Miller@geis.ge.com]
Sent: Tuesday, March 21, 2000 11:52 AM
To: ebXML Transport (E-mail)
Subject: RE: Security Signatures

Some business models may require 'signature over signature', not just
multiple signatures.  
## I agree##
If we provide in our header structures the ability to
sign both headers and message bodies, we may have to address a 'signature
over signature' requirement.  This suggests to me that 'signature' should be
a standalone XML document, 
##Probably true if we use S/MIME, but not true if we use XMLDSIG##

whose content includes a 'table of contents' over
which the signature has been applied.  
##XMLDSIG defines it's own "manifest" which is effectively a table of
contents. We need to think what we do about an equivalent of this if we use

The specification currently states in '2 Message Structure' that 'Message
Signatures are held in the Header Envelope separately from the other headers
since: o Signatures cannot sign themselves and ...'

While signatures cannot sign themselves, 
they can sign other signatures.
##Also agreed##
Therefore, IMO, each signature should be held in a separate body part, not
within the Header Envelope (assuming Header Envelope' is a single body
part).  The scope of a signature would be defined by a 'table of content'
within the signature document.

There likely also is an architectural simplicity benefit in constraining
signatures to separate XML documents.
##We want to strive for architechtural simplicity, but IMO, what is "simple"
will vary depending on the technology we use for signing (XMLDSIG or
S/MIME). As XMLDSIG development is well advanced (it's just gone to "last
call" we should be able to make sensible decisions on how to handle both.##


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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC