https://issues.apache.org/ooo/show_bug.cgi?id=122697

            Bug ID: 122697
        Issue Type: DEFECT
           Summary: Help on Managing Digital Signatures is Incorrect
           Product: General
           Version: AOO 3.4.1
          Hardware: All
                OS: All
            Status: CONFIRMED
          Severity: normal
          Priority: P3
         Component: help
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]

The embedded help for managing digital signatures is incorrect.

[Note: The same problem exists in LibreOffice embedded help, and has been
reported at https://bugs.freedesktop.org/show_bug.cgi?id=36970.  This version
is entirely my own contribution and is available as my contribution to anyone
by virtue of my previously-provided declaration.
  I am continuing any of my effort on this defect here because it provides
wider availability to the extend the same remedy is useful to LibreOffice and
anyone else as well.]

REPRODUCTION

[Done 2013-07-04 using embedded Help with Apache OpenOffice on Windows en-x86.]

 1. Open Apache OpenOffice Writer with a blank document (or just open to the
start page)
 2. Click Help and get LibreOffice embedded Help.
 3. In the Index, Search term tab, type "digital signatures"
 4. When the "digital signatures" term scrolls up, click the
"getting/managing/applying" subtopic.
 5. Read the Managing Certificates topic.  That is wrong.  Getting new root
certificates is something you can do.  It has nothing to do with having your
own private key certificate and how it ends up in a protected key store on your
machine.  
 6. The description about signed macros is also misleading.  It suggests that
there is no value to signing macros when the document is signed.  

DETAILS

Concerning Root Certificates versus Private Keys

Getting a new root certificate is something that an user can do.  However, that
has nothing to do with having a private key certificate and keeping that in a
protected key store.  That's what is needed to sign documents.

It is also true that a recipient of a signed object needs a trusted certificate
to verify the authenticity of the *public* key by which the signature is
verifiable.  That is a different part of the protocol and it is not addressed
on this page at all.

Independence of Macro Signatures from Document Signatures

Unless this is simply implemented horribly wrong, the signatures on embedded
macros should survive editing of the document so long as a signed macro is not
edited.  That's the point of having macros signed, so that they can be trusted
by people when they are found in documents and when they are reused too.  When
a signed document is edited, there is no reason to invalidate the
separately-created signatures on embedded macros that are not touched, whether
or not still used.

POSSIBLE REMEDIES

Concerning Root Certificates versus Private Keys

Short Term Fix: Simply remove that small section.

Longer Term Fix: Replace that section and the one about applying signatures
with something more generic and brief that links to appropriate documentation
elsewhere, perhaps on the Wiki.  Accounting for platform differences is
probably important and there needs to be more about the use of X.509 PKI and
what the end-to-end signing to verification situation is, with illustration of
signing in Apache OpenOffice and also verification of signatures in Apache
OpenOffice.

Concerning Macro Signatures versus Document Signatures

Short Term Fix: Restate how macro signatures provide independent verification
of authenticity and integrity of macros in both signed and unsigned documents.

Longer Term Fix: Address more about how to embed macros, how to sign embedded
macros, and how to handle signed macros in the local user profile as well as
extracting and embedding those, depending on what the implementation actually
supports.  Again, details should probably be on the wiki and might be version
dependent as well.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

Reply via email to