Japanese position on the introduction of XAdES to OPC.

[MURATA Makoto]

The XAdES committee is now considering a big change
in XAdESENv111.xsd.  In my understanding, they
will make a decision before our F2F.

Regards,
Makoto


2015-05-30 0:55 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:

>  I was thinking that the different namespaces and named conformance
> levels could be abstracted away from the requirements.  For example, “if
> validation data is present…” or referencing an element without a
> namespace.  Both methods are used in MS-OFFCRYPTO and ODF.
>
> > begin with careful comparison of the upcoming XAdES and existing XAdES
>
> Yes, I agree.  I’m not as familiar with the upcoming XAdES and may or may
> not be right on my claims.  I will try to understand it better before
> London.  I found it more difficult to parse than the existing standard when
> I looked at it in the past…  Do you know if there is a newer version than
> 0.0.9 (link we received from Juan Carlos Cruellas after the Bellevue
> meeting)?
>
>
>
> John
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Thursday, May 28, 2015 4:06 PM
> *To:* e-SC34-WG4 at ecma-international.org
>
> *Subject:* Re: Japanese position on the introduction of XAdES to OPC.
>
>
>
> John,
>
>
>
> 2015-05-29 3:21 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:
>
> Hello –
>
>
>
> > Even if we introduce the new version of XAdES as part of the revision
> of OPC, the extension points will continue to be available.
>
> Perhaps I misunderstood, then.  I thought the position was to effectively
> prohibit use of the current XAdES and only allow use of the new upcoming
> version.  Even discouraging use of the existing one in favor of the
> upcoming one seems a bit much in my mind.  As long as OPC gives guidance on
> which choices to make when implementing XAdES, that should suffice for
> interoperability and leave flexibility to implementers to choose what they
> support, however good or bad an idea it is – i.e., no signature, plain
> XMLDSig, current XAdES, upcoming XAdES.
>
>
>
> Sure.  The upcoming OPC should not discourage the use of the existing
> XAdES.
>
>
>
>
>
> I may not be familiar enough with the details of the upcoming XAdES, but I
> think the small number of interop requirements that we might want to add to
> OPC apply equally to both the established and upcoming XAdES.  I think it
> can be done in a way that is agnostic to which edition of XAdES
> implementers choose.  I’m don’t think it’s quite right to think of a
> “Microsoft XAdES” as opposed to regular XAdES or XYZ Corp’s XAdES.  Our
> implementation is conformant XAdES and we simply publish a document
> containing information about the choices we made where XAdES allows
> flexibility so that others know what to expect in OOXML files generated by
> Office and what we didn’t implement support for in Office.
>
>
>
> Having seen the latest draft and schemas of the upcoming XAdES, I strongly
> think that we
>
> need different sets of requirements on the upcoming XAdES and the existing
> XAdES.
>
> For example, namespaces are different.  The schema XAdESENv111.xsd for the
> existing
>
> version and that for the upcoming version are different.  The number of
> conformance levels
>
> are different.  The organization of the specs are different: for example,
> level C (references
>
> to validation data) are moved to the second part of the upcoming XAdES.
>
>
>
> If we decide to implement one set of requirements for the upcoming XAdES
> and
>
> another for the existing XAdES, we will probably have to introduce
> different sets
>
> of relationships for the two XAdES.  They are for preserving seemingly
> orphan
>
> parts, which are referenced by XAdES by relative URIs.  If we do not allow
>
> the use of the second part of the upcoming XAdES, we do not need such
>
> relationships for the upcoming XAdES.  I am not completely sure but
>
> I think that the URI attribute in Include element of the existing XAdES
>
> requires such a relationship type.
>
>
>
>
>
> Given the above…
>
>
>
> > It means that a set of conventions on the use of the new version of
> XAdES will be established.  New applications based on the revised OPC will
> follow these conventions.
>
> I fully agree with the first sentence immediately above and think it
> applies to XAdES in general; or, slightly differently, to both the current
> and upcoming versions.  The second sentence could be taken to mean that use
> of the current XAdES is deprecated and implementations should use the
> upcoming one.  The upcoming one is so early in its life that I think this
> might be premature.  I may also be misinterpreting that second sentence and
> this isn’t what you intended.
>
>
>
> Let me try again.  New applications implementing the upcoming version of
> XAdES will follow these conventions.
>
>
>
> > 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.
>
>
>
> My impression is different.  Details of XAdES markup has changed a lot.
>
>
>
> Perhaps, the best way to go forward is to begin with careful comparison of
> the upcoming
>
> XAdES and existing XAdES.   I will prepare something by the F2F.
>
>
>
> Regards,
>
> Makoto
>
>
>
>
>
> John
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Wednesday, May 27, 2015 7:29 PM
> *To:* John Haug
> *Cc:* e-SC34-WG4 at ecma-international.org
> *Subject:* Re: Japanese position on the introduction of XAdES to OPC.
>
>
>
> John,
>
>
>
> I am afraid that I was not clear.  OPC as of now already provides
> extension points.
>
> They allow third parties to introduce legitimate extensions.  Microsoft
> XAdES is
>
> such a legitimate extension.
>
>
>
> Even if we introduce the new version of XAdES as part of the revision of
> OPC,
>
> the extension points will continue to be available.  Thus, Microsoft XAdES
>
> will continue to be a legitimate extension of OPC.   Implementations of
> such extensions will continue to  be conformant.  Backward compatibility
> will not be destroyed.
>
> Then, what does it mean to incorporate the new version of XAdES into
> the revision of OPC?   It means that a set of conventions on the use of
>
> the new version of XAdES will be established.  New applications
>
> based on the revised OPC will follow these conventions.
>
>
>
> If we incorporate the existing version of XAdES into the revision of
>
> OPC, we will establish a set of conventions on the use of
>
> the existing version of XAdES.  Then, we will have two
>
> sets of conventions: Microsoft XAdES and the revised OPC.  They
>
> are unlikely to be identical.  If they diverge, we will cause a lot
>
> of troubles to users and implementations.  I thus think that
>
> not incorporating the existing version of XAdES into the
>
> revised OPC is the best way to provide backward compatibility.
>
>
>
> Perhaps, one solution is to provide an informative note about
>
> the use of the existing XAdES in the OPC revision.  The note
>
> should say that such use IS conformant.
>
>
>
> Regards,
>
> Makoto
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2015-05-28 8:19 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:
>
>  I suspect my position on this would be easily guessed, but I strongly
> disfavor updating OPC in a way that breaks backward compatibility.  Even
> putting aside my Microsoft hat representing the single largest installed
> base of implementations of OPC, whether that be Office or XPS (both the
> .xps file format and Windows print spool format which implement ECMA-388,
> which incorporates OPC by reference) or .NET Framework
> (System.IO.Packaging) or Windows Presentation Framework/XAML – and there
> are other implementers – I’d have to argue the point that where software
> has adopted digital signatures based on XMLDSig and gone further, the
> existing XAdES specifications are what has been adopted.  We’d do a
> disservice to current implementers and to users of many current documents
> to create a discontinuity in compatibility.
>
>
>
> I believe we are getting too far down into the details of whatever work
> ETSI is doing now or may do in the future to revise XAdES.  There is risk I
> feel is inappropriate to take on in requiring use of a new,
> unpublished/unapproved proposed standard that has no adoption by industry
> while ignoring one that does have at least some industry adoption.
> Regardless of considering which version to require, I don’t believe we need
> to or should mandate one version or another – let implementers decide what
> level of security they need for their application.  I assert that our
> interest from the perspective of 29500 is to provide requirements that
> improve interoperability among implementations of OPC that use XMLDSig and
> XAdES.  And I still believe we can do that with simple statements like
> we’ve looked at before, ones that just require this choice or that where
> XAdES provides options or leaves something as implementation-specific.
> Both the new and existing versions of XAdES are backward-compatible
> extensions of XMLDSig, the fundamental underlying technology the use of
> which is an important choice to make for the standard, so the previous
> sentence should hold.
>
>
>
> > As you know, Japanese XAdES experts are unhappy with the MS
>  implementation.
>
> I think this is in reference to Office writing out
> SignaturePolicyIdentifier elements that are empty or use
> SignaturePolicyImplied.  Whether to allow that (which is legal XAdES) is a
> question we can take up along with the context of other related standards
> and implementations (e.g., ODF and MS-OFFCRYPTO make no statement on these
> elements).  Chris and I can raise those concerns with the development team
> here, but let’s leave any individual concerns with Office’s particular
> implementation choices separate from what we choose to specify in the
> standard.
>
>
>
> John
>
>
>
> *From:* eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] *On Behalf Of *MURATA
> Makoto
> *Sent:* Tuesday, May 26, 2015 8:02 PM
> *To:* SC34
> *Subject:* Japanese position on the introduction of XAdES to OPC.
>
>
>
> Dear colleagues,
>
>
>
> This mail is to describe the Japanese position on the
>
> introduction of XAdES to OPC.  Japan believes that the
>
> ongoing revision of OPC (Open Packaging Conventions)
>
> should use the first part of the new version of XAdES and
>
> nothing else.
>
>
>
> As we have discussed, there are two versions of XAdES.  An existing
>
> version of XAdES is documented in ETSI technical specifications, while
>
> a new and incompatible version is expected to become ENs (European
>
> Standards) in one year.
>
>
>
> The first version is already implemented by Microsoft Office.
>
> This means that, if we introduce this version of XAdES to OPC
>
> as a standard, we will run the risk of making the current implementation
>
> by Microsoft non-conformant.  As you know, Japanese XAdES
>
> experts are unhappy with the MS  implementation.
>
>
>
> The latest version of XAdES consists of two specifications.
>
> Apparently, Europe is committed to the first part.  The second part
>
> appears to be an alibi for not abandoning some
>
> features of the old version.
>
>
>
> Moreover, the first part does not use any external files.  But the
>
> second does.  This means that if such external files exist in an OPC
>
> package, they look like orphans and will be thrown away by many
>
> implementations including MS Office.  To avoid this problem, we will
>
> have to introduce relationship types.   Japan does not think that the
>
> second part has advantages significant enough for this additional effort.
>
>
>
>
>
>
>
> 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/20150530/df041aee/attachment-0001.html>