XAdES in OPC: Further comments from Japan

[John Haug]

This seems the best existing mail to add to.  I promised some time back to forward comments from someone on our security team.  My apologies for the delay.  I’ve summarized these point on recent conference calls.




I also have some concerns with supporting ISO 14533-2.  Limiting support in Office to –T and –A (which we don’t support today) would reduce the number of customers that can use the feature.  As David mentioned it would be great from a security and data integrity perspective if everyone required a timestamp to create a digital signature.  We investigated making XAdES –T the default for Office 2013, however there are no free timestamp servers available for customers to use.  This would limit the feature to customers that run and maintain their own timestamp server or have one accessible to them.  We did not feel that it was wise to limit the feature just to customers who have timestamp servers available as many customers use the Office digital signature feature for different reasons.  Some customers simply use it as a way of inking their name on a document, which they plan on printing out.  In this case requiring a timestamp would block them from using  our feature to accomplish their goals.

Office hasn’t received any customer requests to support XAdES –A or counter signatures.  When we last investigated adding support for them, they didn’t make the cut because we didn’t have data to support the need and our team had other feature priorities.

In terms of the hashing algorithm compromise that has always been a concern with digital signatures and was why –A was created.  It appears that the research has discovered a flaw in the existing XAdES –A implementation which would still allow tampering with signed contents to go undetected in the event of an algorithm failure.  In Office 2013 we introduced a new feature to warn customers that their digital signatures contain algorithms which are considered weak  cryptographically and may end up failing in the near future (today only MD5 appears in this category by default).  We made this feature configurable via group policy so that customers could determine what the right policy is for their scenarios and then either warn their users or block signature creation and fail validation.



-----Original Message-----
From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: Thursday, July 17, 2014 3:11 AM
To: SC34
Subject: XAdES in OPC: Further comments from Japan



Dear colleagues,



I gave a report of the Prague meeting in the latest meeting

of the Japanese SC34 mirror.   Now, XAdES experts in Japan

attended this meeting.    They gave some comments (shown

below).   They plan to attend the Kyoto meeting.





XAdES-C and XAdES-X-L are alternative choices.  XAdES-C does not depend on XAdES-X-L, and XAdES-X-L does not depend on XAdES-C.



XAdES-C and XAdES-X-L are intermediate forms rather than distributable forms.



Among the profiles of XAdES, it is only XAdES-A that provides long-term digital signature.



Although XAdES-A is not the only way for providing long-term digital signature, it is a standalone solution: no external data is required.

Meanwhile, XAdES-X-L or XAdES-C can be combined with some external data for providing long-term digital signature.  In other words, neither XAdES-X-L nor XAdES-C provides a complete solution.



XAdES-X-L does not require the use of XAdES-C or XAdES-X.





Regards,

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20140917/9bdd1726/attachment-0001.html>