1

Am I correct in assuming that there's protection against the modification of both the subject and the extension information in a request or X509 certificate?

This signature is just another element embedded in the ASN.1 encoding?

Dustin Oprea
  • 560
  • 2
  • 8
  • 19

1 Answers1

2

You are correct. The integrity of both of those items can be validated by the digital signatures on the request (signed with the requester's private key) or certificate (signed by the CA's private key).

Edit:

RFC 2986, section 3 describing PKCS #10 certificate requests:

3. Overview

   A certification request consists of three parts: "certification
   request information," a signature algorithm identifier, and a digital
   signature on the certification request information.

...

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

and page 5:

The components of type CertificationRequestInfo have the following
   meanings:

...

 attributes is a collection of attributes providing additional
          information about the subject of the certificate.  Some
          attribute types that might be useful here are defined in PKCS
          ...
          certificate revocation.  Another example is information to
          appear in X.509 certificate extensions (e.g. the
          extensionRequest attribute from PKCS #9).  The values of type

RFC 5280 re: x.509 certificates:

4.1.1.3.  signatureValue

   The signatureValue field contains a digital signature computed upon
   the ASN.1 DER encoded tbsCertificate.  The ASN.1 DER encoded
   tbsCertificate is used as the input to the signature function.
   ...


4.1.2.  TBSCertificate

   The sequence TBSCertificate contains information associated with the
   subject of the certificate and the CA that issued it.  Every
   TBSCertificate contains the names of the subject and issuer, a public
   key associated with the subject, a validity period, a version number,
   and a serial number; some MAY contain optional unique identifier
   fields.  The remainder of this section describes the syntax and
   semantics of these fields.  A TBSCertificate usually includes
   extensions.
Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • You don't happen to have a reference into an RFC at hand, do you? – Dustin Oprea Apr 10 '14 at 17:55
  • X.509 is defined as an ITU standard. I'm not sure that's freely available. re: the certificate request have a look at: http://tools.ietf.org/html/rfc2986 – Evan Anderson Apr 10 '14 at 18:25
  • I thought maybe you could cite a specific paragraph so it's a bit more than blind faith. What's the ITU standard vs RFC 5280 (which I thought described X509's)? I thought ASN.1 was ITU, but the others were RFC. – Dustin Oprea Apr 10 '14 at 22:45
  • ASN.1 is an encoding standard. X.509 is the standard for a PKI. – Evan Anderson Apr 10 '14 at 23:20
  • Yes, but you said that X.509 is an ITU standard, and yet I thought it was described by RFC 5280. – Dustin Oprea Apr 10 '14 at 23:34
  • 1
    X.509 *is* an ITU standard. Quoth RFC 5280: "However, the ISO/IEC, ITU-T, and ANSI X9 standard extensions are very broad in their applicability. In order to develop interoperable implementations of X.509 v3 systems for Internet use, it is necessary to specify a profile for use of the X.509 v3 extensions tailored for the Internet." RFC 5280 describes an interpretation of the X.509 standard for use on the Internet. – Evan Anderson Apr 10 '14 at 23:44