<div dir="ltr">I wrote:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">Q3: Should we introduce a new value for<br> ds:Reference/@Type?  (My two cents: Yes)<br><br></blockquote>But this is mistaken.  Both the new and legacy <br>versions of XAdES use<br><a href="http://uri.etsi.org/01903#SignedProperties">http://uri.etsi.org/01903#SignedProperties</a>  <br>We have to use it.<div><div><br></div><div>John left a comment on 12.6 (Generating Signatures) amd 12.7</div><div>(Validating Signatures) on his draft text for incorporating XAdES.</div><div>His comment is:</div><div>  </div><div>      Does anything need to change here for XAdES?</div><div><br></div><div>Meanwhile, the new version of XAdES clearly says (in the Scope):</div><div><br></div><div>  Procedures for creation and validation of XAdES </div><div>  digital signatures are out of scope and specified in EN 319 102</div><div><br></div><div>So, the incorporation of XAdES does not require any changes to these</div><div>clauses.</div></div><div><br></div><div>Regards,</div><div>Makoto</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-01 9:16 GMT+09:00 MURATA Makoto <span dir="ltr"><<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Dear colleagues,</div><div><br></div><div>I reported the result of the Seattle meeting to XAdES</div><div>experts in Japan.  They are happy to hear that SC34 and</div><div>ETSI are likely to work together.  I spoke with Kimura-san</div><div>and find that another committee in ETSI become a liaison of</div><div>another JTC1 committee recently by submitting a document to</div><div>JTC1.  I sent that document to Juan and requested his</div><div>committee to submit it to JTC1.</div><div><br></div><div>I believe that we should use the upcoming version of XAdES</div><div>(319 132-1 [1] and 132-2 [2]) rather than the current</div><div>version (101 903) as a basis of our OPC revision.  It uses</div><div>a new namespaces for many of the existing elements.  Thus,</div><div>data conforming to XAdES 101 903 (such as exisiting</div><div>OFF-CRYPTO XAdES) will never conform to XAdES 319 132.</div><div><br></div><div>One of the issues in XAdES 101 903 is that the</div><div>relationships among conformance levels is very unclear.</div><div>XAdES 319 132 is much better than that.  It now makes clear</div><div>which conformnace level requires which element in Annexes.</div></div><div><br></div><div>But what should our spec look like?  Here are some questions.</div><div><br></div><div>Q1: Shoulld we reference both 319 132-1 and 132-2?  (My two cents: Yes)</div><div><br></div><div>Q2: Should we introduce a new value  for Object/@Id?  (My two cents: No)</div><div><br></div><div>Q3: Should we introduce a new value for ds:Reference/@Type?  (My two cents: Yes)</div><div><br></div><div>Q4: Should we introduce some additional requirements on XAdES by </div><div>    eliminating some options?  (I have no ideas here.)</div><div><br></div><div>Regards,</div><div>Makoto</div><div><br></div><div>[1] <a href="http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN-319132-1v009-XAdES-BuildingBlocksAndBaselineSignatures-STABLE-DRAFT.pdf" target="_blank">http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN-319132-1v009-XAdES-BuildingBlocksAndBaselineSignatures-STABLE-DRAFT.pdf</a></div><div>[2] <a href="http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN-319132-2v009-XAdES-ExtendedSignatures-STABLE-DRAFT.pdf" target="_blank">http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN-319132-2v009-XAdES-ExtendedSignatures-STABLE-DRAFT.pdf</a></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</div>