Re: Consensus Text for key usage?

["Aram Perez" <aram@xxxxxxxxx>]

Hi Tim,

> Folks,
> 
> With Aram and Denis back in the fray, I think we can finish this one off.
> I have incorporated all the changes, and think we may be nearing consensus!
>  There are two pieces of proposed text; text for the key usage extension
> and text for the security considerations section.
>
> Please read it carefully.  In general, the changes were all introduced on
> the list in the "porposed" thread, but I have tweaked a couple of other
> paragraphs.  The only real suprise is that I capitulated and deleted the
> word "user" under dataEncipherment.  I thought keeping it would be less
> controversial, but that wasn't true!  I don't think it added anything, so
> let's delete it.
>
> Thanks,
>
> Tim Polk
>
[snip]
>        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.  This service protects against the certificate subject falsely
>        denying signing the data.  In the case of later conflict, a reliable
>        third party may determine the authenticity of the signed data.

Shouldn't this last sentence read something like "a reliable third party may
determine the non-repudiability (or repudiability) of the signed data" since
previous paragraph states the digitalSignature is used for "entity
authentication and data origen authentication"?

[snip]
>
>     This profile does not restrict the combinations of bits that may be
>     set in an instantiation of the keyUsage extension.  However,
>     valid combinations of bits are specified for particular algorithms
>     in section 7.3.

Like I mentioned in a private exchange, I would add something to the effect
of "Although there are no key restrictions, implementers should be aware
that certain combinations do not make sense (i.e. keyAgreement for RSA keys,
keyExchange for ECC keys) and some combinations may 'be insecure' (or
'lessen the security')."

[snip]

Regards,
Aram Perez