Re: [bdxr] BDE requirements

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Thank you for pulling this together, Kenneth!

At 2015-02-23 02:42 -0500, kenneth@alfa1lab.com wrote:
> Please feel encouraged to comment, edit, discuss
> and correct me everywhere you feel beneficial.

I have some feedback.

> I have as well created a simple gap analysis /
> requirements mapping between the first draft of
> the BDE requirements and the CEN BII
> requirements that were submitted to the TC:

That is very useful, thank you.

> - "InstanceHashAlgorithm", is there any reason
> why the user must be able to specify the hash
> algorithm used or could we improve usability by
> removing this field and instead specify which algorithm to use?

I believe the reason is that there is a plethora
of hash algorithms available to use, some easier
than others and some more full-featured than
others.  I do not believe their use is
self-identifying. For examples, a user may wish
to specify MD4, MD5, SHA1, SHA2, SHA256, or any
of dozens of hash algorithms listed here:

  http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions

> - â??PayloadInstanceEncryptIndicatorâ??, could
> it include be a reference to the encryption
> method used (if any) instead of just an
> indicator as to whether encryption was used?

I see encryption as different than a hash, in
that it is somehow more private.  Also, I see the
hash being a property of the envelope describing
the integrity of the clear text of the document,
but the encryption of the document as being the
business of the document itself and not the
envelope.  Your question prompted me to ask
myself if we could do without even the encryption
indicator, but I think the indicator has a
purpose:  if the envelope processing knows the
document is not encrypted, that is a signal that
the hash can be used by the envelope processing
to verify the integrity of the clear text.  If
the payload is encrypted, the envelope processing
software can't use the hash but the recipient could.

And the hash is an easily auditable or verifiable
string to compare by a human user.  Consider how
MD5 hashes are used by software sites that have
mirror distributions:  a user downloading a
mirror copy can compare its hash against the
published hash to assess the integrity of the
download.  An example is on
https://www.openoffice.org/download/ where you
can see a number of hashes published (such as
http://archive.apache.org/dist/openoffice/4.1.1/binaries/en-US/Apache_OpenOffice_4.1.1_Win_x86_install_en-US.exe.md5
for the MD5 for the Windows install).

Similarly, a recipient of an envelope with a hash
can ask the sender "is this the hash you sent to
me?" if they think an interloper has swapped both
the encrypted content and the hash content.

> - â??PayloadInstanceProfileIDâ?? and
> â??PayloadInstanceServiceIDâ??, I believe these
> two could be combined into one since the
> original requirement is that the other is only
> necessary if the one is not present (BII
> requirements MSGE-15 and MSGE-16). The
> customization ID is a different animal from the
> profile ID by the way. The customization ID is
> commonly used to indicate a user community's
> individual requirements to a document (for
> example making it mandatory to always include
> certain information in a document), whereas the
> profile ID defines a business context.

Sure, but if the envelope fields are populated
with the document fields and the sender wishes to
specify some kind of overriding process, there
would be no room for it.  When I read this it
made sense to me that copies of the document
context metadata in the envelope were important
and that an envelope specification of context was also necessary.

> However:
>
> - "CustomizationID" is, I believe always
> included in the business document itself. So why
> do we need to have it in the envelope also?

Because the business document might be encrypted,
and I think the less that business envelope
software looks in on any payload, the
better.  Also, especially if all of the document
contexts are applicable to satisfy CEN/BII but
they are found in different places in the payload
for a UBL instance or a UN/CEFACT instance, the
payload software won't know where to look for such information.

And, after all, we are talking about a business
envelope instead of just a transport envelope, so
I think the business context information is
important to have available in the envelope.

I strongly believe the envelope software should
not be looking in on the payload.

> Or should there perhaps be a customization ID for the envelope itself?

Interesting question ... but I think the payload service identifier is enough.

> Finally a note on the "hash of the unencrypted
> document" discussion: How would you go about
> verifying the integrity of a document in cases
> where the sender must remain anonymous?

I think by the envelope creator signing the
envelope.  They can take the originator's
content, hash it, encrypt it, envelope it and
send it.  They have a trusted agent relationship to the originator.

> It is my understanding that if signing the
> envelope then the originator would appear in the signature.

Or the originator's agent.

> If including the hash of the encrypted document
> then anyone tampering with the envelope could also replace the hash.

True, but the hash is a human-manageable piece of
information (as I cite above).

> So I am guessing that the origin of the
> requirement is to be able to somehow enable that
> the integrity of the original document can be
> verified without revealing the identity of the sender.

Personally, I didn't see the sender's identity as
playing into it.  I see it simply as a
commonly-deployed web-oriented integrity-checking scheme.

I will await other comments but, meanwhile, I'll
edit the requirements in as you have drafted them
in the DOCX file.  The editing task includes
changing all the hyperlinks from the components to the requirements.

May I please remind other members that we need
the feedback ASAP so that I can do the editing
and any model and schema changes ASAP?  I am on
leave in less than 2 weeks.  It would be helpful
if we could vote on a package on Wednesday March
4 for public review (while I'm gone).  I should
prepare CSD01WD04 first for everyone's review before preparing CSD01 and PRD01.

. . . . . . . Ken

--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Free 5-hour lecture:  http://www.CraneSoftwrights.com/links/video.htm |
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/o/ |
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com |
Google+ profile:       http://plus.google.com/+GKenHolman-Crane/about |
Legal business disclaimers:     http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com