Re: Consensus Text for key usage?

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Aram,

As far as I am concerned your two proposed (small) changes seem
quite reasonable to me.

Regards,

Denis

 
> 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