Japanese position on the introduction of XAdES to OPC.

[MURATA Makoto]

Please look at the page "State transitions of the XAdES profiles" in
Lecture_on_XAdES_20140923.pdf in WG4 N 289 (in 2014).  It was used in
Kyoto.

http://isotc.iso.org/livelink/livelink?func=ll&objId=16821707&objAction=Open

It clearly shows that XAdES-X-L (and XAdES-A) can be created from
XAdES-T.  It is not required to create XAdES-C before creating
XAdES-X-L.  In other words, XAdES-X-L signatures WITHOUT REFERENCES TO
VALIDATION DATA are perfectly legitimate XAdES signatures.  However,
JNSA experts believe that MS Office reports such signatures as errors.
If the upcoming revision explicitly allows the use of the current
version of XAdES, it will disallow this behaviour thus making MS
Office non-conformant.

I understand why this misinterpretation happened.  The existing XAdES
specifications are extremely unclear about the relationship of
conformance levels.  However, those who are involved in XAdES
implementations (and interoperability testing) agree that XAdES-X-L
signatures without references to validation data are perfectly
legitimate.

You wrote: "I believe Microsoft Office supports all except -A."
What does Microsoft Office do when it receives XAdES-A?  Does
it report an error?

Regards,
Makoto

2015-06-06 5:39 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:

>  I had to dig back through old mail with the security folks who worked on
> this years ago.  If this is related to the question about “validation data”
> and MS-OFFCRYPTO seemingly requiring –C and disallowing –T, I’m told that’s
> not the intent.  OPC should allow whatever XAdES levels it defines;
> applications can choose whether to support various levels based on their
> needs and industry adoption.  I believe Microsoft Office supports all
> except -A.
>
>
>
> John
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Saturday, May 30, 2015 1:48 AM
> *To:* John Haug
> *Cc:* e-SC34-WG4 at ecma-international.org
> *Subject:* Re: Japanese position on the introduction of XAdES to OPC.
>
>
>
>
>
>
>
> 2015-05-29 3:21 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:
>
>  > Then, we will have two sets of conventions: Microsoft XAdES and the
> revised OPC.  They are unlikely to be identical.
>
> I think this is the crux of what we need to figure out in detail.  My
> impression is that XAdES hasn’t changed terribly in its markup details,
> which would allow OPC to make restricting statements that would apply
> equally to current and upcoming XAdES.  I may be wrong.  Though if the
> differences are minor, we may simply note something like: for TS 101 903:
> foo, and for EN 319 132: bar.  We have a proposed set of requirements based
> on TS 101 903 in a draft we looked at in Bellevue, very similar to both
> MS-OFFCRYPTO and ODF 1.2, which we could evaluate against the latest draft
> of EN 319 132 to get a better idea of this.
>
>
>
> The conventions on the use of the current XAdES, if standardized
>
> as part of the OPC revision, would allow XAdES-A as well as -L/-X-L
> without
>
> -C.   (This is the right thing to do.)  But how does  Microsoft Office as
> of now
>
>  handle them?
>
>
>
> JNSA experts believe that Microsoft Office cannot handle -L/-X-L without
> -C.
>
> In other words, standardizing the conventions on the use of the
>
> current XAdES may make Microsoft Office non-conformant.
>
>
>
> Regards,
>
> Makoto
>
>
>
>
>
>
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150606/fd878908/attachment.html>