Re: Authentication vs. binding signature, and ephemeral vs.permanent key usage

Petra,

I tried to follow the exchanges but they are going rather fast. I picked
your message from yesterday and will use it to reply.

> Stefan,
 
> I completely agree that we need a common understanding how to use the
> DS and the NR bit. So I'd like to express my understanding of both bits.
 
> As far as I can tell from all the comments on this list the DS bit
> should be used for unconscious signatures (session-oriented
> authentication applications, e.g. SSL/TLS-like protocols) and the
> NR bit should be used for conscious signatures (binding signatures,
> long-term signatures).

Correct.
 
> But I think this definition is not correct. The DS bit is not restricted
> to session-oriented authentication. 

No, it is restricted. The text says:

      The digitalSignature bit is asserted when the subject public key
      is used with a digital signature mechanism to support security
      services other than non-repudiation (bit 1), certificate signing
      (bit 5), or revocation information signing (bit 6). Digital signa-
      ture mechanisms are often used for entity authentication and data
      origin authentication with integrity.

      The nonRepudiation bit is asserted when the subject public key is
      used to verify digital signatures used to provide a non-
      repudiation service which protects against the signing entity
      falsely denying some action, excluding certificate or CRL signing.

> The DS bit has to be set in a
> certificate used for integrity of an object and authenticity of
> the originator, i.e. for digital signatures in general - no matter
> whether the signing act happens conscious or unconscious and automatic.
> For example to (consciously) sign my email I don't necessarily need to
> have the NR bit set, but I need the DS bit set in my certificate.
> 
> NonRepudiation is a service provided by my CA by issuing and archiving
> my certificate. 

No. I would disagree. The CA may do so, but is not in any way obliged to
do so, just because the NR bit is set.

> So if a CA issues a certificate containig the NR bit
> it indicates that the certificate and any other information about the
> certificate holder will be archived and will remain available in the
> future beyond certificate expiration.

This conclusion is based on a wrong assumption, and so is also wrong.
:-(

> So it's like a regular and a golden credit card: The DS certificate is
> the regular and the NR certificate the golden credit card with extra
> services and additional costs.
> Signatures with a NR certificate will be regarded as more trustworthy
> than signatures with only the DS bit set. Some applications might even
> require a NR certificate.

I do not follow you on this track.
 
> Now the question still remains whether the NR bit has to be set
> exclusivly or combined with the DS bit.

Yes. This is the question. More precisely: can a certificate have both
bits set, and in such a case what are the implications?

Note: when a single bit is set, there is no problem.

> In my opinion nonRepudiation services require the integrity
> of the message and authenticity of the originator, both provided by the
> digital signature. 

No. Much more than that, e.g. to be sure about the time of the signature
(hence the use of a TSA is a way to address this concern) and to
validate the path against the policy under which the signature was
affixed.

> So the DS bit always needs to be set with the NR bit.
> If the definition of the NR bit will be changed, and it will include
> the integrity and authenticity as well, the NR bit would be sufficient.
> Otherwise both bits need to be set !

I do not see a need to change the definition.

> > That is the concern that it would be unfit to use a NR key for
> > unconscious and automatic authentication mechanisms where the signing
> > entity doesn't see and accept what he is signing with his key. Since
> > this would lower the evidence value of NR signatures in court.
 
> I agree, it's necessary to be able to distinguish a key used for
> unconscious automatic signatures from a key used for conscious
> signatures. But if I make such a difference I assume that the key
> used for unconscious signatures (DS bit) is worth almost nothing
> because the signer can falsly deny having signed the object.

It can be used for authentication. Do not confuse authentication with
non-repudiation.

> So you can hardly place any trust in a certificate with the DS bit set.
> I don't think this was the intent of this keyUsage bit.

This was not !
 
> I think the separation between keys used for conscious and unconscious
> signing has to be placed somewhere else in the certificate, e.g. in the
> extended key usages. 

This is not necessary.

> You shouldn't overload the semantics of the
> keyUsage field ! I'd propose that a certificate to be used for access
> control purposes where your private key is automatically used for
> signing must contain an additional indicator, e.g. another extension.
> Additionally, the DS bit in the keyUsage must be set.
> 
> Comments ?

No change to the current text is needed. However, some clarifications on
that topic might be helpful. If needed, they could be placed in the
"Security consideration section" (section 10 page 67).

Let me now tackle the previous question:

Can a certificate have both bits (DS and NR) set, and in such a case
what are the implications?

In such a case this means that the certificate can be used for both
services. This is economical (one private key and a single certificate)
but can be dangerous, unless such a certificate and the correspondant
private key is only used in well known environments and with well known
protocols that do not suffer from the kind of attack mentioned in the
paper "Protocol Interactions and the Chosen Protocol Attack", recently
advertised on the mailing list.

A private key whose certificate has the NR bit set must only be used in
well known environments with well known protocols. If the DS bit is also
set, the constraint is extended to plenty of protocols and environments
that may be more difficult to control. As a *very* simple example, an
authentication scheme where I would be invited to sign a 160 bits
challenge would not be acceptable for a certificate where both bits are
set, but quite acceptable if only the DS bit is set.

Denis
 
> Petra
 
> PS.: I'm one of the authors, who wrote the profile for the german
> digital signature law and I've followed the whole discussion with great
> interest. The profile is only a draft by now, so it's possible to
> change it if there is a good reason for doing so.

-- 
      Denis Pinkas     Bull S.A.          mailto:Denis.Pinkas@xxxxxxxx
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21