RE: [ubl-ndrsc] Digital Signatures

[Chin Chee-Kai <cheekai@softml.net>]

On Tue, 3 Jun 2003, Paul Thorpe wrote:

>>I have no doubt the email (unencrypted) works fine quite often since there
>>is usually a human judging the authenticity (sometimes with a follow up
>>phone call), but when doing machine to machine transactions (especially
>>when large orders -- or financially significant orders), authentication
>>becomes much more important.  

I share your concerns about M2M communications.  For financially
significant orders, not any one within a company will be empowered
to operate on them even for humans, much less for machines as you
pointed.  Only secured machines with good trustable security
infrastructure may perhaps be empowered to handle those.  
But to be trustable to a business manager, authentication alone
does not cover the entire requirements of secured transaction.
A list of things some of which I mentioned earlier needs to be
in place.


>>Note, that the proposal is to make the
>>signature field optional so that authentication is not required by UBL,
>>but can be used if desired.  Some business may choose not to accept
>>documents that are not authenticated.

Noted.  Even as an option, such option needs to be described
in details for occassions when they do get used by users.
There would then be a need for UBL to survey, assess and identify
a particular mechanism, perhaps what you and others have suggested,
to perform authentication.  But authentication may not be sufficient
for other businesses, so other aspects of secured transaction
needs to be looked at, and so on.  That might take us rather
far off from UBL, and I suspect it may need another subcomm to 
look into that, if it is to be pursued.



>>Just look at various machine-based attempts to eliminate spam vs. human
>>recognition of what is or isn't spam.  If UBL documents are exchanged on
>>an open network, someone is going attempt to forge UBL documents.

This reminds me of something I read from IETF's end-to-end principle.
At one point in the development of TCP/IP, it was asked "why would
anyone trust an open network?  someone is going to forge packets,
so we should build in encryption at packet level."  Eventually,
the idea was dropped, and fortunately for us, in the majority of
network transport context that security isn't needed, the overheads
of maintaining security consistency is not imposed onto those users.
In partciular cases, the end-points will decide what level of
security is applicable to themselves, and have them implemented
above the network and transport layers.

We should learn from those lessons.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/