Struct ToBeSignedCertificate 

pub struct ToBeSignedCertificate<'input> {

    pub id: CertificateId<'input>,
    pub craca_id: HashedId3<'input>,
    pub crl_series: CrlSeries,
    pub validity_period: ValidityPeriod,
    pub region: Option<GeographicRegion>,
    pub assurance_level: Option<SubjectAssurance<'input>>,
    pub app_permissions: Option<SequenceOfPsidSsp<'input>>,
    pub cert_issue_permissions: Option<SequenceOfPsidGroupPermissions<'input>>,
    pub cert_request_permissions: Option<SequenceOfPsidGroupPermissions<'input>>,
    pub can_request_rollover: Option<()>,
    pub encryption_key: Option<PublicEncryptionKey<'input>>,
    pub verify_key_indicator: VerificationKeyIndicator<'input>,
    pub flags: Option<Bits<8>>,
    pub app_extensions: Option<SequenceOfAppExtensions<'input>>,
    pub cert_issue_extensions: Option<SequenceOfCertIssueExtensions<'input>>,
    pub cert_request_extension: Option<SequenceOfCertRequestExtensions<'input>>,
}

The fields in the ToBeSignedCertificate structure have the following meaning:

For both implicit and explicit certificates, when the certificate is hashed to create or recover the public key (in the case of an implicit certificate) or to generate or verify the signature (in the case of an explicit certificate), the hash is Hash (Data input) || Hash ( Signer identifier input), where:

• Data input is the COER encoding of toBeSigned, canonicalized as described above.
• Signer identifier input depends on the verification type, which in turn depends on the choice indicated by issuer. If the choice indicated by issuer is self, the verification type is self-signed and the signer identifier input is the empty string. If the choice indicated by issuer is not self, the verification type is certificate and the signer identifier input is the COER encoding of the canonicalization per 6.4.3 of the certificate indicated by issuer.

In other words, for implicit certificates, the value H (CertU) in SEC 4, section 3, is for purposes of this standard taken to be H [H (canonicalized ToBeSignedCertificate from the subordinate certificate) || H (entirety of issuer Certificate)]. See 5.3.2 for further discussion, including material differences between this standard and SEC 4 regarding how the hash function output is converted from a bit string to an integer.

Note: Canonicalization: This data structure is subject to canonicalization for the relevant operations specified in 6.1.2. The canonicalization applies to the PublicEncryptionKey and to the VerificationKeyIndicator. If the PublicEncryptionKey contains a BasePublicEncryptionKey that is an elliptic curve point (i.e., of type EccP256CurvePoint or EccP384CurvePoint), then the elliptic curve point is encoded in compressed form, i.e., such that the choice indicated within the Ecc*CurvePoint is compressed-y-0 or compressed-y-1.

Note: Critical information fields:

• If present, appPermissions is a critical information field as defined in 5.2.6. If an implementation of verification does not support the number of PsidSsp in the appPermissions field of a certificate that signed a signed SPDU, that implementation shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established.. A conformant implementation shall support appPermissions fields containing at least eight entries. It may be the case that an implementation of verification does not support the number of entries in the appPermissions field and the appPermissions field is not relevant to the verification: this will occur, for example, if the certificate in question is a CA certificate and so the certIssuePermissions field is relevant to the verification and the appPermissions field is not. In this case, whether the implementation indicates that the signed SPDU is valid (because it could validate all relevant fields) or invalid (because it could not parse the entire certificate) is implementation-specific.
• If present, certIssuePermissions is a critical information field as defined in 5.2.6. If an implementation of verification does not support the number of PsidGroupPermissions in the certIssuePermissions field of a CA certificate in the chain of a signed SPDU, the implementation shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established. A conformant implementation shall support certIssuePermissions fields containing at least eight entries. It may be the case that an implementation of verification does not support the number of entries in the certIssuePermissions field and the certIssuePermissions field is not relevant to the verification: this will occur, for example, if the certificate in question is the signing certificate for the SPDU and so the appPermissions field is relevant to the verification and the certIssuePermissions field is not. In this case, whether the implementation indicates that the signed SPDU is valid (because it could validate all relevant fields) or invalid (because it could not parse the entire certificate) is implementation-specific.
• If present, certRequestPermissions is a critical information field as defined in 5.2.6. If an implementaiton of verification of a certificate request does not support the number of PsidGroupPermissions in certRequestPermissions, the implementation shall indicate that the signed SPDU is invalid in the sense of 4.2.2.3.2, that is, it is invalid in the sense that its validity cannot be established. A conformant implementation shall support certRequestPermissions fields containing at least eight entries.

It may be the case that an implementation of verification does not support the number of entries in the certRequestPermissions field and the certRequestPermissions field is not relevant to the verification: this will occur, for example, if the certificate in question is the signing certificate for the SPDU and so the appPermissions field is relevant to the verification and the certRequestPermissions field is not. In this case, whether the implementation indicates that the signed SPDU is valid (because it could validate all relevant fields) or invalid (because it could not parse the entire certificate) is implementation-specific.

Fields

id: CertificateId<'input>

contains information that is used to identify the certificate holder if necessary

craca_id: HashedId3<'input>

identifies the Certificate Revocation Authorization CA (CRACA) responsible for certificate revocation lists (CRLs) on which this certificate might appear. Use of the cracaId is specified in 5.1.3. The HashedId3 is calculated with the whole-certificate hash algorithm, determined as described in 6.4.3, applied to the COER-encoded certificate, canonicalized as defined in the definition of Certificate.

crl_series: CrlSeries

represents the CRL series relevant to a particular Certificate Revocation Authorization CA (CRACA) on which the certificate might appear. Use of this field is specified in 5.1.3.

validity_period: ValidityPeriod

contains the validity period of the certificate

region: Option<GeographicRegion>

if present, indicates the validity region of the certificate. If it is omitted the validity region is indicated as follows:

• If enclosing certificate is self-signed, i.e., the choice indicated by the issuer field in the enclosing certificate structure is self, the certificate is valid worldwide.
• Otherwise, the certificate has the same validity region as the certificate that issued it.

assurance_level: Option<SubjectAssurance<'input>>

indicates the assurance level of the certificate holder

app_permissions: Option<SequenceOfPsidSsp<'input>>

indicates the permissions that the certificate holder has to sign application data with this certificate. A valid instance of appPermissions contains any particular Psid value in at most one entry.

cert_issue_permissions: Option<SequenceOfPsidGroupPermissions<'input>>

indicates the permissions that the certificate holder has to sign certificates with this certificate. A valid instance of this array contains no more than one entry whose psidSspRange field indicates all. If the array has multiple entries and one entry has its psidSspRange field indicate all, then the entry indicating all specifies the permissions for all PSIDs other than the ones explicitly specified in the other entries. See the description of PsidGroupPermissions for further discussion.

cert_request_permissions: Option<SequenceOfPsidGroupPermissions<'input>>

indicates the permissions that the certificate holder can request in its certificate. A valid instance of this array contains no more than one entry whose psidSspRange field indicates all. If the array has multiple entries and one entry has its psidSspRange field indicate all, then the entry indicating all specifies the permissions for all PSIDs other than the ones explicitly specified in the other entries. See the description of PsidGroupPermissions for further discussion.

can_request_rollover: Option<()>

indicates that the certificate may be used to sign a request for another certificate with the same permissions. This field is provided for future use and its use is not defined in this version of this standard.

encryption_key: Option<PublicEncryptionKey<'input>>

contains a public key for encryption for which the certificate holder holds the corresponding private key

verify_key_indicator: VerificationKeyIndicator<'input>

contains material that may be used to recover the public key that may be used to verify data signed by this certificate

flags: Option<Bits<8>>

indicates additional yes/no properties of the certificate holder. The only bit with defined semantics in this string in this version of this standard is usesCubk. If set, the usesCubk bit indicates that the certificate holder supports the compact unified butterfly key response. Further material about the compact unified butterfly key response can be found in IEEE Std 1609.2.1.

Note: usesCubk is only relevant for CA certificates, and the only functionality defined associated with this field is associated with consistency checks on received certificate responses. No functionality associated with communications between peer SDEEs is defined associated with this field.

app_extensions: Option<SequenceOfAppExtensions<'input>>

indicates additional permissions that may be applied to application activities that the certificate holder is carrying out

cert_issue_extensions: Option<SequenceOfCertIssueExtensions<'input>>

indicates additional permissions to issue certificates containing endEntityExtensions

cert_request_extension: Option<SequenceOfCertRequestExtensions<'input>>

indicates additional permissions to request certificates containing endEntityExtensions

Trait Implementations

impl<'input> Clone for ToBeSignedCertificate<'input>

fn clone(&self) -> ToBeSignedCertificate<'input>

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl<'input> Debug for ToBeSignedCertificate<'input>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Encode for ToBeSignedCertificate<'_>

fn encode(&self, output: &mut Encoder) -> Result<(), EncodeError>

fn encode_to_vec(&self) -> Result<Vec<u8>, EncodeError>

fn encode_to_json(&self) -> Result<String, EncodeError>

where Self: Sized + Serialize,

impl<'input> PartialEq for ToBeSignedCertificate<'input>

fn eq(&self, other: &ToBeSignedCertificate<'input>) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl<'input> Serialize for ToBeSignedCertificate<'input>

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl<'input> StructuralPartialEq for ToBeSignedCertificate<'input>