Initial support for CMPv2 & CRMF

[Taowyoo]

Changes

• Add part of implementation of the Certificate Management Protocol (CMP) as described in RFC 4210, see mod cmpv2.
• Add part of implementation of the Certificate Request Message Format (CRMF) as described in RFC 4211, see mod crmf.
• Add some type implementation of X.509 Public Key Infrastructure Certificate format as described in RFC 5280, see changes in x509.rs.
• • Add some general type implementation, see changes in types.rs.

Tests

• Tests added under cmpv2/message.rs for testing PKIMessage.
• Tests added under x509.rs for testing KeyUsage.

[arai-fortanix]

I have some concerns about whether cert_req_id and the certificate serial number need to be some kind of BigNum. The other feedback is all suggestions.

[arai-fortanix]

Minor: every one of these fields has essentially the same code for serialization, except they each have their own specific tag. Is there some way to reduce the duplicated code? Can you define something like

struct Asn1SerializableOption<V, T> {
    value: Option<V>,
    tag T,
}

impl Asn1SerializableOption<V, T> {
    fn write(writer) {
         if let Some(value) = self.value.as_ref() {
              writer.netxt().write_tagged(Tag::context(self.tag.to_int()), |writer| self.value.write(writer))
        }
    }
}

And then the code for serializing all of the optional fields can just look like

self.message_time.write(writer);
self.protection_alg.write(writer);
self.sender_kid.write(writer);
...

Especially as there seem to be multiple structures with optional fields, something along these lines seems like it has the potential to reduce the amount of very similar code that's being repeated in the serialization functions.

[arai-fortanix]

The other minor benefit to an approach like this is that it explicitly ties the tag value to the field in the declaration of the field in the struct like this:

pub struct PkiHeader<'a, A: SignatureAlgorithm = DerSequence<'static>> {
    pub pvno: Pvno,
    pub sender: GeneralName<'a>,
    pub recipient: GeneralName<'a>,
    pub message_time: Asn1SerializableOption<GeneralizedTime, TAG_MESSAGE_TIME>,
    pub protection_alg: Asn1SerializableOption<A, TAG_MESSAGE_PROTECTION_ALG>,

Without this, it's possible for someone to make a mistake and use the wrong tag constant for a field in either the serializer or the deserializer. With my suggestion, it's still possible for there to be mistakes, but we only have to check one place very carefully. With the tags used in multiple places, there's more likelyhood that a mistake will be made, or that it will slip through code review.

[Taowyoo]

I have a PR for refactoring all these duplicate code using updated derive_sequence macro:
#22

[arai-fortanix]

Deserialization seems like it could use a similar approach I suggested above for serialization to reduce the amount of similar code needed for each field.

[arai-fortanix]

LGTM.

[Taowyoo]

bors r=[arai-fortanix]

[bors]

Build succeeded!

The publicly hosted instance of bors-ng is deprecated and will go away soon.

If you want to self-host your own instance, instructions are here.
For more help, visit the forum.

If you want to switch to GitHub's built-in merge queue, visit their help page.

• continuous-integration/travis-ci/push