Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat(x509): add PkiPath type #466

Merged
merged 1 commit into from
Mar 7, 2022
Merged

feat(x509): add PkiPath type #466

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 17 additions & 1 deletion x509/src/certificate.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,9 @@
use crate::{name::Name, time::Validity};

use alloc::vec::Vec;

use der::asn1::{BitString, UIntBytes};
use der::{Enumerated, Sequence};
use der::{Enumerated, Newtype, Sequence};
use spki::{AlgorithmIdentifier, SubjectPublicKeyInfo};

/// Certificate `Version` as defined in [RFC 5280 Section 4.1].
Expand Down Expand Up @@ -103,3 +105,17 @@ pub struct Certificate<'a> {
pub signature_algorithm: AlgorithmIdentifier<'a>,
pub signature: BitString<'a>,
}

/// `PkiPath` as defined by X.509 and referenced by [RFC 6066].
///
/// This contains a series of certificates in validation order from the
/// top-most certificate to the bottom-most certificate. This means that
/// the first certificate signs the second certificate and so on.
///
/// ```text
/// PkiPath ::= SEQUENCE OF Certificate
/// ```
///
/// [RFC 6066]: https://datatracker.ietf.org/doc/html/rfc6066#section-10.1
#[derive(Clone, Debug, PartialEq, Eq, Default, Newtype)]
pub struct PkiPath<'a>(Vec<Certificate<'a>>);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this could use some sort of accessor for the inner Certificates, such as AsRef<[Certificate<'a>]> and/or something that exposes an Iterator<Item=&Certificate<'a>>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tarcieri Like #[derive(Newtype)]? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/RustCrypto/formats/blob/master/der/derive/src/newtype.rs#L78-L92

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, I forgot it was adding Deref/DerefMut impls.

Thinking about that again, doing that unilaterally somewhat defeats the point of having a newtype, since it effectively leaks the inner type and precludes adding your own inherent methods (at least if you want it to be an idiomatic use of Deref).

But that's something we can circle back on another day, I suppose.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent of newtype is to expose the inner type, but allow the outer type to pick up implementations of traits relevant to specific contexts. Of note here is this new type: #479

This is particularly useful where an identical inner type is used in multiple contexts. A primary example of this is Vec<Extension> which has different OIDs in different contexts. The outer type determines which Identifiable instance to give to the inner type.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The intent of newtype is to expose the inner type

This description is antithetical to the typical notion of "newtype", which is to encapsulate the inner type

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tarcieri I don't think the invariants of "newtype" are that well defined. They are commonly used to allow the implementation of a trait from one crate on the type from a second crate within a third crate, which is roughly how we're using them here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implicit deref coercion has somewhat magical and often surprising powers which allow you to transparently treat one type as another, which go well beyond what's typically meant by "newtype". It means you can't encapsulate the inner type, and it's a mandatory part of the public API.

A very common usage of the newtype pattern is to encapsulate another type to keep it out of the public API, so you can upgrade the dependency that provides the inner type without it resulting in a breaking change to the public API of the consumer providing the outer newtype.

2 changes: 1 addition & 1 deletion x509/src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,4 +23,4 @@ pub mod time;

mod certificate;

pub use certificate::{Certificate, TbsCertificate, Version};
pub use certificate::{Certificate, PkiPath, TbsCertificate, Version};