2
$\begingroup$

What data does a CA sign? I know that in a certificate there is plenty of information like the serial number of the certificate itself, the X.509 version number, the user Public Key, the asymmetric algorithm to which the key belongs and its size, the user ID, the validity of the cert (both beginning and expiration day), CA ID and finally the digital signature and the algorithm used to generate it.
But what are the information signed with the CA private key? Is it just the (user ID || user public key) or something else?

I don't know if I need to specify that, but I mean concatenation with the || symbol. (But I don't know if the data are really appended one to another)

$\endgroup$
2
$\begingroup$

The information that is signed may differ by certificate, but basically the procedure can be found by looking at RFC 5280 and working downward:

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.  This
   signature value is encoded as a BIT STRING and included in the
   signature field.  The details of this process are specified for each
   of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].

   By generating this signature, a CA certifies the validity of the
   information in the tbsCertificate field.  In particular, the CA
   certifies the binding between the public key material and the subject
   of the certificate.

Note that signature value is the signature put over the certificate by the CA here, it's not a digital signature over a document.

The next section contains a content description:

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.  Extensions for the Internet PKI are described in Section
   4.2.

TBS in TBSCertificate stands for To Be Signed which makes things pretty clear.

To be more precise, the contents of the TBS certificate are

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3
     extensions      [3]  Extensions OPTIONAL

subjectPublicKeyInfo above contains the encoded public key.

And the list of extensions can be found by looking at the index:

    4.2. Certificate Extensions ....................................26
           4.2.1. Standard Extensions ................................27
                  4.2.1.1. Authority Key Identifier ..................27
                  4.2.1.2. Subject Key Identifier ....................28
                  4.2.1.3. Key Usage .................................29
                  4.2.1.4. Certificate Policies ......................32
                  4.2.1.5. Policy Mappings ...........................35
                  4.2.1.6. Subject Alternative Name ..................35
                  4.2.1.7. Issuer Alternative Name ...................38
                  4.2.1.8. Subject Directory Attributes ..............39
                  4.2.1.9. Basic Constraints .........................39
                  4.2.1.10. Name Constraints .........................40
                  4.2.1.11. Policy Constraints .......................43
                  4.2.1.12. Extended Key Usage .......................44
                  4.2.1.13. CRL Distribution Points ..................45
                  4.2.1.14. Inhibit anyPolicy ........................48
                  4.2.1.15. Freshest CRL (a.k.a. Delta CRL
                            Distribution Point) ......................48
           4.2.2. Private Internet Extensions ........................49
                  4.2.2.1. Authority Information Access ..............49
                  4.2.2.2. Subject Information Access ................51
$\endgroup$
  • $\begingroup$ Are the contents of the TBS field simply binded together and given in input to the hash function? $\endgroup$ – M-elman Dec 17 '16 at 8:10
  • 1
    $\begingroup$ ASN.1 DER encoding is already a unique encoding of these fields. There are some subtleties with regards to IMPLICIT fields and some people manage to get the encoding of the key usage wrong, but in principle the DER encoding is a canonical encoding: you can only get to one specific encoding given the various fields (no reordering or additional padding etc. allowed). I won't go any further into ASN.1 or DER here. And yes, this is input to the signature function which includes a hash function. $\endgroup$ – Maarten Bodewes Dec 17 '16 at 13:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.