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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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


Subject: Re: [oiic-formation-discuss] List of ODF interop issues that need to be addressed -- Electronic signatures


On Wed, Jul 2, 2008 at 4:48 AM,  <robert_weir@us.ibm.com> wrote:
>
> "Hurley, Garry \(L&I - OIT\)" <ghurley@state.pa.us> wrote on 07/01/2008
> 02:18:16 PM:
>
>> I think that before we add in the requirement for digital signatures
>> to be preserved/included, we need to have a standard definition of
>> what an electronic signature is.  Is it a digital image of a written
>> signature, a 64-bit key, a 128-bit key, a 1024-bit key, or just a 4-
>> bit key?  Different applications will recognize different levels of
>> security and "electronic signatures" until a standard definition is
>> decided upon.  I would suggest that OASIS or some other standards
>> body may want to define, once and for all time, what is and is not
>> considered an "electronic signature" (a bit-length key should
>> specify only a minimum, to allow it to be expanded as time goes by
>> and as needed).
>>
>
> Key length is a sensitive issue, since some nations have restrictions on
> what they allow for use by private citizens, and some other nations have
> restrictions on what can be used in software that is exported.   The net
> result is that digital signature frameworks, like the W3C's Digital
> Signature standard (http://www.w3.org/TR/xmldsig-core/)allow for a variety
> of algorithms and key lengths.
>
> The above mentioned standard gives a few examples of what an XML digital
> signature looks like, e.g.:  http://www.w3.org/TR/xmldsig-core/#sec-o-Simple
>
> ODF 1.2 will include the use of W3C Digital Signatures.
>
> This is also an interesting area to look at for those who would forbid all
> ODF extensions.  In several cases, governments have extended the W3C's
> Digital Signature to add additional elements in their own name space.  These
> extensions are mandated by regulation or legislation.  Different countries
> have different requirements, and these requirements change at a quicker pace
> than standards change.   Do we forbid conforming ODF applications from
> fulfilling the mandatory requirements of these governments?  I assure you
> that those companies selling proprietary formats will have no hesitation
> meeting their customer's needs.
>
There are a few different ways around this problem.   Setting up
something like http://www.lanana.org/ for ODF.  So these additional
elements can be listed without going threw the full standard process
with complete documentation so passing the TC requirements to test.
Since they would be listed when the standard is updated these lists
could be looked at to see what is in need of being added.

Using something like lanana for it also removes compatibility issues.
 Governments using 5 different ODF programs don't want the 5 different
ODF programs doing there mandated requirements different either it
will annoy the hell out of them.  Like one program able to store the
information but not display it.   Another able to display bits of
there information.   Another keeps it but fails to update it when it
should have.  Another losses bits of the key.   And one that works
perfectly.  Simple drive them nuts and a compatibility failure and how
as a TC are we going to prevent this.

Stop thinking as a implementer rob.  You need to think from a
compatibility point of view really.  TC or Standard creator can run a
list of added keys.  I could see Governments even liking it.   Submit
what they want there and lots of ODF applications just pick it up and
have it even able to display it and interact with it correctly.  Even
better there ODF applications will be able to display other Countries
signatures correctly handy for inter Government operations.

There is simply no reason for undocumented anywhere.  If there is a
speed issue provide a high speed documenting process for particular
sections of ODF bypassing the long Standard process.  Less than 24
hours to get a extra key in ODF should be more than adequate in all
cases even 7 days could be fine too.  This still provides all
implementers with a far chance to make programs for those countries
requirements or any other added bit.  It also prevent conflit of two
parties using exactly the same names for different things or two
different parties creating extra keys to do exactly the same thing.

Peter Dolding


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