I decided to change tack in #23 and used BouncyCastle's ASN.1 parser instead of using jASN1, whose parser I found too low-level and error-prone. I think we should eventually consolidate things and rewrite the serializer to use BC as well.

The changes should be minimal but there are more important things to be doing at this point so I'#m deferring it.

This should be trivial, since we're already converting the ByteArray to an InputStream internally anyway.

A new feature in Gradle: https://docs.gradle.org/6.2/userguide/dependency_verification.html

I had a go at doing this in #45 but it was failing and I didn't have much time to debug it then.

Such as the default CRC port (21473), and replace the references in the courier and gateway apps.

Per RS-002. The rate limiting extension is not within scope.

We essentially need to port the Certificate.issue() static method and the Certificate.serialize() instance method from the TS implementation, respectively. Doing the former is the bulk of this task -- the latter should be trivial.

We'll also need to have a function like generateRSAKeyPair() to generate RSA keys, otherwise you wouldn't be able to test the issuance of the certificates. The BC implementation should be a lot more succinct than the TS implementation though, something like:

    KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA");
    keyGen.initialize(modulus); // `modulus` should be >= 2048 and default to 2048
    KeyPair key = keyGen.generateKeyPair();

Note that Certificate.issue() shouldn't be be used directly by users of this library. Instead, this method will be wrapped by higher-level functions like issueGatewayCertificate(), which would simply proxy Certificate.issue() to set some fixed values. Those wrapper functions are outside the scope of this task.

By the way, the Certificate.issue() method in TS takes an optional serialNumber and generates a pseudo-random one when it's absent. I've been meaning to remove that parameter and always generate it, as I think that was an unnecessary premature optimisation on my part -- I think most people will never care to set it upfront. So the JVM implementation should ideally generate it automatically without allowing the caller to set it upfront.

Deserialising/parsing certificates is outside the scope of this task. See #10.

Per RS-001: https://github.com/relaynet/specs/blob/master/rs001-ramf.md

See implementation in PoC:

• https://github.com/relaynet/poc/blob/master/core/serialization.js
• https://github.com/relaynet/poc/blob/master/core/_cms.js

I.e., when a plaintext is encrypted with a Diffie Hellman key per the channel session protocol, as opposed to a key in a certificate.

We should abstract the use of Bouncy Castle to prevent the use of invalid or unsafe parameters.

Per RS-001: https://github.com/relaynet/specs/blob/master/rs001-ramf.md

See implementation in PoC:

• https://github.com/relaynet/poc/blob/master/core/serialization.js
• https://github.com/relaynet/poc/blob/master/core/_cms.js

This includes post-deserialisation validation.

See rationale in JS counterpart: relaycorp/relaynet-core-js#644

And make it part of the CIS.

Per RS-018.

For example, Bouncy Castle supports SHA-1 but RS-018 disallows it.

Counterpart in JS library: relaycorp/relaynet-core-js#27

• Configure linter.
• Configure build automation / Gradle.
• Configure test runner.
• Set up Continuous Integration.
• Etc.

To avoid having to do pick the first in the chain; e.g.:

https://github.com/relaycorp/relaynet-gateway-android/blob/c35f78941be4c223c9ca48be7288ae3cda1f4223/app/src/main/java/tech/relaycorp/gateway/domain/courier/RotateCertificate.kt#L30-L32

That way a private key store would only hold private keys with encryption at rest. Certificates and their chains shouldn't be encrypted.

Each entry could also hold zero or more CAs.

CertificateStore API

This is a rough translation of the JS implementation, with support for chains:

• save(certificate: Certificate, chain: List<Certificate> = emptyList()) (concrete, public). It should do nothing if certificate.expiryDate is in the past.
• retrieveLatest(subjectPrivateAddress: String): CertificationPath? (concrete, public). It should return nothing if there's no matching certificate, or if the latest certificate already expired.
• retrieveAll(subjectPrivateAddress: string): List<CertificationPath> (concrete, public). Expired certs should be excluded.
• deleteExpired() (abstract, public).
• deleteCertificates(subjectPrivateAddress: String) (public, may be used for testing). It should delete all the certificates for a given private address.

We'll also need the following data class:

data class CertificationPath(val leafCertificate: Cert, val chain: List<Cert>)

CertificateStore uses

Each CertificateStore instance would be used to store one of the following things:

• Gateway certs. Both the Android Gateway and the awaladroid library will need it.
• Endpoint certs. Awaladroid needs it to store parcel delivery authorisations.

However, the store will be agnostic of these uses as it'd be up to the user of the class.

Changes to PrivateKeyStore

All references to certificates should be removed. It should only deal with private keys going forward.

See: https://specs.relaynet.link/RS-003

Triggered each time there's a new Git tag matching a semver pattern.

Alternatively, do it by hand each time it's needed.

This assumes Maven is already configured in #5.

So it can be used in the courier and gateway apps.

See: relaycorp/relaynet-gateway-android#29 (comment)

See: https://specs.relaynet.link/RS-003#x509-certificate-for-initial-dh-key

• Document install instructions.
• Etc.

We should abstract the use of Bouncy Castle to prevent the use of invalid or unsafe parameters.

See also: https://specs.relaynet.link/RS-018#digital-signature-algorithms

Only support RSA for now.

Per RS-002: https://github.com/relaynet/specs/blob/master/rs002-pki.md

Depends on #2

• Use the Countersignature approach in the JS implementation.
• Use the new OID.
• Detach the plaintext.
• Require the trusted certificates when deserialising.

I.e., when a plaintext is encrypted with the public key in a node certificate, as opposed to the channel session protocol.

We should abstract the use of Bouncy Castle to prevent the use of invalid or unsafe parameters.

See also: https://specs.relaynet.link/RS-018

Since older versions of Android don't support it.

Note that #22 is using LocalDateTime, which isn't supported either.

As a consequence of this change, we should add the "UTC" suffix to Date fields.

And replace the (de)serialisation code implementation in the Android Gateway and the Endpoint lib.

For safety reasons, and to abstract away protocols that are being reimplemented across apps (e.g., gateways).

The litmus test for this is that SessionEnvelopedData and RAMF messages are no longer exported.

JS counterpart: relaycorp/relaynet-core-js#410

They should be deleted to achieve forward secrecy, future secrecy and replay attack mitigation per https://specs.awala.network/RS-003#receiving-subsequent-messages

Also, it'd prefer the disk from filling up.

AwalaNetwork/specs#32

Also create issueCargoDeliveryAuthorization with isCA = false and pathLenConstraint = 0.

The UKM was introduced in #166 but the test is blocked by bcgit/bc-java#1043

And replace custom logic in the Android Courier.