pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pdf-devel] Crypt filter issue


From: gerel
Subject: Re: [pdf-devel] Crypt filter issue
Date: Mon, 24 Nov 2008 20:02:43 -0800 (PST)

 > Date: Mon, 24 Nov 2008 21:58:58 +0100
 > From: address@hidden
 > 
 > Hi David.
 > 
 >    I am writing crypt filter and it arises a doubt related to
 >    gnupdf's design. According to PDF Reference, encrpytion is defined
 >    (mostly) by a global dictionary. This dictionary holds a list of crypt
 >    filters will
 >    be used in the rest of the document.
 > 
 >    I suppose crypt filter module will receive parameters from its filter
 >    dictionary. However, it is not enought, it is even optional. We must
 >    consider global data, I think. Nevertheless these parameters will be
 >    known by upper layers.
 > 
 > There is not a 1-1 relationship between any PDF filter and a stm
 > filter, although it is common. Regardless the origin of the data we
 > should identify the needed stm filters that will allow us to implement
 > the processing of the higher-level PDF filters.
 > 

For that very reason and some points I mention below, my suggestion is to delay
the crypt filter implementation until we develop another upper-level encryption
module.
The points are,

        1. As read in section 7.6.1 encryption algorithms (8 counting the
           public-key one) and encryption filters are complex enough that they
           should impose us an upper layer module to deal with them. (keep in
           mind that "encryption filter" and "crypt filter" refer to different
           things, the former related to file "security handlers")
        2. As read in section 7.6.5 crypt filter were introduced to provide
           finer granularity control over the PDF document. IMHO that means that
           the crypt filters should be implemented upon the assumptions of the
           new module suggested in the previous item. But that doesn't mean that
           in our architecture the crypt filter should be implemented _on top_
           of that new module, i.e. there is a semantic dependency rather than
           structural one, this due to the crypt filter concept on itself.

Just an opinion,

-gerel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]