What's needed for 3.1.0 release?

[jmehnle]

What's needed for the 3.1.0 release to happen? Is there anything I can help with?

[sbv-trueenergy]

Cant wait to get rid of the deprecation warning (#124) 👍

[mattsb42-aws]

Bump. @mpdavis @zejn @blag
Any updates on a timeline and/or anywhere you need help to prep for the next release?

[blag]

Sorry I've been so MIA.

I am writing this late at night after a long work week

The last thing I would like to see merged for 3.1.0 is my PR #100. Unfortunately, @zejn and I noted that the PR needs to support RFC8410.

When I attempted to add PEM deserialization support, it looked a lot like this:

I looked into using the pyasn1 package to deserialize Ed25519 keys in RFC8410 format, since we're already depending on that library elsewhere, but it didn't have them built-in. So then I looked into what it would take to add them, and the pyasn1 project directed me to add a compiled module to the pyasn1-modules repository:

compiled ASN.1 modules for different protocols and file formats could be found in the pyasn1-modules repo.

So then I looked into adding a data structure for RFC8410 to pyasn1-modules:

If ASN.1 module you need is not present in this collection, try using Asn1ate tool that compiles ASN.1 documents into pyasn1 code.

So then I looked into using the ans1ate tool to transform the actual RFC8410 definitions into Python code. I created an 8410.asn file [1] and ran the tool on that, but it failed because the ASN definition uses imports from other RFCs, and additional features (I don't remember exactly, this was a few months ago) that the asn1ate tool does not support yet. Unfortunately the asn1ate tool is only alpha quality, and the codebase was confusing when I dug into it a bit.

So then I looked into the imports used by RFC8410, to see if I could get them asn1ated into Python. I figured I could probably concatenate them all together and feed them into asn1ate. But digging through the labyrinth of RFC references I quickly got lost and confused, which then became demoralized and intimidated by the task at hand. I'm just a developer who's trying to make crypto software easier to use, I am not an expert on RFCs and the various standard bodies.

As I was retracing my steps and writing this all out, I did stumble onto the pycrate project, which does seem to have all of the necessary ASN definitions:

• AlgorithmInformation-2009
• PKIX1Implicit-2009
• PKIX1-PSS-OAEP-Algorithms-2009
• CMSAesRsaesOaep-2009

Maybe those can be used to generate a Python definition for RFC8410?

@mattsb42-aws If you would like to help out, please get RFC8410 supported by pyasn-modules.

If you are feeling particularly productive, please open an PR against my personal ed25519 branch that adds serialization/deserialization support. Everything I merge into that branch will become part of this repository's PR #100. Since I did a lot of work on that and I am a bit vain, I would like to get at least partial credit for getting Ed25519 support working.

I'll try to work on this soon, but I can't promise anything. If you can get RFC8410 support working, I'll get the tests for PR #100 passing again.

Once that's merged I will release version 3.1.0 on PyPI and GitHub.

[1] Copied and pasted here for your convenience:

ED DEFINITIONS EXPLICIT TAGS ::= BEGIN

IMPORTS
 SIGNATURE-ALGORITHM, KEY-AGREE, PUBLIC-KEY, KEY-WRAP,
 KeyUsage, AlgorithmIdentifier
 FROM AlgorithmInformation-2009
   {iso(1) identified-organization(3) dod(6) internet(1) security(5)
   mechanisms(5) pkix(7) id-mod(0)
   id-mod-algorithmInformation-02(58)}

 mda-sha512
 FROM PKIX1-PSS-OAEP-Algorithms-2009
   { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-pkix1-rsa-pkalgs-02(54) }

 kwa-aes128-wrap, kwa-aes256-wrap
 FROM CMSAesRsaesOaep-2009
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
     smime(16) modules(0) id-mod-cms-aes-02(38) }
 ;


id-edwards-curve-algs OBJECT IDENTIFIER ::= { 1 3 101 }

id-X25519        OBJECT IDENTIFIER ::= { id-edwards-curve-algs 110 }
id-X448          OBJECT IDENTIFIER ::= { id-edwards-curve-algs 111 }
id-Ed25519       OBJECT IDENTIFIER ::= { id-edwards-curve-algs 112 }
id-Ed448         OBJECT IDENTIFIER ::= { id-edwards-curve-algs 113 }

sa-Ed25519 SIGNATURE-ALGORITHM ::= {
   IDENTIFIER id-Ed25519
    PARAMS ARE absent
    PUBLIC-KEYS {pk-Ed25519}
    SMIME-CAPS { IDENTIFIED BY id-Ed25519 }
}

pk-Ed25519 PUBLIC-KEY ::= {
    IDENTIFIER id-Ed25519
    -- KEY no ASN.1 wrapping --
    PARAMS ARE absent
    CERT-KEY-USAGE {digitalSignature, nonRepudiation,
                    keyCertSign, cRLSign}
    PRIVATE-KEY CurvePrivateKey
}

kaa-X25519 KEY-AGREE ::= {
    IDENTIFIER id-X25519
    PARAMS ARE absent
    PUBLIC-KEYS {pk-X25519}
    UKM -- TYPE no ASN.1 wrapping -- ARE preferredPresent
    SMIME-CAPS {
       TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
       IDENTIFIED BY id-X25519 }
}

pk-X25519 PUBLIC-KEY ::= {
    IDENTIFIER id-X25519
    -- KEY no ASN.1 wrapping --
    PARAMS ARE absent
    CERT-KEY-USAGE { keyAgreement }
    PRIVATE-KEY CurvePrivateKey
}

KeyWrapAlgorithms KEY-WRAP ::= {
    kwa-aes128-wrap | kwa-aes256-wrap,
    ...
}

kaa-X448 KEY-AGREE ::= {
    IDENTIFIER id-X448
    PARAMS ARE absent
    PUBLIC-KEYS {pk-X448}
    UKM -- TYPE no ASN.1 wrapping  -- ARE preferredPresent
    SMIME-CAPS {
       TYPE AlgorithmIdentifier{KEY-WRAP, {KeyWrapAlgorithms}}
       IDENTIFIED BY id-X448 }
}

pk-X448 PUBLIC-KEY ::= {
    IDENTIFIER id-X448
    -- KEY no ASN.1 wrapping --
    PARAMS ARE absent
    CERT-KEY-USAGE { keyAgreement }
    PRIVATE-KEY CurvePrivateKey
}

CurvePrivateKey ::= OCTET STRING


END

[mattsb42-aws]

Thanks @blag, I'll take a look.

[mattsb42-aws]

As I was retracing my steps and writing this all out, I did stumble onto the pycrate project

I'm going to try to avoid this if at all possible. LGPL is...problematic...

[mattsb42-aws]

Bumping here in case it is watched closer: @zejn @blag @mpdavis any thoughts on my comments in #100 re this blocking issue?

[mattsb42-aws]

@zejn @blag @mpdavis Per the discussion in #100, is that still blocking the 3.1.0 release?

[blag]

Resolved by #157. That's where release prep is being done.

[blag]

I don't have permissions to upload to PyPI, but I have emailed @mpdavis to add me as a maintainer there. Once that is done, I will upload it. Until then, I have made a release on GitHub.

[mattsb42-aws]

Thanks for driving this through, @blag :)

[blag]

Ladies and gentlemen, version 3.1.0.

[mpdavis]

Shoutout to @blag for being proactive in getting this out. 👏

[zejn]

Thanks, @blag!