Japanese position on the introduction of XAdES to OPC.

[MURATA Makoto]

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

>
>
> Having re-read TS 101 903 and MS-OFFCRYPTO and the JNSA presentations,
> it’s possible that any implementer confusion about -XL might stem
> specifically from the text of B.2, which states that it builds on -X.  In
> its entirety:
>
> Extended long electronic signatures with time (XAdES-X-L) forms in
> accordance with the present document build up
>
> on XAdES-X types 1 or 2 by adding the CertificateValues and RevocationValues
> unsigned properties
>
> aforementioned.
>
>
>

Right.  What XAdES experts say is completely different from what I
interpret from the text
you quoted from the existing XAdES spec.  But what they say is based on
XAdES
interoperability testing in a world-wide basis.

Regards,
Makoto

 The structure for the most complete XAdES-X-L, built on the most complete
> XAdES-X signature, is shown below.
>
>
>
> Now to continue trying to make sense of 101 903 vs. 319 132.
>
>
>
> John
>
>
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Friday, June 5, 2015 3:35 PM
>
> *To:* e-SC34-WG4 at ecma-international.org
> *Subject:* Re: Japanese position on the introduction of XAdES to OPC.
>
>
>
> John,
>
>
>
> 2015-06-06 7:14 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:
>
>  It would be handy to have a set of OOXML files with various levels of
> XAdES signatures…
>
>
>
>
>
> Agreed.  But JNSA is not sure if making the existing XAdES as a
> first-class citizen
>
> (i.e., conformance without relying on extension points) rather than a
> second-class
>
> citizen (i.e., conformance bases on extension points) has enough
> advantages for
>
> justifying the cost for preparing such a set of OOXML files and studying
> the
>
> behaviour of MS Office.   After all, EU will not care the existing XAdES.
> It will care
>
> the upcoming XAdES, which is backed by eIDAS.
>
>
>
>  > However, JNSA experts believe that MS Office reports such signatures
> as errors.
>
> That may be, I don’t know – I have no files to test or check with the
> security team.
>
> > disallow this behaviour thus making MS Office non-conformant
>
> Not so much non-conformant as simply not supporting a particular level,
> no?  I don’t think there is a requirement to support all levels of XAdES.
>
>
>
>
>
> XAdES-X-L without references to validation data and that with references
> to validation data are both
>
> XAdES-X-L.  If you support XAdES-X-L, you have to handle both of them
> correctly.
>
>
>
>  I’m not sure what Office does with a -A signature – I’ve never seen a
> file with one.  I *suspect* anytime it runs into a signature it can’t parse
> (either due to an error in the signature markup or finding markup it
> doesn’t understand), it warns the user that the signature is invalid.
>
>
>
> Regards,
>
> Makoto
>
>
>
>
>
>
>
> John
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Friday, June 5, 2015 2:48 PM
> *To:* e-SC34-WG4 at ecma-international.org
>
>
> *Subject:* Re: Japanese position on the introduction of XAdES to OPC.
>
>
>
> 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
>
>
>
>
>
> --
>
>
> Praying for the victims of the Japan Tohoku earthquake
>
> 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/612ae6c6/attachment-0001.html>