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

Gentlemen:

My two cents (and personal opinion ;-):

    1) It is bad engineering practice to overload too many meanings on
something. It appears that everyone agrees that non-repudiation is a "service"
and not a "keyUsage". The keyUsage field should only indicate what the key is
being used for, not what services it is providing. If it was my standard, the
keyUsage field would have 3 bits: a) key-exchange, b) data encryption, and c)
signature. There would be a separate field(s) that would indicate that only
certificates can be signed or that a non-repudiation service is being performed.

    2) There are valid reasons to have multiple certificates. I have personally
heard from one bank that will have at least 3 certificates: a) a self-signed
root certificate (they want to be a CA), b) a certificate from the American
Banker's Association (for communicating with other banks), and c) a certificate
from the SIAC (some sort of Securities association) (for communicating with
other security firms).  None of these discussions talk address this fact. Must
all the certificates have the same bits set? I doubt that the root certificate
will.

    3) It is not clear to me who determines the value of the keyUsage field.
Does the CA arbitrarily assigned it, or do I specify the field in the
certificate request? And if non-repudiation is a CA service, how do I know the
CA will set the NR bit?

    4) How is the private key involved? What happens if the corresponding
certificate has the NR bit set but I use the private key to sign an ephemeral
object? Ditto for having the NR bit NOT set but I use the private key to do a
"conscious" signature?

Regards,
Aram Perez
Apple Computer, Inc.


>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