[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3280bis: key usage (13)



Hi Denis,

Incorporating comments in the ASN.1 about CC seems like a
fine idea.

However, I don't believe your proposed text is a good idea,
in fact, if I had the energy, I'd be glad to argue about the
serious problems I see with every single sentence except for
the last paragraph.

Just take one phrase: "Since a content commitment signing is
considered to be a digitally signed transaction...". I've
honestly absolutely no idea what that means, and I really
don't want to have to think about it either.

However, I don't think that hammering this out on the list
is likely to be very productive - maybe we should try get
together in Paris and have yet another key usage bun fight
before the PKIX meeting, but even with that, I wouldn't be
confident that any sensible text is possible (except the
"NR MUST be random" proposal of course:-).

I wonder is there any precedent for an RFC containing a
disclaimer? Say including text describing NR/CC followed
by a paragraph which says that a significant number of
those interested in PKIs think that NR is basically silly?

Stephen.

Denis Pinkas wrote:



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