<div dir="ltr"><span style="color:rgb(80,0,80);font-size:14.3999996185303px">Miyachi-san (an attendee of the Kyoto meeting) agrees that </span><div><span style="color:rgb(80,0,80);font-size:14.3999996185303px">idXAdESReferenceObject is not needed in OPC V2.  We </span><br></div><div><span style="color:rgb(80,0,80);font-size:14.3999996185303px">rely on SignedInfo instead.</span></div><div><span style="color:rgb(80,0,80);font-size:14.3999996185303px"><br></span></div><div><span style="color:rgb(80,0,80);font-size:14.3999996185303px">Regards,</span></div><div><span style="color:rgb(80,0,80);font-size:14.3999996185303px">Makoto</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-16 5:19 GMT+09:00 John Haug <span dir="ltr"><<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I nearly forgot, I compared the XAdES-specific requirements in MS-OFFCRYPTO and those we looked at last year in ODF (ODF 1.2 Part 3, section 5.3).  Here is what
 I found.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">SignedSignatureProperties > SigningCertificate -- in BOTH<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">SigningTime – “should” in ODF, “MUST” in OFFCRYPTO<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">EncapsulatedTimeStamp (DER-encoded ASN.1) -- in BOTH<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">CompleteCertificateRefs/CompleteRevocationRefs -- in OFFCRYPTO only<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">SigAndRefsTimestamp for refs to validation data -- in BOTH<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">CertificateValues/RevocationValues -- in OFFCRYPTO only<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Reference element for digest of SignedProperties<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">-- ODF: child of SignedInfo<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">-- OFFCRYPTO: child of SignedInfo (preferred) or Object > Manifest (with id=”idXAdESReferenceObject”)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">They’re pretty similar, MS-OFFCRYPTO has slightly tighter requirements.  So, no notable differences between the two that we would need to research.  The XAdES
 requirements we’ll want to add to Part 2 look fairly well known to the industry.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<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"> John Haug [mailto:<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>]
<br>
<b>Sent:</b> Thursday, January 15, 2015 12:05 PM<br>
<b>To:</b> MURATA, Makoto (<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>); SC34<br>
<b>Subject:</b> RE: XAdES elements in OFF-CRYPTO of Microsoft<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Do you know what the basis is for thinking –C and –X are mandatory?  I assume he’s looking at the 5^th and 6^th bullets under 2.5.2.6 in MS-OFFCRYPTO. 
 I read these as conditionals – if you use validation data, then you must do it this way.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">(1) Are there alternate ways to specify references to validation data other than as specified in XAdES 7.4 (and 4.4/4.4.3, which say signatures with validation
 data are –T and –C.)?  If so, the 5^th bullet is just requiring one way where a choice exists.  If not and XAdES-C is the only way, the 5^th bullet seems to just restate what XAdES-C requires.  I don’t see other ways and I might read that
 bullet as precluding use of XAdES-T, which I’m sure is the wrong interpretation.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">(2) Are there alternate ways to specify time stamps on references to validation data?  It seems so: SigAndRefsTimeStamp and RefsOnlyTimeStamp.  In this case,
 MS-OFFCRYPTO appears to be simply requiring the use of one method where an option exists for implementers.  The mandate here appears to be use of XAdES-X type 1 and not XAdES type 2 if you use XAdES-X.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal">Furthemore, as agreed in Kyoto, we should allow EPES/BES, T, X-L, and A.<br>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Yes.  As reference for today’s call, here are my relevant notes from our discussion and decisions at the Kyoto meeting.<u></u><u></u></span></p>
<p class="MsoNormal" style="vertical-align:middle"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:black">What to specify<u></u><u></u></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Anything re: grace period?  NO - for implementers, not for file format.<u></u><u></u></span></li><li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Which parts/relationships must/must not be signed? Part 2 does not currently say anything to this effect.  NO - for implementers, based on user scenario.<u></u><u></u></span></li><li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Additional restrictions a la ODF? (for interoperability)  NEEDS RESEARCH<u></u><u></u></span></li><li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Other restrictions? (disallow less useful levels?)</span>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span>
<ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">e.g., BES/EPES plus ISO profile<u></u><u></u></span></li><li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Don't mandate/prohibit, give guidance - normative SHOULD or informative NOTE<u></u><u></u></span></li></ul>
</li><li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Does OPC require signing a relationship that targets a part that is signed?  Don't think so (relationships can be signed, but not required).  Should this be mandated?  NO.<u></u><u></u></span></li><li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">RenewedDigests - mention this?</span>
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><u></u><u></u></span>
<ul style="margin-top:0in" type="circle">
<li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Can reference new ETSI std once published (expected within the next year)<u></u><u></u></span></li><li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Should only contain this addition since 1.4.2 (minor bug fixes from 1.4.1)<u></u><u></u></span></li><li class="MsoNormal" style="color:black;vertical-align:middle">
<span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Double-check for any changes, including namespace (all existing features should be in old namespaces, only new features in new ones)<u></u><u></u></span></li></ul>
</li></ul>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></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">
<a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a> [<a href="mailto:eb2mmrt@gmail.com" target="_blank">mailto:eb2mmrt@gmail.com</a>]
<b>On Behalf Of </b>MURATA Makoto<br>
<b>Sent:</b> Thursday, January 15, 2015 5:20 AM<br>
<b>To:</b> SC34<br>
<b>Subject:</b> Re: XAdES elements in OFF-CRYPTO of Microsoft<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Miyachi-san believes that the quoted paragraphs <br>
allow five leveles of XAdES (EPES, T, C, X, X-L)<br>
and mandate C and X.  He thinks <br>
that tjhey should be optional.<br>
<br>
Furthemore, as agreed in Kyoto, we should allow <br>
EPES/BES, T, X-L, and A.<br>
<br>
Regards,<br>
Makoto<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">2014-12-27 18:21 GMT+09:00 MURATA Makoto <<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>>:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Dear colleagues,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">We have already agreed not to introduce <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">SignatureInfoV1.  The rest of XAdES elements <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">in OFF-CRYPTO is described in the following <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">subsection.  We probably have to tweak this <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">subsection since we would like to allow all <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">conformance levels of XAdES.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Regards,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Makoto<u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br>
2.5.2.6 XAdES Elements<br>
<br>
XML Advanced Electronic Signatures [XAdES]<br>
extensions to xmldsig signatures MAY<32> be present<br>
in either binary or ECMA-376 documents [ECMA-376]<br>
when using xmldsig signatures. XAdES-EPES through<br>
XAdES-X-L extensions are specified within a<br>
signature. Unless otherwise specified, any optional<br>
elements as specified in [XAdES] are ignored.  The<br>
Object element containing the information as<br>
specified in [XAdES] has a number of optional<br>
elements, and many of the elements have more than<br>
one method specified. A document compliant with this<br>
file format uses the following options:<br>
<br>
- The SignedSignatureProperties element MUST contain<br>
  a SigningCertificate property as specified in<br>
  [XAdES] section 7.2.2.<br>
<br>
- A SigningTime element MUST be present as specified<br>
  in [XAdES] section 7.2.1.<br>
<br>
- A SignaturePolicyIdentifier element MUST be<br>
  present as specified in [XAdES] section 7.2.3.<br>
<br>
- If the information as specified in [XAdES]<br>
  contains a time stamp as specified by the<br>
  requirements for XAdES-T, the time stamp<br>
  information MUST be specified as an<br>
  EncapsulatedTimeStamp element containing DER<br>
  encoded ASN.1. data.<br>
<br>
- If the information as specified in [XAdES]<br>
  contains references to validation data, the<br>
  certificates used in the certificate chain, except<br>
  for the signing certificate (1), MUST be contained<br>
  within the CompleteCertificateRefs element as<br>
  specified in [XAdES] section 7.4.1. In addition,<br>
  for the signature to be considered a well-formed<br>
  XAdES-C signature, a CompleteRevocationRefs<br>
  element MUST be present, as specified in [XAdES]<br>
  section 7.4.2.<br>
<br>
- If the information as specified in [XAdES]<br>
  contains time stamps on references to validation<br>
  data, the SigAndRefsTimestamp element as specified<br>
  in [XAdES] section 7.5.1 and [XAdES] section<br>
  7.5.1.1 MUST be used. The SigAndRefsTimestamp<br>
  element MUST specify the time stamp information as<br>
  an EncapsulatedTimeStamp element containing DER<br>
  encoded ASN.1. data.<br>
<br>
- If the information as specified in [XAdES]<br>
  contains properties for data validation values,<br>
  the CertificateValues and RevocationValues<br>
  elements MUST be constructed as specified in<br>
  [XAdES] section 7.6.1 and [XAdES] section<br>
  7.6.2. Except for the signing certificate (1), all<br>
  certificates used in the validation chain MUST be<br>
  entered into the CertificateValues element.<br>
<br>
There MUST be a Reference element specifying the<br>
digest of the SignedProperties element, as specified<br>
in [XAdES], section 6.2.1. A Reference element is<br>
placed in one of two parent elements, as specified<br>
in [XMLDSig]:<br>
<br>
- The SignedInfo element of the top-level Signature<br>
  XML.<br>
<br>
- A Manifest element contained within an Object<br>
  element.<br>
<br>
A document compliant with this file format<br>
SHOULD<33> place the Reference element specifying<br>
the digest of the SignedProperties element within<br>
the SignedInfo element. If the Reference element is<br>
instead placed in a Manifest element, the containing<br>
Object element MUST have an id attribute set to<br>
"idXAdESReferenceObject".<u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<p class="MsoNormal"><br>
Praying for the victims of the Japan Tohoku earthquake<br>
<br>
Makoto<u></u><u></u></p>
</div>
</div>
</div></div></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>