Re:RE: RE: Without breaking (formerly: The real crux... )

>  If we
> need to access or validate a particular PDF, we can use the 
> signature in the XML
> document, otherwise it is just part of the identifying information.

>I am still unclear as to the issue here. Either we have a 
>manifest that breaks down the huge document into components or
>we have one huge blob.

>Case A) We have a Manifest.
>        We can validate any component in the manifest that is
>        available to us. This is already supported.

>Case B)We have a huge chunk of data signed as a single unit.
>        We might as well store the signature with the BLOB in the
>        archive. The signature is of zero utility without the
>        accompanying data.

I agree that the signature is of zero utility without the accompanying data in
the end.  That doesn't mean the document and signature must be co-located.  Are
you saying they must be co-located, or am I misunderstanding your point?

>Clearly a document management system should be able to track two
>related documents (the BLOB and its signature) in the archive.

>I still don't see how that this creates any new requirements.

>Document management systems should support meta-data. That is a
>document management system requirement, not a dig sig requirement.
>signatures are only one of hundreds of types of Meta-data that
>the DMS should be able to manage.

Are you implying that nobody will ever by interested in developing an XML-based
DMS?  If they are developed, isn't it possible that they would require this dsig
support?

>> >You have to have the content for the signature to tell you anything. 
>> >A digital signature only has meaning if it has been verified.
>> 
>> Well, sort of.  My take is that checking the signature is 
>> optional (see above). 

>If you don't check the signature it tells you nothing. 

It's there if you need it.  Just because it is there, it doesn't mean we must
check it (dereference it) every time.  Digital signature is just one of the
pieces of information about the document.

>> It's there when you need it.  A good example of a detached 
>> signature is a time
>> stamp system.  You send a signature and get it officially time 
>> stamped to, for
>> example, help prove that you came up with an idea first.  The 
>> idea can remain
>> undisclosed until the "proof" is needed.

>The timestamp is a signature on a document. To give meaning to the 
>timestamp you need to read that document. That document also happens
>to be a signature on yet a third document. 

>You are right in pointing out that to give meaning to a timestamp 
>you don't have to derefference the entire chain of authenticated 
>data.

You are allowing these signatures to not be co-located with the content signed,
which indicates that I may be misunderstanding your point of view.  Also, the
application has the option of dereferencing and validating, but it doesn't have
to which seems to counter your argument that "If you don't check the signature
it tells you nothing."

>All this points to is that signatures have to be first class objects
>which is already a requirement.

>> Knowing that a signature "once existed" sounds pretty useless to 
>> me.  I don't
>> buy that this is the best that can be done.

>Actually this is what your timestamp is.

OK, I think we are in different contexts here.  If you are arguing that there is
no reason for detached signatures or detached documents, I suggest we agree to
disagree.  If I misunderstood, let me know.

Thanks,
Rich

Received on Wednesday, 8 December 1999 15:21:59 UTC