DR 11-0029

[MURATA Makoto]

Rich,

> This seems like a re-hash of the same conversation we had in Prague.

We did discuss this DR in Prague.  We did not close it, but we agreed
on three bullets:

> 1. Revise §13.2.4.1 to make it truly an informative summary (as is,
> it’s too detailed). Move any normative content out to the
> appropriate element subclause following.
> 2. Review §13.2.4.* removing elements for which no constraints are
> added (i.e.; don’t restate anything available from the other spec).
> 3. We decided not to say more about the unspecified elements;
> specifically, we don’t want to say they are disallowed. Our
> understanding is that any elements that are not specifically
> disallowed are allowed.

#3 is the point here.  The minutes shows that our understanding is
"any elements that are not specifically disallowed are allowed".
Thus, anything not mentioned is allowed.  I guess that it differs from
your interpretation, quoted below:

>being proscriptive about what might be disallowed would seem to
>stifle any attempts at the evolution or innovation my implementers
>trying to use this. I would rather say something is “not supported”
>than disallowed.

We did not decide to say "not supported".  What we agreed is, in your
words, proscriptive.  It is true that the default is "allow" and we do
not have a lot of explicit restrictions.  This implies that conformant
implementations are expected to support all features unless explicitly
forbidden.

Let me state my general concern about the way OPC digital signature is
current presented.

After I came back to Japan, the Japanese local mirror had a meeting.
A XAdES expert would like to have more proscriptive wording.  He said
that he had to do a lot of reverse engineering rather than simply
relying on the wording of OPC and OFF-CRYPTO.  For example, neither
specs show which OPC part is singed by MS Office. The first thing he
had to do is reverse engineering for finding the targets of digital
signatures.  But he rather would like OOXML to precisely define which
OPC part is signed and which is not signed.

Microsoft Office is not the only program that generates OOXML
containing  digital signatures.  The advent of XADES EN
is likely to encourage other programs to create OOXML with
XAdES from OOXML without XAdES.  Such programs are certainly
good, as they provide secure OOXML.  I can imagine that some
security policies require such programs.

If different parties support different OPC parts and different DSig
elements, the result will be poor interoperability.  In other words,
conformant data created by some conformant applications will be
rejected by other conformant applications.

In reality, it is hard to provide interoperability without a reference
implementation.  But we should try to (1) precisely define permissible
data and their semantics and to (2) ensure interoperability of
conformant implementations.  If we forget (2), we can simply allow
any part to be signed or not signed, allow any element of DSig 1.0 and
1.1, and allow any feature of XAdES.  But how can we then achieve
interoperability?

Digital signature is particularly underspecified in OOXML.  Let alone
XAdES.  What is more, existing corpus of OOXML documents are not rich
enough to "define" OOXML digital signatures.  Our wording in OPC (and
possibly future amendments to Parts 1 and 4) has to precisely define
them.

> On your second issue regarding examples…. Do we always include
> examples, or are you just asking for an examples for this specific
> case?  If so, your sentence seems incomplete as to what you’re
> requesting. “We do not even have examples, which shows which
> elements of DSig 1.0 is currently.”  Is currently what? Are you
> asking for examples of each element of DSig 1.0?  A set of examples?

I am asking for more active particpation of experts of digital
signatures.  As I see it, WG4 does not have enough expertise
for providing an interoperable standard for the interchange of
digitally signed OOXML.  Not being an expert of digital
signatures or XAdES, I have always felt at a loss.  OCP disallows
some features (e.g., transformations other than canonicalization
transform and relationships transform) of DSig 1.0,
even when they (e.g., <ds:Transform element Algorithm=
"
http://uri.etsi.org/01903/v1.3.2/SignaturePolicy/SPDocDigestAsInSpecification
")
are allowed in XAdES EN.  But why are they disallowed?
I mentioned examples simply because they would allow non-experts
to have better ideas.

Regards,
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20160728/aad24cad/attachment.html>