XAdES Support and the Revised OPC [formerly "DR 11-0030: Proposal"]
MURATA Makoto
eb2m-mrt at asahi-net.or.jp
Sat Jun 11 09:52:45 CEST 2016
I propose to send a question to public-xmlsec at w3.org,
and ask questions about the differences between DSig 1.0
and 1.1.
Here is my draft.
Regards,
Makoto
--------------------------------------------------------------------------
Dear colleagues,
I am writing this mail as the convenor of ISO/IEC JTC1/SC34/WG4, which
maintains OOXML. WG4 is trying to create a new version of OPC (Open
Packaging Conventions) of OOXML. The biggest change in this version
is the introduction of XAdES EN.
The existing version of OPC uses the first edition of DSig 1.0. But
XAdES EN normatively references DSig 1.1. What should the new version
of OPC should reference?
We are aware of "Functional Explanation of Changes in XML Signature
1.1", "Changes in XML Signature Syntax and Processing (Second
Edition)", "Implementation report for XML Signature, Second Edition",
and "XML Signature 1.1 Interop Test Report". We understand that
migration from SHA-1 to newer algorithms is the biggest difference
introduced by DSig 1.1.
Since XAdES EN references DSig 1.1, we believe that OPC should also
reference DSig 1.1. But should OPC reference DSig 1.0 as well?
To resolve this issue, we would like to ask some some questions. Your
thoughtful advice would be truly appreciated.
Q1: Are data conformant to DSig 1.0 guaranteed to conform to DSig 1.1?
In my interpretation, X509IssuerSerial is deprecated and the use of
SHA-1,HMAC-SHA1,RSA-SHA1, ECDSA-SHA1, XPath tranform is discouraged.
But no features were removed. Thus, the answer to Q1 is Yes. Is our
interpretation correct?
Q2: Is the support of all new required features of DSig 1.1 common?
I heard from a XAdES expert that most implementations of XAdES EN
actually support DSig 1.0 rather than DSig 1.1. I had a quick look at
"XML Signature 1.1 Interop Test Report". But few implementations
appear to support all features. Do implementations support all
required features of DSig 1.1?
Q3: Even when some features of DSig 1.1 are required, is it OK for OPC to
make them optional?
If the answer to Q2 is not positive, WG4 might want to make the
support of some DSig 1.1 features optional, although they are required
by DSig 1.1. This is arguably bad, but might be better than
referencing DSig 1.0, which recommends SHA-1.
We are looking forward to your reply.
Regards,
Makoto
2016-06-02 23:01 GMT+09:00 Shawn Villaron <shawnv at microsoft.com>:
> And I believe that this discussion indicates more investigation is
> necessary before we can commit to any particular course of action. I’ll
> circle with Darrin and see what we can do from our side.
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Thursday, June 2, 2016 3:15 AM
> *To:* SC34 <e-SC34-WG4 at ecma-international.org>
>
> *Subject:* Re: XAdES Support and the Revised OPC [formerly "DR 11-0030:
> Proposal"]
>
>
>
> I vaguely remember that Tracie said that Microsoft implements
>
> most of the mandatory algorithms. But Tracie left Microsoft.
>
>
>
> BTW, I heard from my Japanese XAdES colleague that few of the
>
> XAdES EN implementations support mandatory algorithms in
>
> DSig 1.1.
>
>
>
> Regards,
>
> Makoto
>
>
>
> 2016-06-02 19:05 GMT+09:00 Francis Cave <francis at franciscave.com>:
>
> Murata-san
>
>
>
> It is obviously preferable if we only have to reference the latest version
> of XML DSig. From a cursory glance at the specifications, the following
> paragraph appears to summarise the changes in XML DSig 1.1 that affect
> conformance:
>
>
>
> “Conformance-affecting changes of XML Signature 1.1 against [the]
> previous recommendation mainly affect the set of mandatory to implement
> cryptographic algorithms, including Elliptic Curve DSA (and mark-up for
> corresponding key material), and additional hash algorithms. A detailed
> explanation of changes since the last Recommendation are available [
> XMLDSIG-CORE1-CHGS
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2fTR%2f2013%2fREC-xmldsig-core1-20130411%2f%23bib-XMLDSIG-CORE1-CHGS&data=01%7c01%7cshawnv%40microsoft.com%7cbb6c001921a04da3a42808d38acedde6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3IHKp2sqTeRypHJ2AVU9prjjgkHlMgWMNfhAR82nrhk%3d>].
> Changes are also described in a diff document showing changes since the
> Second Edition
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2fTR%2f2013%2fREC-xmldsig-core1-20130411%2fOverview_diff_rec.html&data=01%7c01%7cshawnv%40microsoft.com%7cbb6c001921a04da3a42808d38acedde6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0Zn%2bsUCiAlq0i736C0A%2fS33WxFSOJaqd3nR1fLTr0pU%3d>,
> as well as a diff document showing changes since the previous PR draft
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2fTR%2f2013%2fREC-xmldsig-core1-20130411%2fOverview_diff.html&data=01%7c01%7cshawnv%40microsoft.com%7cbb6c001921a04da3a42808d38acedde6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=CPtqgibMyv1c46AnNuY61%2f2vvUPubs5iqkJfl95YvAY%3d>
> .”
>
>
>
> Since this is not my area of expertise, I’m not sure whether we have
> already adequately reviewed the changes in XML DSig 1.1. Does this need
> more discussion in Prague? I guess that we need the Ecma team to confirm
> that they agree that referencing XML DSig 1.1 and not the previous edition
> won’t break existing implementations.
>
>
>
> Kind regards,
>
>
>
> Francis
>
>
>
>
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* 02 June 2016 08:31
> *To:* Francis Cave <francis at franciscave.com>
> *Cc:* SC34 <e-SC34-WG4 at ecma-international.org>
> *Subject:* Re: XAdES Support and the Revised OPC [formerly "DR 11-0030:
> Proposal"]
>
>
>
> Francis,
>
>
>
> XML DSig 1.1 discourages or deprecates some features of DSig 1.0.
>
> However, in my understanding, any digital signature conformant to
>
> DSig 1.0 is also conformant to DSig 1.1. I said so to Tracie in Barcelona.
>
>
>
> I thus think that a normative ref to DSig 1.1 is good enough for
>
> "allow for both DigSig 1.0 and 1.1 in the text". If we normatively
>
> reference DSig 1.0, we will recommend SHA-1. I think that
>
> we shouldn't.
>
>
>
> Regards,
>
> Makoto
>
>
>
> 2016-05-05 20:45 GMT+09:00 Francis Cave <francis at franciscave.com>:
>
> My recollection accords with the meeting minutes. As I understand it,
> there is a consensus that we normatively need to allow for both versions of
> DSig, so that existing implementations (such as MSOFFCRYPTO) are still
> conformant, but we can also recommend use of the XAdES EN in an informative
> annex. I presume that what Murata-san means is that we are committed to
> introduce text into the OPC revisions that is in line with that consensus.
>
>
>
> Francis
>
>
>
>
>
>
>
> *From:* Rex Jaeschke [mailto:rex at RexJaeschke.com]
> *Sent:* 04 May 2016 20:03
> *To:* 'SC34' <e-SC34-WG4 at ecma-international.org>
> *Subject:* XAdES Support and the Revised OPC [formerly "DR 11-0030:
> Proposal"]
>
>
>
> Hi there Murata-san,
>
>
>
> Below, you wrote, “We are committed to the introduction of XAdES EN
> into the OPC revision.”
>
>
>
> I’m asking for clarification of this statement, so it is not
> misunderstood. At a glance, it seems to be making a broader claim that I
> thought WG4 had agreed to.
>
>
>
> From the Barcelona meeting minutes: “On Tuesday, in WG4 discussions: There
> was consensus that we should produce an informative annex describing a
> profile for XAdES appropriate for use with OPC, and allow for both DigSig
> 1.0 and 1.1 in the text.”
>
>
>
> When this was agreed to, it was my understanding that there would **not**
> be any mandatory normative text re XAdES in the new OPC spec. Instead, the
> informative profile would give directions as to how an implementation could
> support XAdES, if it chose to do so. Specifically, a conforming
> implementation of the next edition of 29500-2 need **not** provide any
> support for XAdES at all.
>
>
>
> Rex
>
>
>
>
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com <eb2mmrt at gmail.com>] *On
> Behalf Of *MURATA Makoto
> *Sent:* Saturday, April 30, 2016 10:41 AM
> *To:* SC34 <e-SC34-WG4 at ecma-international.org>
> *Subject:* DR 11-0030: Proposal
>
>
>
> *DR 11-0030* - OPC: Obsolete version of W3C XML Digital Signature 1.0
>
>
> https://skydrive.live.com/view.aspx/Public%20Documents/2011/DR-11-0030.docx?cid=c8ba0861dc5e4adc&sc=documents
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fskydrive.live.com%2fview.aspx%2fPublic%2520Documents%2f2011%2fDR-11-0030.docx%3fcid%3dc8ba0861dc5e4adc%26sc%3ddocuments&data=01%7c01%7cshawnv%40microsoft.com%7cbb6c001921a04da3a42808d38acedde6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=UUcpEtQBa0ZI0h6EkapdnpayPl95HI3iQ1W1K4lKoxs%3d>
>
>
>
> This DR requests a change in the normative reference of Part 2 §3 from
> XMLDSig 1.0 (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.w3.org%2fTR%2f2002%2fREC-xmldsig-core-20020212%2f&data=01%7c01%7cshawnv%40microsoft.com%7cbb6c001921a04da3a42808d38acedde6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Rghx4cXmTQxklEGXnVjC%2bIWq%2bBVls5luhfz4X4SyALQ%3d>)
> to XMLDSig 1.1 (http://www.w3.org/TR/xmldsig-core1/
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.w3.org%2fTR%2fxmldsig-core1%2f&data=01%7c01%7cshawnv%40microsoft.com%7cbb6c001921a04da3a42808d38acedde6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2b5ybHVsZ7nRtOqBmcTCVubcIjGy9P7zA7YZlUxGwcq8%3d>
> ).
>
>
>
> We are committed to the introduction of XAdES EN into
>
> the OPC revision. XAdES EN uses XML DSig 1.1
>
> rather than 1.0. I thus believe that we cannot stick
>
> to DSig 1.0.
>
>
>
> Regards,
> Makoto
>
>
>
>
>
> --
>
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto
>
>
>
>
>
> --
>
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto
>
--
Praying for the victims of the Japan Tohoku earthquake
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20160611/1c07100c/attachment-0001.html>
More information about the sc34wg4
mailing list