Subject: [pkix] Question about parameters in X509 certs

From: Massimiliano Pala <[email-masked]>
Date: Thu, 29 Mar 2012 11:28:08 +0200

Hi all,

I am trying to understand (and back it up with normative references) what type of 
parameter specifications
for DSA and EC are allowed (especially for US Federal Issued Certs).

In particular, I think that RFC5480 says that implicitCurve MUST NOT be used in PKIX 
compliant certs,
and, from the Common Policy framework for the federal government it seems that that is 
backed up
also in that document.

It is unclear, to me, the DSS case. In particular, in RFC 3279 , section 2.3.2, says:

"The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within a 
certificate where
the parameters may be used. If the DSA algorithm parameters are omitted from the 
subjectPublicKeyInfo
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 domain parameters are omitted from 
the SubjectPublicKeyInfo
AlgorithmIdentifier and the CA signed the subject certificate using a signature algorithm 
other than DSA, then the
subject's DSA domain parameters are distributed by other means. If the 
subjectPublicKeyInfo AlgorithmIdentifier
field omits the parameters component, the CA signed the subject with a signature algorithm 
other than DSA, and the
subject's DSA parameters are not available through other means, then clients MUST reject 
the certificate."

Does this still stands ? Is the case for omitted parameters for the DSS certs still 
supported by pkix ?
IF so, do you know about the Federal Bridge PKI / other environment that use/ever used DSA 
certs with
null parameters (to be imported from the CA or other means) ?

Cheers,

-- 

tel.718-260-4009 | web: http://member.acm.org/~openca/

Massimiliano Pala, Ph.D.
Director&  Founder, OpenCA Labs
Research Professor, NYU Poly
Assistant Director, CRISSP

http://crissp.poly.edu

---

From: Russ Housley <[email-masked]>
Date: Thu, 29 Mar 2012 06:29:08 -0400

Max:

> I am trying to understand (and back it up with normative references) what type of parameter specifications
> In particular, I think that RFC5480 says that implicitCurve MUST NOT be used in PKIX compliant certs,
> and, from the Common Policy framework for the federal government it seems that that is backed up
> also in that document.
> 
> "The AlgorithmIdentifier within subjectPublicKeyInfo is the only place within a certificate where
> the parameters may be used. If the DSA algorithm parameters are omitted from the subjectPublicKeyInfo
> 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 domain parameters are omitted from the SubjectPublicKeyInfo
> AlgorithmIdentifier and the CA signed the subject certificate using a signature algorithm other than DSA, then the
> subject's DSA domain parameters are distributed by other means. If the subjectPublicKeyInfo AlgorithmIdentifier
> field omits the parameters component, the CA signed the subject with a signature algorithm other than DSA, and the
> subject's DSA parameters are not available through other means, then clients MUST reject the certificate."
> 
> Does this still stands ? Is the case for omitted parameters for the DSS certs still supported by pkix ?
> IF so, do you know about the Federal Bridge PKI / other environment that use/ever used DSA certs with

Yes, this still stands.

If you are concerned about this is a bridge CA environment, the safe thing to do is always include the DSA or ECDSA parameters in the subject public key.  In the ECDSA case, it can be a single OID.

Russ

---

From: Sean Turner <[email-masked]>
Date: Thu, 29 Mar 2012 14:01:39 +0200

> If you are concerned about this is a bridge CA environment, the safe thing to do is always include the DSA or ECDSA parameters in the subject public key.  In the ECDSA case, it can be a single OID.

Best to just always include the parameter, which is just the curve's OID.

spt