[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]