Subject: Re: Changes to RFC2459

From: [email-masked] (Terry Hayes)
Date: Mon, 05 Apr 1999 15:33:40 -0700

I would like to restate Michael Sierchio's description of what defines a
CA in
Netscape's products.  I would say that by installing the certificate in
question, the user of the application is asserting that the certificate
belongs
to a CA.

The MIME type "application/x-x509-ca-cert" begins the process of
installing the
CA, but it is up to the user to confirm that operation, and to set
various
trust (or policy) bits that are stored with the certificate.  The
installation
operation allowed, whether the certificate is self-signed (a common
case), or
is a certificate issued by some other entity.  The Netscape applications
do not
check extensions for these certificates, primarily for compatibility
with older
(V1-style) CA certificates.

If the user does install what appears to be an EE certificate as a CA,
Netscape
applications will allow that "EE" to issue certificates.  However these
certificates will only work as part of a certificate chain that ends
with this
"EE-CA".  The chain will never include the CA that issued the original
EE
certificate.  The policies that apply to the chain will be those
assigned by
the user to the "EE-CA" certificate when it was installed.  The same
effect
would have occurred if the "EE" had issued a self-signed certificate to
itself,
and the user had installed that instead.

Certificates at middle levels of a certification chain are required to
contain
an indication that it is a CA.  This can be done with the
basicConstraints
extension, or with private certificate type extensions which were
defined and
in-use to solve this problem before X.509 standard extensions were
available.

Terry Hayes
[email-masked]

Michael Sierchio wrote:

> Peter Gutmann wrote:
>
> > Both MSIE and Netscape treat self-signed certs without
basicConstraits as
> > CA's by default (in fact I don't know of any way to get them to
*not*
> > treat the cert owners as CA's).
>
> My impression is that, in the case of Netscape,  it's the MIME type
> that causes a cert to be treated as a CA:  application/x-x509-ca-cert,

> and not all of these are self-signed.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 5 Apr 1999 19:02:20 -0400

Terry,

Thanks for the additional clarification.  What you describe is an
algorithm, including user interaction, for declaring a cert to be that of a
CA in certain contexts, and subject to certain later processing constraints
(analogous to use of nameConstraints), all of which is understandable in a
pre-v3 environment.

However, since v3 certs are clearly identified as such, one could use a
different algorithm for CA determination for v1 vs. v3 certs. I don't
criticize Netscape for adopting the algorithm you have described prior to
development of the PKIX standards, I also don't think that PKIX v3 cert
standards should be constrained by existing implementations that could have
been coded to distinguish v3 vs. v1 certs.

Steve

---

From: [email-masked] (Terry Hayes)
Date: Mon, 05 Apr 1999 18:00:08 -0700

Stephen,

  A comment on your response, and an attempt to bring the discussion back to
the basicConstraints issue.

Stephen Kent wrote:

> ... What you describe is an

Even in a v3 environment there still needs to be a process defined (possibly
involving user interaction) which approves the operation and defines other
operational parameters that will be associated with the CA.  Just because the
certificate looks like a valid v3 CA doesn't me I will always believe it.

> been coded to distinguish v3 vs. v1 certs.

I believe you are suggesting that an application SHOULD (MUST?) disallow
requests to install certificates as a CA if the certificate extensions do not
allow this use.  This may be a good idea.  However (to bring us back to the
original discussion on basicConstraints), if PKIX does not require a
basicConstraints extension in EE certs, then an application would have to rely
on the version field to tell  whether v3 rules (policies?) should be applied.

I'm not sure I've seen this use of the version field before.  In particular, if
basicConstraints would have been the only extension in the certificate, section
4.1.2.1 says that the version field should be set to version 1.  This would
kick in v1 processing rules (for compatibility reasons).  To get the kind of
processing you want, the version would have to be set to version 3 even though
there are no extensions included in the certificate.

A better solution would be to include the basicConstraints extensions in EE
certificates.  In that case, the application could reject these v3 certificates
in CA management functions, while still supporting the v1 environment.  Of
course the cost is extra room in the certificate to carry the extension data.

Terry Hayes
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 6 Apr 1999 10:31:54 -0400

Terry,

>certificate looks like a valid v3 CA doesn't me I will always believe it.

I agree whole heartedly with this design principle when it applies to
self-seigned (root) CA certs.  I would not agree that user interaction is
needed for subordinate CA certs.
>on the version field to tell  whether v3 rules (policies?) should be applied.

First, this is not always an application issue per se; it may be subsumed
by an API for cert management.  Second, other than "root CA" certs, there
is not a notion of "installing" a cert in the cert chain validation
algorithm, so I interpret your comments in that more narrow context.
Third, I am suggesting that it is approrpiate for the cert processing
software to first examine the version field prior to subsequent processing,
something that I would consider generally good software design practice.
Having examined the version field, then one might reasonably use different
rules for determining CA vs. EE certs.

>there are no extensions included in the certificate.

I don't understand how you are interpreting section 4.1.2.1 of RFC 2459.
The relevant text says:
   4.1.2.1  Version

   This field describes the version of the encoded certificate.  When
   extensions are used, as expected in this profile, use X.509 version 3
   (value is 2).  If no extensions are present, but a UniqueIdentifier
   is present, use version 2 (value is 1).  If only basic fields are
   present, use version 1 (the value is omitted from the certificate as
   the default value).

Are you confusing the term "basic fields" here with the "basicConstraints"
extension?  The former term refers only to the fields in a version 1
certificate.   So, even if basicConstraints is the only extention present,
the version number MUST be 3 to comply with 2459.

>course the cost is extra room in the certificate to carry the extension data.

I still fail to see why the algorithm I described fails to work if one uses
EE vs. CA rules appropriate to the version type of the certificate, which
is consistent with 2459.

Steve