SPRUJ17I March 2022 – August 2025 AM2631 , AM2631-Q1 , AM2632 , AM2632-Q1 , AM2634 , AM2634-Q1
The X.509 certificate is defined in Annex A of ITU-T X.509 specification [1]. Certificate is encoded using ASN.1 encoding [2] with DER (Distinguished Encoding Rules) [3]. The main body of the certificate is illustrated below. Essentially, the signed certificate is the concatenation of the certificate itself and the signature. Certificate includes mandatory and optional fields. The supported version shall be v2. V3 and higher versions support is desired but not guaranteed. Various fields of the x509 certificate are as shown below.
SIGNATURE ::= SEQUENCE {
algorithmIdentifier algorithmIdentifier{{SupportedAlgorithms}},
signature BIT STRING,
... }
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned toBeSigned,
COMPONENTS OF SIGNATURE,
... }
Certificate ::= SIGNED{TBSCertificate}
TBSCertificate ::= SEQUENCE {
version [0] Version DEFAULT v1,
serialNumber CertificateSerialNumber,
signature AlgorithmIdentifier{{SupportedAlgorithms}},
issuer Name,
validity Validity,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
issuerUniqueIdentifier [1] IMPLICIT UniqueIdentifier OPTIONAL,
...,
[[2: -- if present, version shall be v2 or v3
subjectUniqueIdentifier [2] IMPLICIT UniqueIdentifier OPTIONAL]],
[[3: -- if present, version shall be v2 or v3
extensions [3] Extensions OPTIONAL]]
-- If present, version shall be v3]]
} (CONSTRAINED BY { -- shall be DER encoded -- } )
In order to meet the security goals, the R5F SBL and the HSM runtime image needs to have an X.509 certificate attached to the binary images. The Boot-ROM will only load images which have a valid X.509 certificate attached to them.