Subject: RE: multiple digitale signatures

From: "Bland, Graham" <[email-masked]>
Date: Wed, 21 Feb 2001 14:08:43 -0000

Sonke,

I think we have a fundamental philosophical disagreement.
A CA is responsible for the certificates it issues only according to the
clauses it places in its CPS.  It does not necessarily know the business
purposes to which the certificates will be put For example there is a great
difference in my use of a certificate to sign a $100 million contract
opposed to its use to secure possibly embarrassing valentines emails to my
wife.
The CA does not know, has no interest in knowing and has no responsibility
for the use to which the certificate is put.  As such it is not a competent
agency to determine if it should revoke my certificate, it may only respond
to my request for revocation.

The other problem is that I just do not believe that when prudence is used
to select established algorithms that have been subject to review and
cryptanalysis such algorithms are suddenly compromised.  However even
established algorithms will become weaker over time due if nothing else but
Moores law.
While your model works in the first case which I believe will not happen, it
does not work in the second case which I know will.

Graham Bland

-----Original Message-----
From: Sönke Maseberg [mailto:[email-masked]]
Sent: 21 February 2001 10:03
To: [email-masked]; [email-masked]
Subject: RE: multiple digitale signatures

Graham,

we are working at the problems if a signature algorithm is compromised
suddenly without any time to change the algorithm parameters, keys oder
key lengths. IMO the CA is responsible for the certificates of the CHs.
If now a failure occurs, the shocked certificates have to be revoked.
The idea is to revoke the certificates not explicitly but implicitly
through the revocation of the used signature algorithms. The benefit
would be a shorter CRL, and the benefit grows up if many CHs are
involved.

I agree that for multiple digital signatures different signature
algorithms have to be used with independent components like hash
algorithm and independent basic mathematical problems. The use of
multiple digital signatures is optional in relation to the specific
application: In authentication applications it makes less sense. But the
signatures in e.g. e-government have to be proofable for many years.

Sönke

_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________

---

From: Sönke Maseberg <[email-masked]>
Date: Thu, 22 Feb 2001 09:49:51 +0100

I understand now the problems on revocation.

But I want to point out, that there is no signature algorithm that is proofable
secure. Yes, the established algorithms are analysed and they seem to be secure,
but we cannot exclude the sudden compromise of a signature algorithm. On the
other hand a lot of companies, banks or governments rely on PKI technologies.
What would happen if a failure occurs? The reason can also be an incorrect
implementation. E.g. think of Identrus - the worldwide PKI of some banks: What
would happen if Identrus doesn't work and the banks cannot communicate securely?

For this reason we want to build a flexible public key infrastructure which can
be used to exchange compomised components securely.

To support Standards of PKIX as well, we ask for some discussions about an
extension in CMP (PKIX - Certificate Management Protocols)
[<draft-ietf-pkix-rfc2510bis-02.txt>, November, 2000, Appendix F]:

     PKIBody  ::=  CHOICE  {
        ...
        compUpdate [25]  UpdateData,    -- Extension for Components Update
        }

     UpdateData  ::=  SEQUENCE  {
       infoCode    OBJECT IDENTIFIER,
       freeText    UTF8String                 OPTIONAL,
       relevantID  SET OF ApplicationIdentifier,
       newID       AlgorithmIdentifier        OPTIONAL,
       code        BIT STRING                 OPTIONAL
       }

UpdateData has the following meanings:
infoCode      a code that is interpreted by the software
freeText      readable text for the user
relevantID    Identifier of compromised components
newID         Identifier of new components
code          code of new components

Thanks in advance,
Sönke

---

From: jim <[email-masked]>
Date: Thu, 22 Feb 2001 10:52:28 -0500

Sonke,
    I am not sure what you mean by proofable secure.  Please clarify.  If you mean
that it is not by itself secure and therefore proof of its secureness cannot be
verified after the fact, then I do understand, but if you are saying that signatures
are inherently not able to provide proof of the authenticity of the signee, then
that is the reason that many CP and CPSs require the use of encryption any time
something is going to be signed.  In this manner, the encryption outer wrapping
protects the integrity of the signature providing proofability of the authenticity
of the signature.  IMHO, both have to be there.
Jim

---

From: Sönke Maseberg <[email-masked]>
Date: Fri, 23 Feb 2001 10:09:25 +0100

Jim,

what I mean by proofable secure signature algorithm is a mathematical proof for its
correctness. Please show me a signature algorithm and the mathematical proof that it is
not possible
- to calculate private key from knowledge of public key,
- to calculate private key from knowledge of public key and some signatures
- to calculate private key from knowledge of public key and some signatures with the
signed document,
- to generate a valid signature from other signatures or
- to change a document without change of the signature (compromise of the hashfunction)
IMHO there is only experience that the signature algorithms are suitable for signature
creation but no proof.

Sönke