OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Two JIRA Issues for discussion


On 2 March 2010 20:04,  <robert_weir@us.ibm.com> wrote:
> We currently say:
>
> "Note: Applications may use extensions to the [xmldsig-core]
> specification, such as those required
> for implementation of XAdES signatures specified in ETSI TS 101 903 v1.3.2
> [XAdES]."
>
> And [XAdES] is a non-normative reference.
>
> Do we really want to say "Applications _should_ use extensions to the
> [xmldsig-core] specification..." ?  That sounds odd to me.  Surely the
> user, not the implementation should decide.
>
> Maybe we  want something like (in conformance terms) "A Conforming
> OpenDocument Package Consumer should support  XAdES signatures specified
> in ETSI TS 101 903 v1.3.2 [XAdES]" ?  (Could do the same on producer
> conformance.)

As one of the drafters of this original wording regarding XAdES
(together with Jomar Silva) I am happy to enough to see this
rewording.  We both at the time would have liked some stronger wording
but felt this was the least controversial to get in.  The govt of
Brazil really requires XAdES and it was important to specify that this
is indeed supported.  Not that it was ever precluded.  To say that
consumers (and possibly producers) *should* support XAdES is maybe
better but let us also be careful not to lose the sense that producers
*may* also use other extensions so long as they remain within the
bounds of what is permitted by XMLDsig.

Regards
Bob

> Note that if we make a provision recommending or requiring use of XAdES we
> also should move [XAdES] into the normative references section.
>
> I'm not expressing an opinion one way or another on this change.  I'm just
> trying to clarify the intended language.
>
> Rob
>
>
>
> Cherie Ekholm <cheriee@exchange.microsoft.com> wrote on 03/02/2010
> 02:36:26 PM:
>
>>
>> I don't remember Bart's suggestion for strengthening the wording on
>> XaDeS use having been discussed yet, though we did talk about the
>> RNG schema in the TC meeting two weeks ago.
>>
>> Over the last 6th months or more there has been an increasing
>> interest in not only XaDeS, but the other ETSI dig sig work as well.
>> The next version of the main PDF standard (ISO 32000-2) as well as
>> the newest PDF/A version (ISO 19005-2) both include support for
>> PaDes. While 32000-2 isn't expected to publish until sometime in
>> 2011, 19005-2 has gone out for DIS vote and will likely be published
>> sometime in fall 2010.
>>
>> Changing from a may to a should in ODF 1.2 seems like a small but
>> important way that we can acknowledge in the increasing push for XaDeS.
>>
>> Cherie
>>
>> -----Original Message-----
>> From: Hanssens Bart [mailto:Bart.Hanssens@fedict.be]
>> Sent: Friday, February 19, 2010 12:28 PM
>> To: dennis.hamilton@acm.org; 'Dave Pawson'; 'Patrick Durusau'
>> Cc: 'Michael Brauer - Sun Germany - ham02 - Hamburg';
>> office@lists.oasis-open.org
>> Subject: RE: [office] Two JIRA Issues for discussion
>>
>>
>> And emphasize XAdES (ETSI TS 101 903)
>> (1.2 part 3 mentions it briefly in a note, "may implement", I'd
>> rather make that a "should")
>>
>> At least in Europe, governments really want to have XAdES implemented
>> (and we're issuing millions of eID cards for filling out tax forms
>> and legally sign documents)
>>
>>
>> Best regards,
>>
>> Bart
>>
>> ________________________________________
>> From: Dennis E. Hamilton [dennis.hamilton@acm.org]
>> Sent: Friday, February 19, 2010 9:06 PM
>> To: 'Dave Pawson'; 'Patrick Durusau'
>> Cc: 'Michael Brauer - Sun Germany - ham02 - Hamburg';
>> office@lists.oasis-open.org
>> Subject: RE: [office] Two JIRA Issues for discussion
>>
>> My sense of this is that we have done something very strange.
>>
>> In Part 3, there is a standalone RNG schema for an XML document that
>> has an ODF Dsigs list as its root element.  The only element in the
>> content of this root element is one more W3Cdsig:dsig elements (that
>> is, W3C XML DSigs).
>>
>> Because the trivial root element is specified in RNG, we have the
>> problem that we have chosen to have no schema for the W3Cdsig:dsig
>> XML element, and we allow any content on that element instead.  (And
>> it is done in an ugly way, but I won't go into that.  I will point
>> out that IS 29500 offers both Relax NG and XML Schema schemas and
>> they seem to have found some sort of transliteration that preserves
>> the schematic essence in both directions.)
>>
>> Clearly, a way to have a precise specification would be to have this
>> trivial standalone XML document schema be done in XML Schema in the
>> first place.  Then it can incorporate W3Cdsig:dsig by reference to
>> the XML Schema for it.
>>
>> Alternatively, get rid of the multi-signature wrapper (not sure what
>> value it is since any number of separate signature files are
>> permitted and a component of the multi-signature wrapper will have a
>> hard time self-signing without screwing something up), and simply
>> allow dsig:dsig (W3C dsig binding) root elements on the ODF 1.2 Part
>> 3 digital signature documents.
>>
>> Short-term problem solved either way.  Choose your poison.
>>
>> There is a lot more needed to have ODF 1.2 DSig be well-specified.
>> With the schema resolved, we might turn our attention to that more
>> substantial matter of how XML Dsig is profiled for ODF 1.2.  (The
>> original proposal accepted by the ODF TC over a year ago is somehow
>> not reflected in ODF 1.2 Part 3 and ODF 1.2 Part 1 anywhere.  There
>> was a lot more profiling of XML DSig that someone thought was
>> important, and that the TC accepted, and now it is nowhere to be seen.)
>>
>>  - Dennis
>>
>> <rant>
>>
>> The fact that someone wants to do fancy tooling so they can verify
>> document packages in some automatic way should not be a detriment to
>> producing a quality specification.  We don't prescribe
>> implementations and we don't tell consumers how schemas are to be
>> used to assess the validity of the packages they attempt to accept.
>>
>> A more interesting challenge is how smart tooling will deal with
>> URIs in the dsig:dsig element that need to refer to the other
>> Package files in the same package, and have that make sense without
>> custom tooling.  I don't see how that is possible, so custom work is
>> required no matter what.  Also, the production of the digital
>> signature files is clearly a custom job and at the moment, can't be
>> schema driven at all without someone cooking up one of their own
>> that works with whatever schema-following DOM they want to use.
>>
>> </rant>
>>
>> -----Original Message-----
>> From: Dave Pawson [mailto:dave.pawson@gmail.com]
>> Sent: Friday, February 19, 2010 08:37
>> To: Patrick Durusau
>> Cc: Michael Brauer - Sun Germany - ham02 - Hamburg;
>> office@lists.oasis-open.org
>> Subject: Re: [office] Two JIRA Issues for discussion
>>
>> On 19 February 2010 16:19, Patrick Durusau <patrick@durusau.net> wrote:
>> > Michael,
>> >
>> > Switching the schema is a big step but I assume that there are tools
> to
>> > measure formal equivalence of schemas?
>> >
>> > I haven't looked, therefore the question.
>> >
>> > If there were some assurance other than "eye balling" the two schemas,
> I
>> > would feel more confident about a last minute change.
>>
>> Trang, from James Clark, helps, but has no guarantees.
>> rng is currently a superset of XSD, so rng to XSD is not always
>> possible.
>>
>> Yes, you'd have to check a lot of the schema before you trusted
>> your conversion.
>>
>> HTH
>>
>>
>>
>> --
>> Dave Pawson
>> XSLT XSL-FO FAQ.
>> Docbook FAQ.
>> http://www.dpawson.co.uk
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]