From b080d4da3f87a74cc6111915e2dc46d59e64c5f3 Mon Sep 17 00:00:00 2001 From: Shams Asari Date: Mon, 24 Jul 2017 17:59:32 +0100 Subject: [PATCH] Removed out-of-date warnings regarding the switchover to X.500 names --- docs/source/messaging.rst | 13 +++++-------- docs/source/permissioning.rst | 10 ++++------ 2 files changed, 9 insertions(+), 14 deletions(-) diff --git a/docs/source/messaging.rst b/docs/source/messaging.rst index a62d6802c7..2bd301d3bc 100644 --- a/docs/source/messaging.rst +++ b/docs/source/messaging.rst @@ -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 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 -the peer. This allows the flow framework to authentically determine the ``Party`` initiating a new flow. For RPC clients -the validated user is the username itself and the RPC framework uses this to determine what permissions the user has. +validated user is the X.500 subject of the client TLS certificate. This allows the flow framework to authentically determine +the ``Party`` initiating a new flow. For RPC clients the validated user is the username itself and the RPC framework uses +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 - it can provide additional structures for uniqueness. - -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. +The broker also does host verification when connecting to another peer. It checks that the TLS certificate subject matches +with the advertised X.500 legal name from the network map service. diff --git a/docs/source/permissioning.rst b/docs/source/permissioning.rst index 420188c73d..9ab1782f76 100644 --- a/docs/source/permissioning.rst +++ b/docs/source/permissioning.rst @@ -15,12 +15,10 @@ Initial Registration 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. -:myLegalName: Your company's legal name. e.g. "Mega Corp LLC". This needs to be unique on the network. If another node - has already been permissioned with this 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. +:myLegalName: Your company's legal name as an X.500 string. X.500 allows differentiation between entities with the same + name as the legal name needs to be unique on the network. If another node has already been permissioned with this + 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. :emailAddress: e.g. "admin@company.com"