<div dir="ltr"><div class="gmail_signature">Folks,</div><div class="gmail_signature"><br></div><div class="gmail_signature">The Japanese mirror of SC34 (including <span tabindex="-1" id=":1ak.1" style="background:yellow">XAdES</span> people involved </div><div class="gmail_signature">in the <span tabindex="-1" id=":1ak.2" style="background:yellow">ETSI</span> committee) had a meeting yesterday.  Here is what I </div><div class="gmail_signature">learned.</div><div class="gmail_signature"><br></div><div class="gmail_signature">1) There are no mechanisms for distinguishing (a) signatures </div><div class="gmail_signature">conforming to the old version of <span tabindex="-1" id=":1ak.4" style="background:yellow">XAdES</span> data and (b) those </div><div class="gmail_signature">conforming to the new version of <span tabindex="-1" id=":1ak.5" style="background:yellow">XAdES</span>.</div><div class="gmail_signature"><br></div><div class="gmail_signature">2) Some optional data are mandated by the new version.  Thus, </div><div class="gmail_signature">signatures conforming to the old version are likely to be rejected </div><div class="gmail_signature">by new implementations.</div><div class="gmail_signature"><br></div><div class="gmail_signature">3) These optional data specify the media type and encoding of each </div><div class="gmail_signature">file to be signed.</div><div class="gmail_signature"><br></div><div class="gmail_signature">4) It is not clear whether these optional data are mandatory </div><div class="gmail_signature">even when manifests are used.  Since <span tabindex="-1" id=":1ak.6" style="background:yellow">OOXML</span> uses manifests,</div><div class="gmail_signature">we have to know the answer.</div><div class="gmail_signature"><br></div><div class="gmail_signature">5) Creation and validation of <span tabindex="-1" id=":1ak.7" style="background:yellow">XAdES</span> signatures are specified </div><div class="gmail_signature">by a separate spec <span tabindex="-1" id=":1ak.9" style="background:yellow">AeDS</span>.  Everybody thinks that <span tabindex="-1" id=":1ak.10" style="background:yellow">AeDS</span> is </div><div class="gmail_signature">very hard to understand.</div><div class="gmail_signature"><br></div><div class="gmail_signature">6) What should we do about our own description of signature </div><div class="gmail_signature">creation and validation?  It now references W3C XML <span tabindex="-1" id=":1ak.12" style="background:yellow">DSig</span>, </div><div class="gmail_signature">but does not reference <span tabindex="-1" id=":1ak.13" style="background:yellow">XAdES or <span tabindex="-1" id=":1ak.9" style="background:yellow">AeDS</span></span>.  We do not have to repeat </div><div class="gmail_signature">what is already stated elsewhere, but we do </div><div class="gmail_signature">have to specify our own requirements on our own constructs:</div><div class="gmail_signature">SignatureTime, RelationshipReference, and </div><div class="gmail_signature">RelationshipsGroupReference.</div><div class="gmail_signature"><br>Regards,<br><span tabindex="-1" id=":1ak.14" style="background:yellow">Makoto</span></div>
</div>