AW: 3280bis: key usage (13)

[thomas.beckmann@xxxxxxxxxxxxxx]

Denis, Stefan,

why not make it the other way round? Why not call it contentCommitment in
the definition with a note that this was nonRepudiation in older versions?
Wouldn't that foster the use of the term contenCommitment in future?

Regards

Thomas Beckmann

> -----Ursprüngliche Nachricht-----
> Von: owner-ietf-pkix@xxxxxxxxxxxx
> [mailto:owner-ietf-pkix@xxxxxxxxxxxx]Im Auftrag von Denis Pinkas
> Gesendet: Freitag, 3. Juni 2005 09:54
> An: pkix
> Betreff: 3280bis: key usage (13)
> 
> 
> 
> To the list,
> 
> We still need a text for bit 1.
> 
> The text from X.509 has been published in Corrigendum 3 (04/2004)
> on pages 4 and 5 (see ISO/IEC 9594-8:2000/Cor.3:2004 also called
> ITU-T Rec. X.509 (2000)/Cor.3 (04/2004)).
> 
> An extract from this text is copied below:
> 
> b) contentCommitment: for verifying digital signatures which 
> are intended
>     to signal that the signer is committing to the content 
> being signed.
>     The type of commitment the certificate can be used to 
> support may be
>     further constrained by the CA, e.g. through a certificate policy.
>     The precise type of commitment of the signer e.g. "reviewed and
>     approved" or "with the intent to be bound", may be 
> signalled by the
>     content being signed, e.g. the signed document itself or 
> some additional
>     signed information.
> 
>     Since a content commitment signing is considered to be a 
> digitally signed
>     transaction, the digitalSignature bit need not be set in 
> the certificate.
>     If it is set, it does not affect the level of commitment 
> the signer has
>     endowed in the signed content.
> 
>     Note that it is not incorrect to refer to this keyUsage 
> bit using the
>     identifier nonRepudiation. However, the use of this 
> identifier has been
>     deprecated. Regardless of the identifier used, the 
> semantics of this bit
>     are as specified in this Directory Specification.
> 
> I had some face to face discussions with Stefan and we looked for a 
> compromise (which means making all parties equally unhappy). 
> He argued that 
> as far as the ASN.1 is concerned we should keep the current 
> structure that is :
> 
>       nonRepudiation          (1),
> 
> The reason is that some software directly use the name of the 
> field for 
> display. So the idea would be to keep the current ASN.1 but 
> to mention in a 
> note that it would also be legitimate to use the ISO ASN.1, which is :
> 
>       contentCommitment       (1),
> 
> so we would have :
> 
>        KeyUsage ::= BIT STRING {
>             digitalSignature        (0),
>             nonRepudiation          (1),
>     -- this field may also be called contentCommitment
>     -- as per ISO/IEC 9594-8: 2000 / Corrigendum 3 : 2004
>     -- and ITU-T Rec. X.509 (2000) / Corrigendum 3 (04/2004)
>             keyEncipherment         (2),
> 
> The proposal is then to take the text from Corrigendum 3 and 
> provide a link 
> with the term non repudiation (which is the most difficult 
> part of the 
> exercice). See the third paragraph below which is a strawman.
> 
> I would propose the following text for 3280bis:
> 
>     The nonRepudiation bit is asserted for verifying digital 
> signatures
>     which are intended to signal that the signer is committing to the
>     content being signed. The precise type of commitment of the signer
>     e.g. "reviewed and approved" or "with the intent to be 
> bound", may be
>     signalled by the content being signed, e.g. the signed 
> document itself
>     or some additional signed information.
> 
>     Since a content commitment signing is considered to be a 
> digitally signed
>     transaction, the digitalSignature bit need not be set in 
> the certificate.
>     If it is set, it does not affect the level of commitment 
> the signer has
>     endowed in the signed content.
> 
>     A transaction signed with a certificate that has this bit 
> set may be
>     used to build a non-repudiation service which protects against the
>     signing entity falsely denying later on some action, excluding
>     certificate or CRL signing.
> 
>     Note that it is not incorrect to refer to this keyUsage 
> bit using the
>     identifier contentCommitment since it is how it has been 
> renamed by
>     ISO and ITU in the ITU-T X.509 Corrigendum 3 (04/2004). 
> Regardless of
>     the identifier used, the semantics of this bit is the same.
> 
> 
> Denis
>