Subject: PKAlgs: 02: DSA Signature Keys needs re-wording

From: [email-masked]
Date: Fri, 23 Mar 2001 09:53:19 +0100

Some further comments:

section 2.2.2 states:
When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in an AlgorithmIdentifier, the encoding SHALL omit the
   parameters field.

This seems to contradict the intended contents of section 2.3.2 ?

Some more minor editorials:
p.3: For each algorithm, the appropriate alternatives for the the keyUsage
...
                                                              ^
p.11: g specifies the generator of the multiplicative subgroup of order g;
                  ^----- (maybe better: "a generator" ?)
^----- should be "q"
p.11: q specifies the prime factor of p-1;
                  ^----- (maybe better: "a prime factor" ?)

p.16:
Maybe it would be nice to extend the following lines (similar to the
following definitions
of gnBasis, etc.):
   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
   Prime-p ::= INTEGER    -- Field size p (p in bits)
   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
   Characteristic-two ::= SEQUENCE {
   ...

   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
   -- type for parameters field for prime-field is Prime-p
   Prime-p ::= INTEGER    -- Field size p (p in bits)
   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
   -- type for parameters field for characteristic-two-field is
Characteristic-two
   Characteristic-two ::= SEQUENCE {
   ...

p.12,p.13,p.18  ... MAY assert either encipherOnly and decipherOnly.
                                                   ^----- or

> -----Original Message-----
> From: Manger, James H [mailto:[email-masked]]
> Sent: Friday, March 23, 2001 7:52 AM
> To: [email-masked]
> Subject: PKAlgs: 02: DSA Signature Keys needs re-wording
>
>
> Comments on draft-ietf-pkix-ipki-pkalgs-02.txt, section 2.3.2
> "DSA Signature
> Keys":
>
> The paragraph beginning "If the DSA algorithm parameters are
> absent" has 3
> sentences.  The 2nd and 3rd contradict each other (at least the 2nd is
> useless in light of the 3rd).  The next paragraph repeats the
> 1st and 3rd
> sentences.
> Delete something.  Perhaps replace the two paragraphs with
> "The DSA domain
> parameters may be omitted if and only if the certificate is
> signed using a
> DSA key that has the same parameters.".
>
> The DSA signature values r & s should not be mentioned in
> this section.
> They are appropriately, clearly and completely defined in
> section 2.2.2 "DSA
> Signature Algorithm"; with an OID, parameters (omit),
> Dss-Sig-Value syntax
> and mapping to a bit string.
> Delete the paragraph beginning "When signing, DSA algorithm
> generates", the
> definition of Dss-Sig-Value and the paragraph beginning "The encoded
> signature is conveyed".
>
>
> Minor editorials:
> Ecdsa-Sig-Value is ECDSA-Sig-Value in the ASN.1 module.
> RSAPublicKey, DSAPublicKey and DHPublicKey are not in the
> ASN.1 module.
> Comment with Dss-Parms in ASN.1 module should be "for DSA
> parameters", not
> "for DSA public key".
>

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 23 Mar 2001 11:28:10 +0100

> This seems to contradict the intended contents of section 2.3.2 ?

No.  Section 2.3 is on algorithm identifiers for *keys* contained in
certificates; section 2.2 is on algorithm identifiers for *signatures*.
To verify a signature, you must already have the key, and that is
where you obtain the parameters from.

A couple of days ago I misunderstood the draft exactly as you do now
(except that I had looked at ECDSA where you now look at DSA :-).
So maybe it's not just me and the draft should have some additional
clarification in the text.  The confusion is caused by the use of
'AlgorithmIdentifiers' for two different purposes: in the
'signatureAlgorithm' field and in the 'subjectPublicKeyInfo' field.

Proposed change for the DSA case, section 2.2.2: Replace

   parameters field.  [...]

by

   When the id-dsa-with-sha1 algorithm identifier appears as the algo-
   rithm field in a signatureAlgorithm field, the encoding SHALL omit the
   parameters field.  [...]

(Similarly for ECDSA.)

(But note that the 'id-dsa-with-sha1' algorithm identifier is never
actually used in 'subjectPublicKeyInfo' fields, so even when taken
out of context the original wording from 2.2.2 is not wrong
-- in 'subjectPublicKeyInfo' fields, you'd see the 'id-dsa' algorithm
identifier instead.)

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036