<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I suspect my position on this would be easily guessed, but I strongly disfavor updating OPC in a way that breaks backward compatibility. Even putting aside my
Microsoft hat representing the single largest installed base of implementations of OPC, whether that be Office or XPS (both the .xps file format and Windows print spool format which implement ECMA-388, which incorporates OPC by reference) or .NET Framework
(System.IO.Packaging) or Windows Presentation Framework/XAML – and there are other implementers – I’d have to argue the point that where software has adopted digital signatures based on XMLDSig and gone further, the existing XAdES specifications are what has
been adopted. We’d do a disservice to current implementers and to users of many current documents to create a discontinuity in compatibility.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I believe we are getting too far down into the details of whatever work ETSI is doing now or may do in the future to revise XAdES. There is risk I feel is inappropriate
to take on in requiring use of a new, unpublished/unapproved proposed standard that has no adoption by industry while ignoring one that does have at least some industry adoption. Regardless of considering which version to require, I don’t believe we need
to or should mandate one version or another – let implementers decide what level of security they need for their application. I assert that our interest from the perspective of 29500 is to provide requirements that improve interoperability among implementations
of OPC that use XMLDSig and XAdES. And I still believe we can do that with simple statements like we’ve looked at before, ones that just require this choice or that where XAdES provides options or leaves something as implementation-specific. Both the new
and existing versions of XAdES are backward-compatible extensions of XMLDSig, the fundamental underlying technology the use of which is an important choice to make for the standard, so the previous sentence should hold.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">>
</span>As you know, Japanese XAdES experts are unhappy with the MS implementation.<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I think this is in reference to Office writing out SignaturePolicyIdentifier elements that are empty or use SignaturePolicyImplied. Whether to allow that (which
is legal XAdES) is a question we can take up along with the context of other related standards and implementations (e.g., ODF and MS-OFFCRYPTO make no statement on these elements). Chris and I can raise those concerns with the development team here, but let’s
leave any individual concerns with Office’s particular implementation choices separate from what we choose to specify in the standard.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> eb2mmrt@gmail.com [mailto:eb2mmrt@gmail.com]
<b>On Behalf Of </b>MURATA Makoto<br>
<b>Sent:</b> Tuesday, May 26, 2015 8:02 PM<br>
<b>To:</b> SC34<br>
<b>Subject:</b> Japanese position on the introduction of XAdES to OPC.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">Dear colleagues,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This mail is to describe the Japanese position on the <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">introduction of XAdES to OPC. Japan believes that the <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ongoing revision of OPC (Open Packaging Conventions) <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">should use the first part of the new version of XAdES and<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">nothing else.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As we have discussed, there are two versions of XAdES. An existing<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">version of XAdES is documented in ETSI technical specifications, while<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">a new and incompatible version is expected to become ENs (European<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Standards) in one year.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The first version is already implemented by Microsoft Office. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">This means that, if we introduce this version of XAdES to OPC <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">as a standard, we will run the risk of making the current implementation<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">by Microsoft non-conformant. As you know, Japanese XAdES <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">experts are unhappy with the MS implementation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The latest version of XAdES consists of two specifications.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Apparently, Europe is committed to the first part. The second part <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">appears to be an alibi for not abandoning some<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">features of the old version.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Moreover, the first part does not use any external files. But the<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">second does. This means that if such external files exist in an OPC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">package, they look like orphans and will be thrown away by many<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">implementations including MS Office. To avoid this problem, we will<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">have to introduce relationship types. Japan does not think that the <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">second part has advantages significant enough for this additional effort.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Makoto<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>