Subject: FW: Minor confusion in PKIX part 1, section 7.3.3

From: "Grall, Cynthia" <[email-masked]>
Date: Tue, 24 Nov 1998 08:42:58 -0800

> The following paragraph seems to have two conflicting sentences:
> 
> 7.3.3  DSA Signature Keys
> 
> ...
> 
>    If the DSA algorithm parameters are absent from the subjectPublicKey-
>    Info AlgorithmIdentifier and the CA signed the subject certificate
>    using DSA, then the certificate issuer's DSA parameters apply to the
>    subject's DSA key.  If the DSA algorithm parameters are absent from
>    the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
>    subject certificate using a signature algorithm other than DSA, then
>    the subject's DSA parameters are distributed by other means.  If the
>    subjectPublicKeyInfo AlgorithmIdentifier field omits the parameters
>    component and the CA signed the subject with a signature algorithm
>    other than DSA, then clients shall reject the certificate.
> 
> I understand the second sentence to mean if the CA cert. has a (for
> example) RSA key, and the EE cert. has a DSA key with no parameters,
> then the EE cert. is okay and I have to find the parameters somewhere
> else.  
> 
> The third sentence says if the CA cert. has (for example) a RSA key,
> and the EE cert. has a DSA key with no parameters, then I should reject
> the EE cert.
> 
> Is there something I'm missing here?  If these do conflict, which is the
> correct statement?
> 
> Cindy
> ----------
> Cindy Grall                       [email-masked]
> Network Associates, Inc.          phone: (310) 737-1629
> 3415 S. Sepulvida Blvd.           fax:   (310) 737-1755
> Los Angeles, California 90034

---

From: "Grall, Cynthia" <[email-masked]>
Date: Mon, 30 Nov 1998 07:49:50 -0800

I agree.  If the intent is to disgard a subject certificate if the DSA
param's are not present AND the CA used a signature algorithm other than
DSA, then this sentence (especially the phrase "distributed by other means")
is confusing.  To me it directly contradicts the next sentence which states
"...then clients shall reject the certificate."

Cindy
-------------
Cindy Grall
Network Associates, Inc.                    [email-masked]
3415 s. Sepulvida Blvd. suite 700       phone: (310) 737-1629
Los Angeles, CA 90034                       fax: (310) 737-1755

> -----Original Message-----
> From:	Santosh Chokhani [SMTP:[email-masked]]
> Sent:	Monday, November 30, 1998 7:15 AM
> To:	'Russ Housley'; [email-masked]
> Cc:	[email-masked]; [email-masked]
> Subject:	RE: Minor confusion in PKIX part 1, section 7.3.3
> 
> Russ and Tim Polk:
> 
> I think the following sentence is confusing and may mislead:
> 
> 	"If the DSA  algorithm parameters are absent from the
> subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject
> certificate using a signature algorithm other than DSA, then the
> subject's DSA parameters are distributed by other means." 
> 
> It does not seem to lead to any processing requirements.  Thus, I
> suggest we delete it from PKIX part 1.
> 
> 
>

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 30 Nov 1998 10:14:57 -0500

Russ and Tim Polk:

> From:	Russ Housley [SMTP:[email-masked]]
> Sent:	Monday, November 30, 1998 9:45 AM
> To:	[email-masked]
> Cindy:
> This is trying to explain parameter inheritance.
> 
> When the DSA algorithm parameters are absent from the
> subjectPublicKeyInfo
> AlgorithmIdentifier and the CA signed the subject certificate using
> DSA,
> the CA's parameters are inherited by the issued certificate.  This is
> done
> to reduce the size of the certificate.  The parameters are more than
> twice
> the size of the public key, so to reduce the number of certificates
> that
> include them.
> 
> When the DSA algorithm parameters are absent from the
> subjectPublicKeyInfo
> AlgorithmIdentifier and the CA signed the subject certificate using an
> algorithm other than DSA, the CA's parameters cannot be inherited.  To
> avoid this situaltion, the parameters should be put in the
> certificate.  If
> they are not in the certificate, it should be rejected.
> 
> Russ
> 
>

---

From: Al Arsenault <[email-masked]>
Date: Tue, 01 Dec 1998 02:00:21 -0500

If I recall correctly, this paragraph is actually trying to address the
fact that the parameters field is optional, and even if it's there, it
might be NULL.  The relevant wording is:

> If the DSA algorithm parameters are absent 
> from  the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed 
> the subject certificate using a signature algorithm other than DSA, 
> then  the subject's DSA parameters are distributed by other means. If 
> the  subjectPublicKeyInfo AlgorithmIdentifier field omits the 
> parameters component and the CA signed the subject with a signature 
> algorithm other than DSA, then clients shall reject the certificate. 
> 

This is poorly worded, I admit, but it tries to address two different cases:

	case 1:  the CA used an algorithm other than DSA, the end-entity cert has
a DSA key, and the parameters component of the subjectPublicKeyInfo
AlgorithmIdentifier is PRESENT but equal to NULL.  In this case, the
end-entity need not reject the certificate, but it has to get the parameter
values from some place other than the certificate.

	case 2:  the CA used an algorithm other than DSA, the end-entity cert has
a DSA key, and the parameters component of the subjectPublicKeyInfo
AlgorithmIdentifier is ABSENT.  There's not a NULL field, there's no field.
 In this case, the end-entity has to reject the certificate.

(There was actually a long discussion in the S/MIME WG in Chicago about
whether this field should be there and be set to NULL, or left out
altogether. You can see the S/MIME meeting minutes/mailing list for all the
gory details.)

Before figuring out the wording that would make this clearer, the important
question is:  is this correct?  That is, should the actions be different in
these 2 cases (including the field & setting it to NULL, and omitting the
field altogether), or should they be the same?  If they're the same, which
should they be - reject the cert, or go get the parameters from somewhere else?

In my opinion, the proper action in both cases is to look for the parameter
values first, before rejecting the certificate, but that's just a personal
preference.  Other opinions are welcome (and I'm confident they'll come :-)  

			Al Arsenault