Subject: RE: multiple digitale signatures

From: "Bland, Graham" <[email-masked]>
Date: Fri, 23 Feb 2001 08:23:12 -0000

Sonke,

Again as devils advocate, In the past protocols have also shown themselves
to have flaws which can be compromised, for example SSL V2 is no longer
recommended, should a protocol identifier and version be added to the list?

I is quite possible that some cryptographic implementations in both hardware
or software could be compromised, should these also be added to the list?

If we accept these risks and guard against them then obviously I cannot
trust a compromised protocol to report on its own compromise so logically I
must implement two different protocols simultaneously which both use
multiple algorithms which are independently passed through two separate
implementations!

I do not know current practice within for example Identrus on key lengths
but anybody correct me if I am wrong. The banks I am sure are not routinely
using 4096 bit RSA keys even though these are much stronger than 2048/1024
bits and are less likely to be broken.  The reason is that they have made a
trade off between cost and security.  Any system must be adequately secured
for the business purposes to which it is put. Any higher security than this
is an unnecessary expense, it just gets interesting when defining
'adequate'.

Anything which adds to the cost of a system, which this does by increasing
the complexity, must be justified by the value it adds. I do not believe it
does in this case.

I think we have two opposing views and must accept that. May I suggest that
if you are still not convinced then you ask the chair to put it to a vote.

Graham

-----Original Message-----
From: Sönke Maseberg [mailto:[email-masked]]
Sent: 22 February 2001 08:50
To: Bland, Graham
Cc: [email-masked]
Subject: Re: multiple digitale signatures

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

"Bland, Graham" schrieb:

> 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.
> _______________________________________________________________________
_______________________________________________________________________

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: Fri, 23 Feb 2001 11:14:10 +0100

Graham,

> multiple algorithms which are independently passed through two separate

That is exactly what we want to do: two independent signature algorithms. Is one
compromised, the other will work securly and is able to repair the compromised
one.

> the complexity, must be justified by the value it adds. I do not believe it

Yes, it is a question between cost and security. If the risks are known and
accepted then IMHO the companies will pay for it.

But again, do you mean that such an extension in CMP as I proposed would be
possible? I think on interoperational and migration matters: If a user system
receive a CMP PKIBody with tag [25] and cannot interpret it, the system will
reject this tag.

Sönke

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 23 Feb 2001 12:09:42 +0100

"Bland, Graham" wrote:

> The banks I am sure are not routinely
> bits and are less likely to be broken.

Are they ?

In the current state of technology and knowledge, you will need huge ressources
to break 1024 keys, but not huge enough to have the strong security margin that
would garanty there is no risk they will be broken within say 10 years.

Now if you take a key of 2048, this is doubling the length, this time the
ressources that you will need will be absolutely impressive, and clearly not
something that will be reached within a reasonnable time-frame.

If we are there to see a key size of 2048 broken, that quite probably will mean
someone has succeeded in proving the RSA algorythm to be much weaker than
believed currently, that he has found a method for resolution of RSA that
strongly lowers the complexity of the problem (complexity in the mathematical
meaning the increase of ressource needed to break a key with regard to the
increase of the key size) and _if_ there's such a fail in the RSA algorythm,
then even a 4096 key might not be that much more secure than a 2048.