x509 v1 certificate

[Simon Josefsson]

Werner Koch <wk at gnupg.org> writes:

> On Mon, 25 Sep 2006 10:58, Simon Josefsson said:
>
>> However, I do agree with you, and a perfectly reasonable
>> interpretation is that CA certificates (including root CAs) MUST have
>> key usage extensions, but a conforming verifier of certificates chains
>> should permit certificates without key usage extensions.  This is also
>
> But not without BasicConstraints.  I just looked at the test
> specification we had to pass and they clearly state that all CA
> certificates (including the root CA certificate) are required to carry
> a BasicConstraints.
>
> Whey saying "all certificates issued by a CA" this obviously includes
> the root certitificate because that one has been issued by the CA too.
> Whether it is self-signed or not does not matter.

If we talk about RFC 3280, the algorithm in section 6 doesn't verify
root CAs aka trust anchors, only intermediate CAs, see:

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
      the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated; and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
      time in question.

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.  Information about trust anchors
   are provided as inputs to the certification path validation algorithm
   (section 6.1.1).

And further:

6.1.1  Inputs

   This algorithm assumes the following seven inputs are provided to the
   path processing logic:
...
      (d)  trust anchor information, describing a CA that serves as a
      trust anchor for the certification path.  The trust anchor
      information includes:

         (1)  the trusted issuer name,

         (2)  the trusted public key algorithm,

         (3)  the trusted public key, and

         (4)  optionally, the trusted public key parameters associated
         with the public key.

      The trust anchor information may be provided to the path
      processing procedure in the form of a self-signed certificate.
      The trusted anchor information is trusted because it was delivered
      to the path processing procedure by some trustworthy out-of-band
      procedure.  If the trusted public key algorithm requires
      parameters, then the parameters are provided along with the
      trusted public key.

Although in general, I'd love to see more implementations reject CAs
that doesn't conform to RFC 3280 section 4.  It is difficult to
motivate that decision by pointing to any standard, though, as far as
I know.

/Simon