Re: Single Key in Originator Information

>Of course, this problem wouldn't exist if we weren't trying to express the
>signature in XML.  If the problem did exist, it would be in the underlying
>signature technology, and the signed XML group would not have created a
new
>security hole by trying to bundle new cryptographic techniques with the
>fundamental and different problem of signing XML.

Signing XML is not a fundamental and different problem.  We have many
worked examples to learn from like: X.410, X.509, PEM, MOSS, DNS Sec, SDSI,
SPKI, PGP, DMS, and DSig 1.0.

The originator information is an often overlooked problem in signature
standards.  For example, formal evaluation of a PGP signature is difficult
because PGP's web of trust does define a single evaluation path.  X.509
also has had similar problems with the attributes that reference the
issuer.  Mulitple evaluation paths were possible because the issuer name
did not guarentee unique identification of and issuer certificate.   Id
numbers consisting of a certificate hash were invented to solve this
problem.

So, hopefully we will be able learn from these past efforts.

Paul





"John Boyer" <jboyer@uwi.com> on 04/21/99 01:51:27 PM

To:   Paul Lambert/Certicom
cc:   "Dsig group" <w3c-xml-sig-ws@w3.org>
Subject:  Re: Single Key in Originator Information




Of course, this problem wouldn't exist if we weren't trying to express the
signature in XML.  If the problem did exist, it would be in the underlying
signature technology, and the signed XML group would not have created a new
security hole by trying to bundle new cryptographic techniques with the
fundamental and different problem of signing XML.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

-----Original Message-----
From: Paul Lambert <plambert@certicom.com>
To: reagle@w3.org <reagle@w3.org>
Cc: w3c-xml-sig-ws@w3.org <w3c-xml-sig-ws@w3.org>
Date: Wednesday, April 21, 1999 1:39 PM
Subject: Single Key in Originator Information


>
>Joseph,
>
>In your example from April 13 you have two keys represeted using
<rdf:Alt>:
>
>       <!-- The originator info and his keys -->
>       <dsig:OriginatorInfo rdf:resource="http://w3.org/Reagle/">
>         <dsig:keys>
>           <rdf:Alt>
>             <rdf:li rdf:parseType="Resource">
>               <dsig:key ID="X509" type="http://iso.org/x509"
>                         value="...308201F0308201B002010..."/>
>             </rdf:li>
>             <rdf:li rdf:parseType="Resource">
>               <dsig:key ID="PGP" type="http://pgp.com/pgp"
>                         value="...F3082010308201B002010..."/>
>             </rdf:li>
>          </rdf:Alt>
>        </dsig:keys>
>       </dsig:OriginatorInfo>
>
>The first key is carried in within a X.509 certificate.  The second key is
>carried in a PGP certificate.  I assume that you intend in this example
for
>both certificates to carry the same public key.
>
>Evaluation of this signature will  result in an ambiguos result.  The
>validation processing for X.509 is very different from PGP.  It is
possible
>for one certificate to be revoked and the signature invalid and the second
>certificate to be valid.
>
>Even if both alternatives were in the same format, the associated
>attributes would be different (or else they would be the same
certificate).
>Any variations in the certificate in name, validity period, key usage
>restrictions, or other attributes will effect the interpretation of the
>signature.  Allowing multiple alternatives for a key will allow create
>scenarios with ambiguos signature interpretations.
>
>This example  illustrates that a signing entity is more than just the
>public key.   The validation processing of a digital signature must
>consider all of the originator information carried with the public key.
>We should include only one starting point for this validation process.
>
>So, I propose that:
> XML digital signatures must carry only a single originator key or
>certificate.
>
>
>Paul
>
>
>
>

Received on Wednesday, 21 April 1999 18:04:40 UTC