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

comments see below...

Denis Pinkas wrote:
> 
> 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.
> 
...
> 
> > 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.
 
Well, I wouldn't call this a restriction, it only excludes
non-repudiation, certificate signing and revocation information 
signing. The DS bit is definetly not restricted to session-oriented 
authentication only.

> > 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 what does it mean if the NR bit is set ? What's the difference to DS
?
The assumption: 
        NR is for conscious signatures
        DS is for unconscious automatic signatures
cannot be based on the pkix draft because it's not defined like that.
I'd like to follow this solution but right now the pkix draft does not
require the DS bit for unconscious automatic signatures. If everybody
interprets the DS bit like that, we should add this requirement to the 
definition of the DS bit.

> > 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.
 
Like Tony proposed, we need to agree on a definition for
non-Repudiation.
In my opinion non-Repudiation is a service offered by a CA - see my 
answer to Tony's mail. 

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

Agreed !
 
> > 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, do you require a timestamp for all signatures with a NR certificate
?
Will the verification of such a signature fail without a timestamp?
The implications on the verification in case of the nonRepudiation bit 
set in a certificate are not clear to me.

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

If you look at the big confusion on these keyUsage bits you have to
agree, 
that we cannot leave like that either.
 
> > 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.

What isn't necessary: The separation of keys or to place the seperation
somewhere else in the certificate ?
I think the separation is quite important, but unfortunately it's not 
defined by now how to separate and distinguish certificates for
conscious 
and unconscious signatures.
 
> > 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.
> 

Some clarification like that should be added to the current text, if all 
agree on this definition. This would help a lot !

Petra

vcard.vcf
Description: Card for Petra Glöckner

smime.p7s
Description: S/MIME Cryptographic Signature