Subject: Re: [smime] [pkix] Research question: Witnessing by digital signature

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 11 Jun 2010 14:37:03 +0200

Jorge,

Since it is a topic more related to S/MIME, I copy the SMIME list and I suggest that the next message is no more sent to the PKIX list.

I agree that the current notion of signature policy should not be changed since it applies to a single electronic signature.

If you prepare a draft for an "extended policy" (the right wording still needs to be found), then I am interrested to read the draft.

The next question will then be: should this "formal" definition be done using XML or/and ASN.1 ? :-)

Denis

----- Message reçu ----- 
De : Jorge López 
À : Liaquat Khan 
Date : 2010-06-11, 14:24:30
Sujet : Re: [pkix] Research question: Witnessing by digital signature

Hi again Liaquat,

I agree with you that, in this context, generation and verification rules should be specified in a signature policy. The problem is that, currently, ETSI Signature Policy (or analog RFC 3125) cannot deal with multiple signatures. There is no way of binding one signature with another, neither when they are parallel/sequential nor embedded.  

In addition, verification procedures for a tree of signatures is not as simple as you may think. Among others, tree matching issues appear, and there is not simple algorithm for that, specially when nodes of the tree keep so much semantic information such as the certificate used, the signature policy to which they adhere, timing data, commitment type made, etc. The algorithm complexity is non-linear with the increase of the tree depth or tree width. 

IMHO, there were two possibilities: modifying/extending current definition of signature policy (under my viewpoint, not recommended at all), or proposing another extended policy to cope with these needs, and that could be easily integrated with the current one. The latter was my choice.

Kind regards,

Jorge.

2010/6/11 Liaquat Khan <[email-masked]>

Hi Jorge

You are correct with regards to this stage of PEPPOL, but this doesn’t mean it’s against using automated processes in future.  My main point was that regardless of manual or automated approach, the policy for how multiple signatures should be applied seems appropriate subject for the Signing Policy.   Putting this in a separate “policy” will just make things more complicated IMO as its yet another policy to process for the signature verification application. 

Regards
LK  

From: Jorge López [mailto:[email-masked]] 
Sent: 11 June 2010 14:26
To: Liaquat Khan
Cc: Pope, Nick; pkix; [email-masked]

Subject: Re: [pkix] Research question: Witnessing by digital signature

Dear Liaquat,

(sorry if I have missed some information) I have skim read document D1.1 Part 3: Signature Policies, and it seems that the Project uses ETSI Signature Policies, and that the "binding" between the multiple signatures (when needed) is made in human-readable documents rather than by means of automated processes. Am I right?

Jorge.

2010/6/11 Liaquat Khan <[email-masked]>
Note the large European project “PEPPOL” (Pan-European Public Procurement On-Line) considers multiple signature options as part of the Signature Policy.   It seems logical place to me.  

Regards
LK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jorge López
Sent: 11 June 2010 13:22
To: Pope, Nick
Cc: pkix; [email-masked]

Subject: Re: [pkix] Research question: Witnessing by digital signature

Mmm, not so sure about that. Current signature policy is already transaction/document oriented, as it establishes the requirements to be fulfilled for the generation and validation of the signature, but within the transaction scope. There are fields that specifically fix the business/transactional context. The necessity I mentioned is what happens when more than one signature is needed to complete the transaction.

Well, you could do that at document/application level, but the cumbersome is guaranteed. An extended signature policy, like the one proposed in the aforementioned paper, can fill that gap in a seamlessly manner, and not application-dependent one.

Regards,

Jorge.

2010/6/11 Pope, Nick <[email-masked]>
Denis,

With PDF's this is handled by producing a document template with the layout including the placement of signatures.  I think this is an issue for the document standards applying signatures not for signatures standards.

Nick
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: 11 June 2010 09:54
To: Jorge López; swilson
Cc: pkix
Subject: Re: [pkix] Research question: Witnessing by digital signature
Hi,

You are right: there is no signature policy standard or technical document that helped to establish the dependences and relationships among several signatures.

The current concept of "signature policy" applies to a single signature. 
If a document has multiple signatures, each one can be done under a different signature policy.

So the "missing" concept is a "document signature policy" (not to be confused with  a "signature policy") which would tell, 
how many electronic signatures are needed, which signature policies are acceptable for each one, whether they need to be parallel 
or embedded, which commitment types must be present, etc ...

This combination of criteria could be important and all these verifications are currently left to the application.
It is questionnable whether this should be standardized now or left to the application.

Denis

----- Message reçu ----- 
De : Jorge López 
À : Stephen Wilson 
Date : 2010-06-11, 10:17:44
Sujet : Re: [pkix] Research question: Witnessing by digital signature

Hi, 

Among other open issues, a technical one lies in the fact that currently there is no signature policy standard or technical document that helped to establish the dependences and relationships among several signatures to make them legally binding. It would be the scenario of a witness or notary, who must countersign a former signature to make the transaction effective. This limitation was pointed out by ETSI in a technical report published in 2003 [1]. To the best of my knowledge, little research has been done in this direction [2].

Regards,

[1] ETSI TR 102 045 - Electronic Signatures and Infrastructures (ESI); Signature policy for extended business model v1.1.1. European Telecommunications
Standards Institute (ETSI), March 2003
[2] Jorge L. Hernandez-Ardieta, Ana I. Gonzalez-Tablas, Benjamin Ramos and Arturo Ribagorda. Extended Electronic Signature Policies. 2nd ACM International Conference on Security of Information and Networks (SIN 2009), pp. 268--277, ACM Press. North Cyprus. 2009.

2010/6/10 Stephen Wilson <[email-masked]>

Has any work been done in PKIX or elsewhere on formal witnessing of digital signatures?  And/or ... does anyone in the group know of real life instances where a digital signature is witnesses and attested to using another dig sig? 
Cheers,

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

www.lockstep.com.au <http://www.lockstep.com.au>
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.  Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

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 2NX.
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 [email-masked]. 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".

---

From: Jorge López <[email-masked]>
Date: Fri, 11 Jun 2010 14:47:36 +0200

Denis,

Thanks for the interest. BTW, the paper can be a good starting point, where
I define the "extended policy" using ASN.1 notation. On the contrary, in my
doctoral thesis, I have carried out an implementation in XML.

I think that both definitions apply, since ETSI has delivered Signature
Policy definitions both in XML (ETSI 038) and ASN.1 (ETSI 272), and both
"XML-based and ASN.1 based transactions" should benefit from it.

However, and following IETF basis, I would suggest to prepare an I-D in
ASN.1 in the first instance.

Jorge.

2010/6/11 Denis Pinkas <[email-masked]>

>  Jorge,
>
> Since it is a topic more related to S/MIME, I copy the SMIME list and
> I suggest that the next message is no more sent to the PKIX list.
>
>  I agree that the current notion of signature policy should not be changed
> since it applies to a single electronic signature.
>
> If you prepare a draft for an "extended policy" (the right wording still
> needs to be found), then I am interrested to read the draft.
>
> *De :* Jorge López
> *À :* Liaquat Khan
> *Date :* 2010-06-11, 14:24:30
> *Sujet :* Re: [pkix] Research question: Witnessing by digital signature
>
>  Hi again Liaquat,
>
> I agree with you that, in this context, generation and verification rules
> should be specified in a signature policy. The problem is that, currently,
> ETSI Signature Policy (or analog RFC 3125) cannot deal with multiple
> signatures. There is no way of binding one signature with another, neither
> when they are parallel/sequential nor embedded.
>
> In addition, verification procedures for a tree of signatures is not as
> simple as you may think. Among others, tree matching issues appear, and
> there is not simple algorithm for that, specially when nodes of the tree
> keep so much semantic information such as the certificate used, the
> signature policy to which they adhere, timing data, commitment type made,
> etc. The algorithm complexity is non-linear with the increase of the tree
> depth or tree width.
>
> IMHO, there were two possibilities: modifying/extending current definition
> of signature policy (under my viewpoint, not recommended at all), or
> proposing another extended policy to cope with these needs, and that could
> be easily integrated with the current one. The latter was my choice.
>
> Kind regards,
>
> Jorge.
>
>> You are correct with regards to this stage of PEPPOL, but this doesn’t
>> mean it’s against using automated processes in future.  My main point was
>> that regardless of manual or automated approach, the policy for how multiple
>> signatures should be applied seems appropriate subject for the Signing
>> Policy.   Putting this in a separate “policy” will just make things more
>> complicated IMO as its yet another policy to process for the signature
>> verification application.
>>
>>
>>
>> Regards
>>
>> LK
>>
>>
>>
>>
>>
>>
>>
>> *From:* Jorge López [mailto:[email-masked]]
>> *Sent:* 11 June 2010 14:26
>> *To:* Liaquat Khan
>> *Cc:* Pope, Nick; pkix; [email-masked]
>>
>> *Subject:* Re: [pkix] Research question: Witnessing by digital signature
>>
>>
>>
>> Dear Liaquat,
>>
>>
>>
>> (sorry if I have missed some information) I have skim read document D1.1
>> Part 3: Signature Policies, and it seems that the Project uses ETSI
>> Signature Policies, and that the "binding" between the multiple signatures
>> (when needed) is made in human-readable documents rather than by means of
>> automated processes. Am I right?
>>
>>
>>
>> Jorge.
>>
>>
>>
>> 2010/6/11 Liaquat Khan <[email-masked]<[email-masked]>
>> >
>>
>> Note the large European project “PEPPOL” (Pan-European Public Procurement
>> On-Line) considers multiple signature options as part of the Signature
>> Policy.   It seems logical place to me.
>>
>>
>>
>> Regards
>>
>> LK
>>
>>
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Jorge López
>> *Sent:* 11 June 2010 13:22
>> *To:* Pope, Nick
>> *Cc:* pkix; [email-masked]
>>
>>
>> *Subject:* Re: [pkix] Research question: Witnessing by digital signature
>>
>>
>>
>> Mmm, not so sure about that. Current signature policy is already
>> transaction/document oriented, as it establishes the requirements to be
>> fulfilled for the generation and validation of the signature, but within the
>> transaction scope. There are fields that specifically fix the
>> business/transactional context. The necessity I mentioned is what happens
>> when more than one signature is needed to complete the transaction.
>>
>>
>>
>> Well, you could do that at document/application level, but the cumbersome
>> is guaranteed. An extended signature policy, like the one proposed in the
>> aforementioned paper, can fill that gap in a seamlessly manner, and not
>> application-dependent one.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Jorge.
>>
>>
>>
>> With PDF's this is handled by producing a document template with the
>> layout including the placement of signatures.  I think this is an issue for
>> the document standards applying signatures not for signatures standards.
>>
>>
>>
>> Nick
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
>> Of *Denis Pinkas
>> *Sent:* 11 June 2010 09:54
>> *To:* Jorge López; swilson
>> *Cc:* pkix
>> *Subject:* Re: [pkix] Research question: Witnessing by digital signature
>>
>> Hi,
>>
>>
>>
>> You are right: there is no signature policy standard or technical document
>> that helped to establish the dependences and relationships among several
>> signatures.
>>
>>
>>
>> So the "missing" concept is a "document signature policy" (not to be
>> confused with  a "signature policy") which would tell,
>> how many electronic signatures are needed, which signature policies are
>> acceptable for each one, whether they need to be parallel
>> This combination of criteria could be important and all these
>> verifications are currently left to the application.
>>
>> *De :* Jorge López
>> *À :* Stephen Wilson
>> *Date :* 2010-06-11, 10:17:44
>>
>> *Sujet :* Re: [pkix] Research question: Witnessing by digital signature
>>
>>
>>
>> Hi,
>>
>>
>>
>> Among other open issues, a technical one lies in the fact that currently
>> there is no signature policy standard or technical document that helped to
>> establish the dependences and relationships among several signatures to make
>> them legally binding. It would be the scenario of a witness or notary, who
>> must countersign a former signature to make the transaction
>> effective. This limitation was pointed out by ETSI in a technical
>> report published in 2003 [1]. To the best of my knowledge, little research
>> has been done in this direction [2].
>>
>>
>>
>> Regards,
>>
>>
>>
>> [1] ETSI TR 102 045 - Electronic Signatures and Infrastructures (ESI);
>> Signature policy for extended business model v1.1.1. European
>> Telecommunications
>>
>> [2] Jorge L. Hernandez-Ardieta, Ana I. Gonzalez-Tablas, Benjamin Ramos and
>> Arturo Ribagorda. Extended Electronic Signature Policies. 2nd ACM
>> International Conference on Security of Information and Networks (SIN 2009),
>> pp. 268--277, ACM Press. North Cyprus. 2009.
>>
>>
>>
>> Has any work been done in PKIX or elsewhere on formal witnessing of
>> digital signatures?  And/or ... does anyone in the group know of real life
>> instances where a digital signature is witnesses and attested to using
>> another dig sig?
>> Cheers,
>>
>> Stephen Wilson
>> Managing Director
>> Lockstep Group
>>
>> Phone +61 (0)414 488 851
>>
>> *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 2NX.*
>>
>> *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
>> [email-masked]. 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".*
>>
>>
>>
>>
>>
>
>