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


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

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

Subject: RE: [dss-x] Suggested addition to DSS Core - Estimate CMS Signature Size


Interesting issue.  Could be difficult to predict size 100% as certificate
lengths can change if just about to roll over to a new key.

I am not sure about the added complexity of this function warrants the gain
in efficiency as probably most of the overhead will be in collecting the
information used to build the signature rather than calculating the
signature value itself.  Though I am not totally against this.

One the organisation of such sundry additions to the Core - I would suggest
that this be placed in a profile (either specific to PDF signing or a
general profile for "sundry" optional features.


> -----Original Message-----
> From: Uri Resnitzky [mailto:Uri@arx.com]
> Sent: 13 August 2007 12:19
> To: dss-x@lists.oasis-open.org
> Subject: [dss-x] Suggested addition to DSS Core - Estimate CMS Signature
> Size
> Hello all,
> Applications that use detached CMS signatures and embed the signature
> bytes into the signed document (such as in PDF signing) need to know
> what is the expected size of the CMS signature *before* they can
> calculate the document hash value.
> The reason is that the file format sometimes specify that the length of
> the embedded signature object affects the content of the rest of the
> document is relation to data headers, offset tables, etc, and the hash
> calculation must cover that data as well.
> Client applications can not assume a fixed value for the size of the CMS
> signature since they may need to sign with different certificates each
> time and only the server knows its own policies regarding including
> certificate chains, CRLs and other variable size objects as
> authenticated or un-authenticated attributes of the CMS signature.
> One solution would be to sign such documents twice - use a dummy hash
> value in the first signature and use the returned length of the
> signature object to format the document and calculate the real hash
> value and then sign again.
> This kind of solution has many obvious drawbacks, so I suggest we add an
> optional input that allows the client to ask the server *not* to perform
> the signature calculation, but only to return in an optional output an
> estimation of the size of the resulting signature object that would have
> been returned if the signature calculation was actually made using all
> the input parameters.
> The requirement from the server should be to make sure that the returned
> size is at least equal or greater than the actual size of the signature
> that would be calculated.
> Thanks,
> - Uri
> Uri Resnitzky
> Chief Scientists, ARX
> http://www.arx.com
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email postmaster@thales-esecurity.com.
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 

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