XAdES EN: Avoiding catch 22

[MURATA Makoto]

Dear colleagues,

In the WG4 Seattle meeting, we thought that the
introduction of XAdES EN signatures will make
existing MS Office crash or silently discard
XAdES EN signatures.

I have thought about this and made some experiments.
I think that I now find a solution.  Attached please find an
example demonstrating my ideas.

https://1drv.ms/w/s!An5Z79wj5AZBgfBNAVSC3OxAZAOuLA


1. What the revised OPC should do

Introduce a new relationship type for the latest XAdES EN signatures.

Recommend the use of *BOTH* XAdES EN and existing XAdES signatures for
interoperability with existing OOXML applications.

Note: Existing MS Office documents containing XAdES signatures are
continue to be conformant.

2. Design of future MS Office

Signature Creation:

Always generate both existing XSdES signatures and XAdES EN
signatures.

Signature Validation:

When XAdES EN signatures are present, validate XAdES EN signatures and
ignore existing XSdES signatures (if any).

When XAdES EN signatures are absent, validate existing XSdES
signatures (if any).

3. Behaviours of existing MS Office

How can avoid the catch 22 situation as discussed in Seattle?

Since XAdES EN signatures are protected by new relationship types,
existing MS Office will not try to parse them.  It will handle
existing XAdES signatures successfully.  It will not crash.

Since documents containing XAdES EN signatures always contain existing
XAdES signatures, existing MS Office will handle such documents as
signed documents.  In other words, it will not modify such documents
unless users agreee to discard signatures.  Thus, no signatures are
broken unless users discard them.

In fact, the attached document contain

<Relationship Id="rIdE" Type="http://schemas.openxmlformats.org/package/
2006/relationships/digital-signature/signature/XAdES EN"
Target="sig1Enhanced.xml"/>

as a relationship from origin.sigs.  Note that the relationship type is new.
The content of sig1Enhanced.xml is obviously non-conformant, but MS Office
2016
does not crash.

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