Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt

From: "Jim Schaad" <[email-masked]>
Date: Fri, 7 Feb 2003 09:59:13 -0800

Gentlemen,

1.  Can you make the title of the document another line longer?

2.  Please consider adding the following textto section 1.2 p 3.  "Note:
It is not possible to restict the use of a key either RSASSA-PSS and
anything else.  The same is true of RSAES-OAEP."

3.  In section 1.2 p 2 last sentence.   I think it should be "signature
and/or key transport".

4.  In section 2.1, there is a par of paragraphs about the use of NULL
or ABSENT in encoding the hash functions.  There appears to be a
conflict between the two paragraphs.  The first says use ABSENT.  The
second says use NULL.  One or the other should be omitted, I would
perfer the second as the first is the "standard" way of doing things.
The second would require changes in my encoder/decoder utility
functions.

5.  Section 3, para 1, last sentence:  It appears to me that there
should potentially be two different statements on conforming CAs.  Some
CAs will using RSASSA-PSS as the signing algorithm, while other will
just encode a certificate with the RSASSA-PSS public key.  Should these
be seperated in conformant statements?

6.  Section 3.1 maskGenAlgorithm.  Please remove the statement "It MUST
be an algorithm identifier".  This is a tautology.

7.  Section 3.2.  I would like to see a different OID used for a
signature value from that used to encode the public key.  This makes it
easier to process for encode/decode as there are not two structures with
the same OID.

8.  RSASSA-PSS-params and signature processing.  I am confused about
what should be done by a signature verifier/producer in checking the
parameters of a signature againist the parameters of a signature.  My
first assumption was that all of the fields mattered and should be
"equivalent".  From reading the text I find that this is not the case
and the saltLength is encoded in the certificate parameters but is
wildcarded against the signature parameters.  This type of behavior
makes implementation difficult.  My first assumption on this
implemenation was a binary comparison.  This would not work for a number
of reasons the first being saltLength, the second being the requirements
that I need to be able to match a defaulted parameter against an
existing parameter (i.e. sha1Identifier present vs absent).

9.  Section 3.1 maskGenAlgorithm.  The text at the end of the paragraph
is missing some cases that would seem to be logical.  The following
should be matched:
    ABSENT
    {id-mgf1}
    {id-mgf1, {id-sha1}}
    {id-mgf1, {id-sha1, NULL}}

It would be MUCH simplier if the "stupid" cases could be removed, but I
don't know if that would match your worldview.

10.  Section 3.1 saltLength.  There seems to be a mis-match between the
default value in the ASN.1 structure and that in the text.  The
structure definition says 20.  The description says the length of the
hash output value.  This implies that if I were to use md5 as in the
hashAlgorithm field, the default value of the ASN.1 structure for
saltLength would suddenly be 16 not 20.

11. Section 4.1, para 1 - missing id- from RSAES-OAEP in the first
sentence.

12. Section 4.1, maskGenFunc - see comment 9.

13. Section 4.1, RSAES-OAEP-params comparison function.  This comparison
has some of the same problems as that of RSASSA-PSS.  I don't know the
proper way to compare pSourceFunc.  I believe that the comparison here
is dependent on the value of pSourceFunc.Algorithm.  For a value of
id-pSpecified, this field should be ignored.  Are there other values
(such as if nullOctetString is not of 0 length based on para 6 of the
security considerations section).

14. Section 5.  Please change "the parameters MUST be NULL" to "the
parameters MUST be ABSENT".  This matches SHA-1 convention.

15.  ASN.1 Module:  Organization:  It helps if the parameters structure
is in the same section as the OID that uses the structure.  Looking from
the top to the very bottom for the parameters is messy.

16.  ASN.1 Module:  All of the rSASSA-PSS-*-Identifier structures need
to be changed to
   rSASSA-PSS-*-Identifier AlgorithmIdentifier ::= {
	id-RSASSA-PSS, rSASSA-PSS-*-params }

   rSASSA-PSS-*-params RSASSA-PSS-params ::= {
	*-hash, mgf1*Identifier, 20, 1}

The second level of initialization cannot be done in 1988 because the
structure is an ANY.

17.  Section 7.1 [P1v2.1]  Remove the first J. and the first comma.

Jim

---

From: "Kaliski, Burt" <[email-masked]>
Date: Fri, 21 Feb 2003 11:56:13 -0500

Dear Jim,

Sorry for my slow response to your comments. My replies are embedded below.

I'm not fully committed to the approach of encoding algorithm usage
restrictions into the "public key type", and am open to other suggestions.
Your message illustrates the challenges with this approach.

-- Burt

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]]
Sent: Friday, February 07, 2003 12:59 PM
To: 'Russ Housley'; Kaliski, Burt
Cc: [email-masked]
Subject: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt

Gentlemen,

[BK] We'll try :-)

[BK] Agreed.

[BK] Our intent was that a key would be used only for one or other other,
hence "or" not "and/or".

[BK] Both are allowed, due to confusion in implementations. The parameters
should be absent, but if present must be NULL. The new RFC version of PKCS
#1 v2.1 includes text on this,
ftp://ftp.rfc-editor.org/in-notes/rfc3447.txt.

[BK] Agreed, the conformance may be different for signing with RSASSA-PSS,
vs. including public keys restricted to RSASSA-PSS.

[BK] OK.

[BK] The OID is not used to encode the public key directly, but to encode an
AlgorithmID; the AlgorithmID is used to describe the public key. So, the
AlgorithmID has two meanings, one for the signature, one for the public key.
I agree this is potential problem, and am open to alternatives.

[BK] I see the challenge.

[BK] The second case can be removed since MGF1 must have a parameter (no
confusion on that). The others are needed, the first one for the default
case, the third and fourth in case of confusion about SHA1's parameters
(though MGF1 is explicit that it expects the SHA1 to have parameters).

[BK] Yes, this is a problem, already propagated in PKCS #1 v2.1. Better not
to have defaults ... what's your preference on fixing things?

[BK] OK.

[BK] See above.

[BK] In general, this field is unused. But I can see cases where it might be
used several different ways with a given public key, which means that a
direct comparison might not be ideal.

[BK] See answer to comment 4. The parameters SHOULD be absent but MAY be
NULL, and receivers MUST accept either.

[BK] Agreed, will improve this.

[BK] OK.

[BK] OK.

Jim

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Feb 2003 16:27:58 -0500

Burt & Jim:

Clearly there are some choices.  I believe that use of the same object 
identifier is the best we can do given the current state of the world.  The 
solution that we devise needs to be backward compatible.  I do not think 
that assigning two OIDs for each possible use of an RSA or Elliptic Curve 
public key is desirable.  We already need to assign one OID for the 
signature validation (or key management technique).  Assigning a second OID 
for use in the subject public key info to say that the key can only be used 
in a particular manner is only useful if the parameters that are already 
associated with the currently assigned OID do not support the necessary 
information.

Russ

>[JS] 7.  Section 3.2.  I would like to see a different OID used for a