TLDR: Yes, everything in a CSR or a certificate is using ASN.1 notation, ASN.1 is a description of the data types.
There are a few things to unpack here but let's start with some definitions:
Data formats used in PKI:
ASN.1:
This is a syntax notation, or how to represent various data types (integer, string, bytes, etc...).
A programming language equivalent would be a data structure with defined types. eg:
struct Certificate {
tbsCertificate TBSCertificateType // Another struct
signatureAlgorithm SignatureAlgorithmType // Another struct
signatureValue []byte // An array of bytes
}
DER:
DER encoding is a way of serializing ASN.1 data. The output is an array of bytes that can be stored in a file, sent over the network, or as input to a signature algorithm.
PEM:
PEM is the base64 representation of DER data plus a header and footer. This results in ASCII data that can be easily sent over ASCII-only channels (eg: email doesn't do binary, it needs to be encoded).
I'm going to ignore PEM encoding because it's not strictly necessary here, it is only used to encapsulate binary data to pass around between parties.
How signatures work:
Signature algorithms in PKI have three parameters
- the signature algorithm (and optional parameters), eg:
PKCS #1 SHA-256 With RSA Encryption
- the key: the private key of the signer
- the input: raw bytes to sign
There is one output: the signature, which is a bit string.
note: under ASN.1, an octet string and a bit string are two different types. They are both binary data but the bit string can be any length whereas an octet string length in bits must be a multiple of 8.
Signing the input:
No matter what the input is (certificationRequestInfo for CSR, or tbsCertificate for Certificate), it must first be encoded into plain binary.
We need a standard for what that binary is. Luckily, we have one.
- For a CSR, RFC 2986 tells us::
The value of the certificationRequestInfo component is DER encoded, yielding an octet string
- For a Certificate, RFC 5280 tells us:
The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate.
In both cases, the relevant data in ASN.1 format must be DER encoded, then fed into the signature algorithm. The output (the signature) is a bit string.
What happens to the output:
The output of the signature algorithm is stored in the signatureValue of field of the certificate with type bit string. Again, this is in ASN.1 notation.
Once all certificate fields have been set properly, the certificate is DER encoded.
If needed, the DER data is base64 encoded to yield the PEM data format. But this is not required.
A word of warning:
I think you're trying to accomplish too much. I would start with the basic components of the CSR/Certificate flow and worry about the finer details (such as data encoding) later.
Instead of a diagram that contains all the possible details, start at a high level, get a good handle on the process, then dig into the gritty details if you must.
