Re: Please Respond: Security Sections in ebXML Requirements Spec 1.04

[Mike Rawlins <mike@rawlinsecconsulting.com>]

I don't think you can argue that businesses have a need to be able to interpret
the meaning of an electronic document several years from now.   An adequate
measure may be what we do now with EDI - you can interpret the basic semantics
of an interchange or transaction set as long as you have the corresponding X12
or EDIFACT standards manuals.  The specific implementation conventions would be
best, but if you have neither you're sunk.

Our intent regarding the requirement was that the ebXML solution support (or at
least not prohibit) a similar level of support regarding archiving.  Whether or
not we meet that requirement is another matter.

Hope this helps clarify.  If your group recommends further changes to the
Requirements Spec 1.04 based on this clarification, please let us know ASAP.

Mike


"Scherling, Mark" wrote:

> For one of Mike's questions on semantic reconstruction, I'd be cautious on
> attempting that at this particular moment.  A Semantic Web is a vision of
> Tim Berners Lee and others but not really practical given the limitations of
> interpretation standards and contextual references that may or may not be
> understood by the system or application reconstructing the phrase.  If you
> are going to look at semantics, then it would be best to set up standards
> such that interpretation could be more consistent.  That will take a lot of
> work!
>
> -----Original Message-----
> From: Maryann Hondo [mailto:mhondo@us.ibm.com]
> Sent: Wednesday, May 02, 2001 11:01 AM
> To: mike@rawlinsecconsulting.com
> Cc: ebxml-ta-security@lists.ebxml.org; Mark CRAWFORD;
> tmcgrath@tedis.com.au
> Subject: Re: Please Respond: Security Sections in ebXML Requirements
> Spec 1.04
>
> MIke,
>
> Since the security section in question  is under "business" requirements as
> opposed to "technical
> specification" requirements, I suggest the following structure/wording for
> this section.
>
> But, then, I would also include some text for the "technical" section. A
> very rough suggestion is attached below.
>
> Maryann
>
> ----------------------------------------------------------------------------
> ---------------------------------------------
> 6.5 Security
>
> Businesses   have  a  high  level  requirement  that  appropriate  security
> technology   be   applied  to  protect  information  involved  in  business
> processes.  Aspects  of  security  may  be  required at various layers of a
> business  process;  at an outsourcing/transaction layer, at a session layer
> (i.e., for the duration of a network session in which data is exchanged) or
> applied   to   a   single,  stand-alone  document  instance.  In  addition,
> application  of security to a particular exchange or document instance must
> be  determined  by the business needs, and allow unrestricted and unsecured
> interchanges  if  the  business   process  requires  this. All, some, or no
> security  features  may  be required in any particular exchange of business
> information. The following requirements are general security definitions:
> ¨    Confidentiality - Only sender and receiver can interpret document
> contents
> ¨    Authentication of sender - Assurance of the sender's identity
> ¨    Authentication of receiver - Assurance of the receiver's identity
> ¨    Integrity - Assurance that the message contents have not been altered
> ¨    Non-repudiation of Origin - The sender can not deny having sent the
> message
> ¨    Non-repudiation of Receipt - The receiver can not deny having received
> the message
> ¨    Archiving - It must be possible to reconstruct the semantic intent of
> a document several years after the creation of the document
>
> The understanding of these security requirements is also subject to the
> following related requirements; Legal, Digital Signatures,
> Interoperability, and Third Party Trust relationships.
>
> For example; The archiving, Authentication and Non-Repudiation of Origin
> and Receipt may be performed by a trusted third party through which the
> Parties to a transaction agree to channel transaction messages in order to
> provide independent historical proof that the transaction took place at a
> specific time and on specific terms. This time period is subject to the
> archiving and record retention requirements of particular situations. In
> general, businesses might require archiving and retrieval of up to 30 years
> after document creation.
>
> 6.5.1     Legal
> Beyond the security requirements identified in section 6.5, the following
> additional legal requirements exist:
> ¨    Comply with the requirements of UN/CEFACT recommendation 14 -
> Authentication of Trade Documents by Means Other Than Signature
> ¨    Provide versioning support to facilitate reconstructing the semantic
> meaning of transactions in accordance with the underlying transaction
> format used
> ¨    Ensure full audit capability is supported
> ¨    Ensure all transmitted data is well defined by a minimal set of
> metadata
> ¨    Ensure a mechanism provides for identifying completeness of a
> transaction
> 6.5.2     Digital Signatures
> Digital signatures, or electronic signatures, have security and legal
> implications that directly impact on electronic business requirements. As
> more and more government bodies define digital signatures, and enact
> legislation that adopts such techniques as having the same force of law as
> traditional signatures, new technology solutions must accommodate these
> business requirements.
>
> The following definition and statement of compliance requirements is taken
> from Article 6 of  UN Commission on International Trade Law, Working Group
> on Electronic Commerce, Draft Guide to Enactment of the UNCITRAL Model Law
> on Electronic Signatures (A/CN.9/WG.IV/WP.88)
>
> (1)  Where the law requires a signature of a person, that requirement is
> met in relation to a data message if an electronic signature is used which
> is as reliable as was appropriate for the purpose for which the data
> message was generated or communicated, in light of all the circumstances,
> including any relevant agreement.
> (2)  Paragraph (1) applies whether the requirement referred to therein is
> in the form of an obligation or whether the law simply provides
> consequences for the absence of a signature.
> (3)  An electronic signature is considered to be reliable for the purpose
> of satisfying the requirement referred to in paragraph (1) if:
> (a)  the signature creation data are, within the context in which they are
> used, linked to the signatory and to no other person;
> (b)  the signature creation data were, at the time of signing, under the
> control of the signatory and of no other person
> (c)  any alteration to the electronic signature, made after the time of
> signing, is detectable; and
> (d)  where a purpose of the legal requirement for a signature is to provide
> assurance as to the integrity of the information to which it relates, any
> alteration made to that information after the time of signing is
> detectable.
>
> The ebXML technical framework must support electronic transactions that
> provide for electronic signatures at an appropriate level within the
> transaction to meet requirements of both the sender and receiver in keeping
> with the forgoing definition and attributes.
>
> ----------------------------------------------------------------------------
> --------------------------------------------------------------------
>
> 7.3  Recommendations
> The Requirements Project Team's initial task was to produce this ebXML
> Requirements Specification. In addition, the Requirements Project Team
> makes the following recommendation:
> ¨    Develop follow-on requirements for an overall security model that
> addresses the combination of security requirements as well as those
> security requirements included in each of the individual specifications.
>
> ----------------------------------------------------------------------------
> --------------------------------------------------------------------
>
> Mike Rawlins <mike@rawlinsecconsulting.com> on 04/27/2001 11:05:02 AM
>
> Please respond to mike@rawlinsecconsulting.com
>
> To:   ebxml-ta-security@lists.ebxml.org
> cc:   Mark CRAWFORD <mcrawford@lmi.org>
> Subject:  Please Respond: Security Sections in ebXML Requirements Spec 1.04
>
> QRT offered the following comment regarding this specification, which is
> currently posted for public comment on the ebXML web site.
>
> Security Requirements
>
> Some of the requirements for security may not be reasonable (line
> 558-567) or specific enough (line 335) for conformance. We suggest this
> material (mostly in section 6.5 (lines 534-601) should be ratified
> against the risks identified in the Security Architecture Team's Risk
> Assessment document.
>
> Section 6.5 Security ? Archiving (lines 549-550)
> Is it practical for a requirement to enable semantic reconstruction
> where normal practice it is adequate to simply have access to the
> document?
>
> Please assess these comments and provide us with any suggested wording
> changes by close of business, Thursday, April 27.  If no changes are
> offered, this section will remain as written in the final version and we
> will note in our comment disposition log that your team offered no
> changes.
>
> Thanks very much,
>
> ---------------------
> Mike Rawlins, ebXML Work Group, Requirements Project Team Leader
> http://www.ebxml.org/project_teams/requirements/private/
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-ta-security-request@lists.ebxml.org
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-ta-security-request@lists.ebxml.org

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com