ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2024-12-22 06:17:55 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Removed out-of-date warnings regarding the switchover to X.500 names

Browse Source
This commit is contained in:
Shams Asari 2017-07-24 17:59:32 +01:00
parent dca2274bff
commit b080d4da3f
2 changed files with 9 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/source/messaging.rst
View File

@ -100,12 +100,9 @@ Clients attempting to connect to the node's broker fall in one of four groups:
Artemis provides a feature of annotating each received message with the validated user. This allows the node's messaging Artemis provides a feature of annotating each received message with the validated user. This allows the node's messaging
service to provide authenticated messages to the rest of the system. For the first two client types described above the service to provide authenticated messages to the rest of the system. For the first two client types described above the
validated user is the X.500 subject DN of the client TLS certificate and we assume the common name is the legal name of validated user is the X.500 subject of the client TLS certificate. This allows the flow framework to authentically determine
the peer. This allows the flow framework to authentically determine the ``Party`` initiating a new flow. For RPC clients the ``Party`` initiating a new flow. For RPC clients the validated user is the username itself and the RPC framework uses
the validated user is the username itself and the RPC framework uses this to determine what permissions the user has. this to determine what permissions the user has.
.. note:: ``Party`` lookup is currently done by the legal name. A future version will use the full X.500 name as The broker also does host verification when connecting to another peer. It checks that the TLS certificate subject matches
it can provide additional structures for uniqueness. with the advertised X.500 legal name from the network map service.
The broker also does host verification when connecting to another peer. It checks that the TLS certificate common name
matches with the advertised legal name from the network map service.

10
docs/source/permissioning.rst
View File

@ -15,12 +15,10 @@ Initial Registration
The certificate signing request will be created based on node information obtained from the node configuration. The certificate signing request will be created based on node information obtained from the node configuration.
The following information from the node configuration file is needed to generate the request. The following information from the node configuration file is needed to generate the request.
:myLegalName: Your company's legal name. e.g. "Mega Corp LLC". This needs to be unique on the network. If another node :myLegalName: Your company's legal name as an X.500 string. X.500 allows differentiation between entities with the same
has already been permissioned with this name then the permissioning server will automatically reject the request. The name as the legal name needs to be unique on the network. If another node has already been permissioned with this
request will also be rejected if it violates legal name rules, see `Legal Name Constraints`_ for more information. name then the permissioning server will automatically reject the request. The request will also be rejected if it
violates legal name rules, see `Legal Name Constraints`_ for more information.
.. note:: In a future version the uniqueness requirement will be relaxed to a X.500 name. This will allow differentiation
between entities with the same name.
:emailAddress: e.g. "admin@company.com" :emailAddress: e.g. "admin@company.com"