[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bdxr] BDE requirements
Hi Ken Thanks for this! Please see my comments below. Best regards, Kenneth On 2015-02-23 14:20, G. Ken Holman wrote:
- "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
By all means, if there is a value for the user in being able to choose which hash algorithm to use, let's keep it in there. My question was if we could simplify the use a bit by specifying that hash totals was always to be generated with for example SHA256. But if there is not one shoe that fits all then we leave it as it is.
- “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.
Yes, I agree with everything you wrote above. My question was if "PayloadInstanceEncryptIndicator" could be replaced with a "PayloadInstanceEncryptionMethod". The PayloadInstanceEncryptionMethod would be not-present if no encryption was used, and in case encryption was used would hold the algorithm used for encryption.
- “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.
I'm not sure I understand or see the use case where both the ProfileID and ServiceID would be present, but I'm not religiously opposed to having both of them in the spec either. If you believe that the necessity is there then no objection from me.
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.
Is there any scenario where the business envelope software would need to know the CustomizationID? Will anyone ever need to know the CustomizationID except for understanding how to read the business document? For service routing etc. we already have the ProfileID and ServiceID.
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.
So are we introducing a requirement for a third party to get involved in the creation of the envelope (in certain use cases at least)?
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.
Anything I can do to help you just let me know!
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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]