With network parameters the CN is no longer needed to identify notaries. This frees it up to be used in the node's name alongside the other attributes.
Also, the identity generation logic has been simplified, removing the need to have magic string values for storing distributed identities in the keystore. Now there are just two alias prefixes: "identity" as it was previously, and "distributed-notary".
* Add roles to X509 certificates so that the identity service can always determine which certificate in a hierarchy is the well known identity
* Rename CLIENT_CA certificate type to NODE_CA
* Rename DOORMAN role to INTERMEDIATE_CA
* Correct issue in CashTests where instead of providing a well known identity to generateSpend(), a confidential identity was passed in and a confidential identity generated from it.
* Enforce role hierarchy in PKI
* Enforce that party certificates must be well known or confidential identities
* Add network map certificate role
* * Document TestIdentity entropy and enforce that it actually works
* Ledger/transaction DSL default notary with fresh key
* MockServices default identity with fresh key
* makeTestIdentityService now takes vararg
* Require cordappPackages for MockServices
* DSL automatic serialization init
* Improve error when two MockNetworks used
* * Make cordappPackages required by MockNetwork
* Default identity service in MockServices
* Make notarySpecs Java-friendly
* Take maximum message size from network parameters
* Add epoch handling
* Add handling of network parameters mismatch
Change NetworkMapClient and updater, add handle in
AbstractNode that results in node shutdown on parameters mismatch. Later
on we should implement proper handling of parameters updates.
Add tests of NetworkParameters wiring.
When node starts with compatibilityZone url configured it takes
networkParameters from the networkMap.
* Permit only one network parameters file
On node startup network parameters are read from node's base directory,
we permit only zero or one files to be there. If network map server is
configured the parameters can be downloaded at startup (if not present
in the directory already).
* Update docs on network map endpoints
* Rename certificate types
* Create separate certificate type for confidential identities
* Add name constraints to dev node CA
* Move dev node CA into getTestPartyAndCertificate()
This removes any need for the user implement and override types from the
super class
* CORDA-786 - Docs update
* CORDA-786 - Remove unneeded second annotation on the proxy objects
* Fix merge conflicts
* new network map object for network map, and verify signature and root in Signed network map and node info
* fixup after rebase
* * added certificate and key to network map server
* move DigitalSignature.WithCert back to NetworkMap.kt, as its breaking API test, will raise another PR to move it back.
* Make DigitalSignature.WithCert not extend WithKey, as per PR discussion.
* various fixes after rebase.
* move Network map back to core/node, as its breaking API test
* revert unintended changes
* move network map objects to node-api
1. The runRPCCashIssue and runWebCashIssue gradle tasks didn't work because they were using the wrong ports
2. Notary lookup was failing because the lookup name didn't include the correct CN for the notary name (this slipped through when reverting the network parameters)
The ports change occurred in #1922 which was attempting the fix the runIssuer gradle task. This is actually a misleading and redundant task as all it does is start up the nodes, which is what the documented deployNodes already does. The ports runIssuer allocated to the nodes were different to the ones specified in deployNodes.
To make sure we have integration tests which closely match deployNodes, the BoC demo has been updated to make use of CordformDefinition. This keeps the node definitions in one place, removing the need to have disparate files in sync. runIssuer has been removed.
Previously when de-anonymising a Party instance, the name of the Party was used rather than
the key, meaning a Party could be constructed with a random nonsense key and any name, and be treated as corresponding to the well known identity. This is not a security hole in itself as
in any real scenario a party shouldn't be trusted without having been registered, it creates
a significant risk of a security hole depending on how trusted the anonymous identity is, and
the returned identity is considered.
