OPC revision on top of XAdES 319 132-1 and -2

[John Haug]

OK, I misinterpreted what you were getting at, then.  Yes, I agree.  In fact, to your B1 point, I think we can and should add OPC-specific conventions for use of XAdES in general, applying to both existing and upcoming versions.  So I think we’re in rough agreement and not far off from where we started with the brief draft new text for additional requirements when using XAdES in OPC.

John

From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: Wednesday, April 8, 2015 6:28 AM
To: SC34
Subject: Re: OPC revision on top of XAdES 319 132-1 and -2



2015-04-08 8:04 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com<mailto:johnhaug at exchange.microsoft.com>>:
> It uses a new namespaces for many of the existing elements.  Thus,
data conforming to XAdES 101 903 (such as exisiting
OFF-CRYPTO XAdES) will never conform to XAdES 319 132.

This is a good point to raise.  Do we want to preclude the existing in-market XAdES from being used in OPC?

The use of  the existing XAdES as described in OFF-CRYPTO is certainly
allowed by OPC, since OFF-CRYPTO takes advantages of extension points
of OPC (e.g., the Object element).  When we revise OPC, we should continue
to provide these extension points and continue to allow the use of the existing
XAdES as described in OFF-CRYPTO.


I think that may not be a good idea.  At this point, the new XAdES is still a draft and will take some years to be approved by EU member states plus quite some years to possibly be adopted by industry.  I can see allowing for the possibility of the new version, but I don’t think we ought to prevent the current method from being used, even though it does have shortcomings addressed by the new version.  I think any OPC-specific requirements we add can be specified in a manner that is XAdES version agnostic.  For example, the ones in the draft text we looked at in Bellevue that were based on MS-OFFCRYPTO and ODF.  I think the normative references could allow both XAdES.  This is a good topic for broader discussion.

We have to distinguish two things: (A) the use of XAdES is allowed, and
(B) conventions for using XAdES are standardized.  To do (A), we only
have to provide extension points.  To do (B), we have to reference XAdES
specs and introduce normative sentences.

I think that we need (A1) and (B1) shown below:

   (A1) the use of the existing XAdES is allowed,

   (B1) conventions for using the upcoming XAdES are standardized

Does this sound reasonable?

Regards,
Makoto

John

From: eb2mmrt at gmail.com<mailto:eb2mmrt at gmail.com> [mailto:eb2mmrt at gmail.com<mailto:eb2mmrt at gmail.com>] On Behalf Of MURATA Makoto
Sent: Saturday, April 4, 2015 6:30 AM
To: SC34
Subject: Re: OPC revision on top of XAdES 319 132-1 and -2

I wrote:

Q3: Should we introduce a new value for
ds:Reference/@Type?  (My two cents: Yes)
But this is mistaken.  Both the new and legacy
versions of XAdES use
http://uri.etsi.org/01903#SignedProperties
We have to use it.

John left a comment on 12.6 (Generating Signatures) amd 12.7
(Validating Signatures) on his draft text for incorporating XAdES.
His comment is:

      Does anything need to change here for XAdES?

Meanwhile, the new version of XAdES clearly says (in the Scope):

  Procedures for creation and validation of XAdES
  digital signatures are out of scope and specified in EN 319 102

So, the incorporation of XAdES does not require any changes to these
clauses.

Regards,
Makoto

2015-04-01 9:16 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp<mailto:eb2m-mrt at asahi-net.or.jp>>:
Dear colleagues,

I reported the result of the Seattle meeting to XAdES
experts in Japan.  They are happy to hear that SC34 and
ETSI are likely to work together.  I spoke with Kimura-san
and find that another committee in ETSI become a liaison of
another JTC1 committee recently by submitting a document to
JTC1.  I sent that document to Juan and requested his
committee to submit it to JTC1.

I believe that we should use the upcoming version of XAdES
(319 132-1 [1] and 132-2 [2]) rather than the current
version (101 903) as a basis of our OPC revision.  It uses
a new namespaces for many of the existing elements.  Thus,
data conforming to XAdES 101 903 (such as exisiting
OFF-CRYPTO XAdES) will never conform to XAdES 319 132.

One of the issues in XAdES 101 903 is that the
relationships among conformance levels is very unclear.
XAdES 319 132 is much better than that.  It now makes clear
which conformnace level requires which element in Annexes.

But what should our spec look like?  Here are some questions.

Q1: Shoulld we reference both 319 132-1 and 132-2?  (My two cents: Yes)

Q2: Should we introduce a new value  for Object/@Id?  (My two cents: No)

Q3: Should we introduce a new value for ds:Reference/@Type?  (My two cents: Yes)

Q4: Should we introduce some additional requirements on XAdES by
    eliminating some options?  (I have no ideas here.)

Regards,
Makoto

[1] http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN-319132-1v009-XAdES-BuildingBlocksAndBaselineSignatures-STABLE-DRAFT.pdf
[2] http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN-319132-2v009-XAdES-ExtendedSignatures-STABLE-DRAFT.pdf



--

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/20150408/399c1bf5/attachment-0001.html>