Before going too deep into this, I'm trying to implement a Subject Alternative Names struct, RFC section link here: https://datatracker.ietf.org/doc/html/rfc2459#section-4.2.1.7

General Name here is a CHOICE, with 9 context-specific implicit tags. Several of these tags have the same underlying type.

I'm trying to implement the Encodable/Decodable/Choice traits on my GeneralName enum. I can't use the Choice derive macro because:

• It doesn't include Ia5String as a possible type (my main interest)
• Even if it did, the Choice derive macro does not allow for multiple enum variants of the same intermediate subtype

Having dug into the expanded macro, I think I understand why, so I figured I could implement the traits on my own, but I'm running into trouble implementing TryFrom<Any<'a>>. Code snippet:

    fn try_from(any: Any<'a>) -> Result<Self, Self::Error> {
        match any.tag() {
            der::Tag::Ia5String => any
                .ia5_string()
                .ok()
                .and_then(|val| val.try_into().ok())
                .ok_or_else(|| der::Tag::Ia5String.value_error()),
            actual => Err(der::ErrorKind::UnexpectedTag {
                expected: None,
                actual,
            }
            .into()),
        }
    }

Should the tag requested here be an Ia5String, or do I need to manually interpret the tag? I also don't understand how to interpret implicit context-specific tags, and the ContextSpecific struct seems to set the constructed bit even though, in the X509 certificates I've parsed, none of them do (the tag for each SAN goes 0x82 <len> <value>, where as the ContextSpecific struct always serializes to 0xA2.

RFC 7468 § 2. General Considerations

Data before the encapsulation boundaries are permitted, and parsers MUST NOT malfunction when processing such data.

fixes TODO

• Adds SignedData type to ContentInfo
• Two examples + test cases (Apple MDM Signature and SCEP Request from Apple device) originally BER encoded but reencoded in DER
• Requires x509-cert now for some types

Missing

• Some types (like AttributeCertificateV2) I haven't encountered
• More asserts in the new tests. Currently only tests if e_content ambiguity in PKCS#7 vs CMS standard was handled
• ValueOrd implementation.. what makes sense?

Hi there,

I'm seriously considering using your library to encode lots of f64 data (cf. https://github.com/anise-toolkit , and specifically this flatbuffer example: https://github.com/anise-toolkit/specs/blob/1-draft-0-0-1/ephemeris.fbs ).

I'm brand new to ASN.1, so please excuse novice questions. According to a copy of some specs I found here, https://www.oss.com/asn1/resources/books-whitepapers-pubs/larmouth-asn1-book.pdf, section 2.4 (page 83) talks about a REAL type. The ASN.1 playground also uses that type in their default example: https://asn1.io/asn1playground/ .

However, I don't see it in the docs as one of the supported type (https://docs.rs/der/latest/der/asn1/index.html).

Is the REAL type not supported in DER encoding? Or has it not yet been implemented in this library because it isn't needed for the crypto algorithms?

Thanks

The following are outstanding issues and/or discussion points.

• [x] https://github.com/RustCrypto/formats/issues/322

• [ ] https://github.com/RustCrypto/formats/issues/321

• [ ] I'm not sure about structure naming. I've chosen CertReq. But I think the style of the repo might be the longer CertificationRequest. But this gets pretty long for CertificationRequestDocument. Also, *Info seems to be shortened by this project. So some guidance on the naming would be helpful.

• [ ] I'm only testing this with RSA keys. However, I'm just re-using spki::SubjectPublicKeyInfo. So I think this might be okay.

• [ ] pkcs10::CertReq is incredibly similar to x509::Certificate. These two could be genericized and then they could share an implementation of signature validation. However, I don't know the right crate to put them in. This could also be a future enhancement.

Reproducing DER crate compilation failure

See this repo https://github.com/mishazharov/der-repro for a small test case to show the error

Versions

$ rustc --version
rustc 1.56.0 (09c42c458 2021-10-18)

$ cargo --version
cargo 1.56.0 (4ed5d137b 2021-10-04)

Platform

Kernel: 5.11.0-38-generic Distro: #42~20.04.1-Ubuntu Arch: x86_64

Steps to reproduce

Run wasm-pack build --no-typescript --release.

Error shown

   Compiling der v0.4.4
error[E0277]: can't compare `usize` with `()`
   --> /home/misha/.cargo/registry/src/github.com-1ecc6299db9ec823/der-0.4.4/src/encoder.rs:151:43
    |
151 |         if nested_encoder.finish()?.len() == length.try_into()? {
    |                                           ^^ no implementation for `usize == ()`
    |
    = help: the trait `PartialEq<()>` is not implemented for `usize`

error[E0277]: the trait bound `(): From<Length>` is not satisfied
   --> /home/misha/.cargo/registry/src/github.com-1ecc6299db9ec823/der-0.4.4/src/encoder.rs:151:53
    |
151 |         if nested_encoder.finish()?.len() == length.try_into()? {
    |                                                     ^^^^^^^^ the trait `From<Length>` is not implemented for `()`
    |
    = note: required because of the requirements on the impl of `Into<()>` for `Length`
note: required because of the requirements on the impl of `TryFrom<Length>` for `()`
   --> /home/misha/.cargo/registry/src/github.com-1ecc6299db9ec823/der-0.4.4/src/asn1/null.rs:46:6
    |
46  | impl TryFrom<Any<'_>> for () {
    |      ^^^^^^^^^^^^^^^^     ^^
    = note: required because of the requirements on the impl of `TryInto<()>` for `Length`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `der` due to 2 previous errors
Error: Compiling your crate to WebAssembly failed
Caused by: failed to execute `cargo build`: exited with exit status: 101
  full command: "cargo" "build" "--lib" "--release" "--target" "wasm32-unknown-unknown"

Proposed fix

I did some basic testing and found that patching the encoder with the following line appeared to resolve it on v0.4.4, but I didn't get the chance to test it on master. In https://github.com/RustCrypto/formats/blob/master/der/src/encoder.rs#L159

        Header::new(Tag::Sequence, length).and_then(|header| header.encode(self))?;

        let mut nested_encoder = Encoder::new(self.reserve(length)?);
        f(&mut nested_encoder)?;

+       let len: usize = length.try_into()?;
+       if nested_encoder.finish()?.len() == len {
-       if nested_encoder.finish()?.len() == length.try_into()? {
            Ok(())
        } else {
            self.error(ErrorKind::Length { tag: Tag::Sequence })
        }

I wanted to get some thoughts before opening a PR though because this seems like a bandaid fix. Am happy to open a PR though if the maintainers think this is worth fixing and the fix is acceptable!

Edit: Going to open one anyway because it's easy

Moving code from https://github.com/openmls/tls-codec/

I'm sure there are a couple things in here we want to touch. Some things I noticed

• [x] There's currently only an MIT license. We have to add Apache
• [ ] We should agree on a badge style
• [x] I added CI, let's see if that's working. I also added Windows and macOS targets.
• [x] Are there binaries or why do we have a Cargo.lock?
• [x] There are no-std CI targets. tls-codec wasn't written with no-std in mind so far.

I'm sure there's more. Let me know what you think @tarcieri

I tried writing a function that returns complete AlgorithmIdentifier for the RSASSA-PSS algorithm. However my attempts to write a sensible one have failed up to now, as it's not possible to embed an owned value into the parameters field (AnyRef). I ended up declaring static byte array with the PSS parameters in DER encoding, but it is not really intuitive.

Bumps rstest from 0.12.0 to 0.14.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

NOTE: breaking change.

Previously AlgorithmIdentifier::parameters were always AnyRef. This commit changes them to a generic parameter Params.

An alias AlgorithmIdentifierRef provides a type identical to the original with AnyRef as its parameters, which is used in all of the other crates in this repo.

cc @baloo @lumag

This PR adds the ability to derive the tls_codec traits for enumerations with data. It also adds an attribute to specify what the discriminant should be. The tls_codec_derive crate documentation provides more details. Thank you.

As requested in #813 a test for mixed encoding CMS.

@tarcieri I didn't find my original BER file from the Apple MDM Signature so I just checked the example at https://lapo.it/asn1js/# and it's very similar in that it starts with an indefinite length tag, uses multiple along the way and also uses constructed undefined length OctetStrings.

Both the DER/BER file have the same e_content. Currently the DER encoded file is used in the test and works fine.

Like #821, although probably a different cause: d3eefbcbbcf49867838626e23bb59ca01e305db7 in the Windows CTL fails to parse with:

ASN.1 DER message is too long at DER byte 60

The offending cert, as PEM:

-----BEGIN CERTIFICATE-----
MIIDcTCCAlmgAwIBAgIVAOYJ/nrqAGiM4CS07SAbH+9StETRMA0GCSqGSIb3DQEB
BQUAMFAxCzAJBgNVBAYTAlBMMSgwJgYDVQQKDB9LcmFqb3dhIEl6YmEgUm96bGlj
emVuaW93YSBTLkEuMRcwFQYDVQQDDA5TWkFGSVIgUk9PVCBDQTAeFw0xMTEyMDYx
MTEwNTdaFw0zMTEyMDYxMTEwNTdaMFAxCzAJBgNVBAYTAlBMMSgwJgYDVQQKDB9L
cmFqb3dhIEl6YmEgUm96bGljemVuaW93YSBTLkEuMRcwFQYDVQQDDA5TWkFGSVIg
Uk9PVCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKxHL49ZMTml
6g3wpYwrvQKkvc0Kc6oJ5sxfgmp1qZfluwbv88BdocHSiXlY8NzrVYzuWBp7J/9K
ULMAoWoTIzOQ6C9TNm4YbA9A1jdX1wYNL5Akylf8W5L/I4BXhT9KnlI6x+a7BVAm
nr/Ttl+utT/Asms2fRfEsF2vZPMxH4UFqOAhFjxTkmJWf2Cu4nvRQJHcttB+cEAo
ag/hERt/+tzo4URz6x6r19toYmxx4FjjBkUhWQw1X21re//Hof2+0YgiwYT84zLb
eqDqCOMOXxvH480yGDkh/QoazWX3U75HQExT/iJlwnu7I1V6HXztKIwCBjsxffbH
3jOshCJtywcCAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMC
AQYwHQYDVR0OBBYEFFOSo33/gnbwM9TrkmdHYTMbaDsqMA0GCSqGSIb3DQEBBQUA
A4IBAQA5UFWd5EL/pBviIMm1zD2JLUCpp0mJG7JkwznIOzawhGmFFaxGoxAhQBEg
haP+E0KR66oAwVC6xe32QUVSHfWqWndzbODzLB8yj7WAR0cDM45ZngSBPBuFE3Wu
GLJX9g100ETfIX+4YBR/4NR/uvTnpnd9ete7Whl0ZfY94yuu4xQqB5QFv+P7IXXV
lTOjkjuGXEcyQAjQzbFaT9vIABSbeCXWBbjvOXukJy6WgAiclzGNSYprre8Ryydd
fmjW9HIGwsIO03EldivvqEYL1Hv1w/Pur+6FUEOaL68PEIUovfgwIB2BAw+vZDuw
cH0mX548PojGyg434cDjkSXa3mHF
-----END CERTIFICATE-----

Happy to debug this again, just making the issue for visibility.

Hey, I'm using std::fs::write and its signature looks like that: (it has AsRef generic)

and I think I found one hole in your API:

error[E0277]: the trait bound `SecretDocument: AsRef<[u8]>` is not satisfied
   --> keypair/build.rs:25:55
    |
25  |     fs::write(keys_dir.join("private_key_pkcs1.der"), private_key_der)?;
    |     ---------                                         ^^^^^^^^^^^^^^^ the trait `AsRef<[u8]>` is not implemented for `SecretDocument`
    |     |
    |     required by a bound introduced by this call

Now the developer needs to manually call .as_bytes() for SecretDocument, but Document already has impl AsRef<[u8]> for Document

Suppose I have a struct:

use der::Sequence;

#[derive(Sequence)]
struct MyThing {
   things: Vec<u8>,
   already_encoded: Vec<u8>,
}

How could I add bytes to MyThing.already_encoded that is a Vec that's from some other der::Encode.to_vec()? That is, I have something else already der-encoded (let's say der(thing)), and don't want to have an additional wrapper of der encoded vec of vec of bytes (let's say der(der(thing))).

Hi,

while looking into the pkcs7 crate for a CMS usecase around the Apple world I discovered that their detached signatures use the BER indefinite length encoding for some of the SEQUENCE which of course is not supported by the der crate.

Has there been any thoughts/discussions around if that's something the formats repo should address or if that is out of scope (for now) and left to other crates.

I started with adding the signed-data content to pkcs7 validating against a DER encoded signature and discovered the problem afterwards with the ones Apple generates :( Link to example

Simon

The x509-cert crate currently has a hard dependency on alloc, but several types still have a lifetime which borrows from the input, which precludes one-pass decoding from PEM (where Base64 is decoded directly into owned types) and makes writing things like certificate builders harder.

We could potentially move entirely to types which own their backing data, eliminating lifetimes from all types. We could still potentially have a corresponding set of borrowed e.g. Ref types (see https://github.com/RustCrypto/formats/issues/689), but using owned types would make usage more convenient at the cost of losing zero-copy decoding from DER bytes.