<div dir="ltr"><div>Rich,</div><div><br></div><div>> This seems like a re-hash of the same conversation we had in Prague.</div><div><br></div><div>We did discuss this DR in Prague. We did not close it, but we agreed</div><div>on three bullets:</div><div><br></div><div>> 1. Revise §13.2.4.1 to make it truly an informative summary (as is,</div><div>> it’s too detailed). Move any normative content out to the</div><div>> appropriate element subclause following.</div><div>> 2. Review §13.2.4.* removing elements for which no constraints are</div><div>> added (i.e.; don’t restate anything available from the other spec).</div><div>> 3. We decided not to say more about the unspecified elements;</div><div>> specifically, we don’t want to say they are disallowed. Our</div><div>> understanding is that any elements that are not specifically</div><div>> disallowed are allowed.</div><div><br></div><div>#3 is the point here. The minutes shows that our understanding is</div><div>"any elements that are not specifically disallowed are allowed".</div><div>Thus, anything not mentioned is allowed. I guess that it differs from</div><div>your interpretation, quoted below:</div><div><br></div><div>>being proscriptive about what might be disallowed would seem to</div><div>>stifle any attempts at the evolution or innovation my implementers</div><div>>trying to use this. I would rather say something is “not supported”</div><div>>than disallowed.</div><div><br></div><div>We did not decide to say "not supported". What we agreed is, in your</div><div>words, proscriptive. It is true that the default is "allow" and we do</div><div>not have a lot of explicit restrictions. This implies that conformant</div><div>implementations are expected to support all features unless explicitly</div><div>forbidden.</div><div><br></div><div>Let me state my general concern about the way OPC digital signature is</div><div>current presented.</div><div><br></div><div>After I came back to Japan, the Japanese local mirror had a meeting.</div><div>A XAdES expert would like to have more proscriptive wording. He said</div><div>that he had to do a lot of reverse engineering rather than simply</div><div>relying on the wording of OPC and OFF-CRYPTO. For example, neither</div><div>specs show which OPC part is singed by MS Office. The first thing he</div><div>had to do is reverse engineering for finding the targets of digital</div><div>signatures. But he rather would like OOXML to precisely define which</div><div>OPC part is signed and which is not signed.</div><div><br></div><div>Microsoft Office is not the only program that generates OOXML</div><div>containing digital signatures. The advent of XADES EN</div><div>is likely to encourage other programs to create OOXML with</div><div>XAdES from OOXML without XAdES. Such programs are certainly</div><div>good, as they provide secure OOXML. I can imagine that some </div><div>security policies require such programs. </div><div><br></div><div>If different parties support different OPC parts and different DSig</div><div>elements, the result will be poor interoperability. In other words,</div><div>conformant data created by some conformant applications will be</div><div>rejected by other conformant applications.</div><div><br></div><div>In reality, it is hard to provide interoperability without a reference</div><div>implementation. But we should try to (1) precisely define permissible</div><div>data and their semantics and to (2) ensure interoperability of</div><div>conformant implementations. If we forget (2), we can simply allow</div><div>any part to be signed or not signed, allow any element of DSig 1.0 and</div><div>1.1, and allow any feature of XAdES. But how can we then achieve</div><div>interoperability?</div><div><br></div><div>Digital signature is particularly underspecified in OOXML. Let alone</div><div>XAdES. What is more, existing corpus of OOXML documents are not rich</div><div>enough to "define" OOXML digital signatures. Our wording in OPC (and</div><div>possibly future amendments to Parts 1 and 4) has to precisely define</div><div>them.</div><div><br></div><div>> On your second issue regarding examples…. Do we always include</div><div>> examples, or are you just asking for an examples for this specific</div><div>> case? If so, your sentence seems incomplete as to what you’re</div><div>> requesting. “We do not even have examples, which shows which</div><div>> elements of DSig 1.0 is currently.” Is currently what? Are you</div><div>> asking for examples of each element of DSig 1.0? A set of examples?</div><div><br></div><div>I am asking for more active particpation of experts of digital</div><div>signatures. As I see it, WG4 does not have enough expertise</div><div>for providing an interoperable standard for the interchange of</div><div>digitally signed OOXML. Not being an expert of digital</div><div>signatures or XAdES, I have always felt at a loss. OCP disallows </div><div>some features (e.g., transformations other than canonicalization</div><div>transform and relationships transform) of DSig 1.0, </div><div>even when they (e.g., <ds:Transform element Algorithm=</div><div>"<a href="http://uri.etsi.org/01903/v1.3.2/SignaturePolicy/SPDocDigestAsInSpecification">http://uri.etsi.org/01903/v1.3.2/SignaturePolicy/SPDocDigestAsInSpecification</a>")</div><div>are allowed in XAdES EN. But why are they disallowed? </div><div>I mentioned examples simply because they would allow non-experts</div><div>to have better ideas.</div><div><br></div><div>Regards,</div><div>Makoto </div><div><br></div><div><div class="gmail_extra">
</div></div></div>