Subject: RE: multiple digitale signatures

From: "Bland, Graham" <[email-masked]>
Date: Fri, 23 Feb 2001 11:17:21 -0000

Sonke,

> -----Original Message-----
> From: Sönke Maseberg [mailto:[email-masked]]
> Sent: 23 February 2001 10:14
> To: Bland, Graham
> Cc: [email-masked]
> Subject: Re: multiple digitale signatures
> 
> 
> Graham,
> 
> > 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!
> 
> That is exactly what we want to do: two independent signature 
> algorithms. Is one
> compromised, the other will work securely and is able to 
> repair the compromised
> one.
> 

What about my extension to two protocols and two Crypto Libraries to cover
the compromise of these?

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

In order to determine if it is possible I must have a bit more detail:

Please define Infocode, this is an OID that is interpreted by the software,
What is the software and what are the possible interpretations, if existing
software is to understand these codes then they must have predefined
meanings.  How does Infocode relate to the relevantID?

Does the use of freetext imply that the user is informed, can the user
influence anything or is this just a message to be displayed.  As this will
be permanently in the 

relevantID,  This identifies compromised components, I presume these would
be defined for all cryptographic algorithms with a range of key lengths and
protocols, presumably separate ones for any possible options would be needed
for example SSL with and without client authentication.  Who is going to be
responsible for allocating these OIDs?

newID identifies a new component, is this intended to instruct a system to
dynamically reconfigure itself? Again does the software have to understand
these OIDS, if so all possible new components must be predefined.

code, are you suggesting that this is the executable code to be used as the
new components referenced by newID or have I misread this completely.  If
this was intended to be the code then OS details etc are required as this
would be different for NT and Solaris systems.  All possible variants must
be included in the message

Once this extension has been sent what happens next, must it be permanently
left in place for any new users to read, is it removed after a period of
time or do all users acknowledge somehow that they have received it?
Certificates expire and can be removed from a CRL, these would never expire.

What happens if my system does not support RSA 4096 when this is mandated,
do I shut down?

Does this apply to other protocols, for example must I throw away all RSA
512 bit PGP keys when this is revoked within a PKI?

Graham

> Sönke
> 
> > 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
> >
> 
_______________________________________________________________________

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: [email-masked]
Date: Tue, 27 Feb 2001 13:40:29 +0100 (MET)

Graham,

>   What about my extension to two protocols and two Crypto Libraries to cover

If you want to regard also failures that occurs in protocols, a solution would 
be to use two protocols and two implementations as well. It's same paradigm.

But we look at the following failures only:
- compromise of signature algorithm
- compromise of keys or systemparameter

We suppose that protocols like PKCS#7 are secure. 

>   meanings.  How does Infocode relate to the relevantID?

Infocode is interpreted by the client software like mail client, so the client
knows what to do - e.g. delete, add or update of algorithms. Software that don't 
unterstand Infocode should ignore it. 

relevantID contains a list of application identifier of intended application
like a chipcard AID or an ID of the mail client.

>   influence anything or is this just a message to be displayed.

Depending on application and implementation I think the user should return
the following actions - analogous to virus scanner.

>   As this will be permanently in the 
IMO the CA knows the OID of the used signature algorithms of its Certificate
Holders.
But it's right, I have to add keylength to differ between the compromised
algorithm
and the new one.

>   these OIDS, if so all possible new components must be predefined.

Yes, the basis of the FlexiPKI is a flexible structure which allows the
exchange of signature algorithms separately

>   be included in the message

Yes, I think the CA stores the informations about the system requirements of its 
customers.
>   What happens if my system does not support RSA 4096 when this is mandated,

This is a proposal to distribute the new RSA 4096 software. But if your system
doesn't allow the exchange, you will do shut down - in the same manner as now.
>   512 bit PGP keys when this is revoked within a PKI?

If your certificate is revoked and you cannot work with it because the receiver
doesn't accept the signature: yes.

Best regards,
Soenke