x509-cert: Only allow `Certificate`s to be constructed via either the builder or deserialization

[str4d]

The Certificate type is currently completely transparent:

formats/x509-cert/src/certificate.rs

Line 183 in e0c3e08

pub type Certificate = CertificateInner<Rfc5280>;

formats/x509-cert/src/certificate.rs

Lines 199 to 203 in e0c3e08

	pub struct CertificateInner<P: Profile + 'static = Rfc5280> {
	pub tbs_certificate: TbsCertificateInner<P>,
	pub signature_algorithm: AlgorithmIdentifierOwned,
	pub signature: BitString,
	}

formats/x509-cert/src/certificate.rs

Lines 119 to 144 in e0c3e08

	pub struct TbsCertificateInner<P: Profile + 'static = Rfc5280> {
	/// The certificate version
	///
	/// Note that this value defaults to Version 1 per the RFC. However,
	/// fields such as `issuer_unique_id`, `subject_unique_id` and `extensions`
	/// require later versions. Care should be taken in order to ensure
	/// standards compliance.
	#[asn1(context_specific = "0", default = "Default::default")]
	pub version: Version,
	pub serial_number: SerialNumber<P>,
	pub signature: AlgorithmIdentifierOwned,
	pub issuer: Name,
	pub validity: Validity,
	pub subject: Name,
	pub subject_public_key_info: SubjectPublicKeyInfoOwned,
	#[asn1(context_specific = "1", tag_mode = "IMPLICIT", optional = "true")]
	pub issuer_unique_id: Option<BitString>,
	#[asn1(context_specific = "2", tag_mode = "IMPLICIT", optional = "true")]
	pub subject_unique_id: Option<BitString>,
	#[asn1(context_specific = "3", tag_mode = "EXPLICIT", optional = "true")]
	pub extensions: Option<crate::ext::Extensions>,
	}

This enables arbitrarily-invalid Certificates to be constructed. In particular, this means that the P: Profile generic parameter cannot be trusted; if a downstream API receives an &CertificateInner<Rfc5280>, they have zero guarantee that it is actually valid under the RFC 5280 profile.

The x509-cert crate's public API should be altered to make Certificate (and all types below it) opaque, replacing direct field access with getter methods. This would then enable Certificates to be correct-by-construction, by enforcing the relevant Profile in the builder or during deserialization.

[tarcieri]

@baloo I'd be interested in taking this one

[baloo]

Sure!

[tarcieri]

Something else to consider here is whether it would make sense for Extension to have private fields (which perhaps deserves its own issue).

That could be used to e.g. hide an inner enum which could potentially hold a pre-serialized raw extension (which could help with e.g. #1490).

Constructors like Extension::custom (accepting the 3 fields of the current struct) or Extension::raw (accepting raw bytes) could make it semantically clear that non-standard extensions are being constructed.

[baloo]

I'm not sure I follow what you're saying here.

Is this to serialize extensions without the OctetString?

[tarcieri]

@baloo well, mostly I thought it might be helpful to make it semantically clear and easily grep-able when custom extensions are being constructed