|
Re: [smime] [pkix] Research question: Witnessing by digital signature
2010-06-11 10:08:34
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 <denis(_dot_)pinkas(_at_)bull(_dot_)net>
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 <liaquat(_dot_)khan(_at_)ascertia(_dot_)com>
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:jlopez(_dot_)ha(_at_)gmail(_dot_)com]
*Sent:* 11 June 2010 14:26
*To:* Liaquat Khan
*Cc:* Pope, Nick; pkix; denis(_dot_)pinkas(_at_)bull(_dot_)net
*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
<liaquat(_dot_)khan(_at_)ascertia(_dot_)com<liaquat(_dot_)(_dot_)khan(_at_)ascertia(_dot_)com>
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:* pkix-bounces(_at_)ietf(_dot_)org
[mailto:pkix-bounces(_at_)ietf(_dot_)org] *On Behalf
Of *Jorge López
*Sent:* 11 June 2010 13:22
*To:* Pope, Nick
*Cc:* pkix; denis(_dot_)pinkas(_at_)bull(_dot_)net
*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 <Nick(_dot_)Pope(_at_)thales-esecurity(_dot_)com>
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:* pkix-bounces(_at_)ietf(_dot_)org
[mailto:pkix-bounces(_at_)ietf(_dot_)org] *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 <swilson(_at_)lockstep(_dot_)com(_dot_)au>
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
pkix(_at_)ietf(_dot_)org
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
postmaster(_at_)thales-esecurity(_dot_)com(_dot_) 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".*
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime
|
|