search

iho-ohi / 98-interoperability

A repository to discuss issues to S-98 Product Specification of IHO
10 stars 0 forks source link

MRN Structure in X-509 certificates #44

Open HolgerBothien opened 1 month ago

HolgerBothien commented 1 month ago

In S-98 Annex C ; C-9.1.1 the structure of an URN is described to be put in a CN field of the X-509 certificate. The structure IS: urn:mrn:iho:aa:1810 where aa is the alpha-numerical producer code and 1810 is the numerical producer code.

In general I support the idea to include the producer code in the certificate. But I see a few problems with the proposed solution.

  1. Why both codes are included here, one would be enough to unambiguously identify the producer.
  2. The larger problem is that an URN as used here defines a tree and that is not considered here. Each token defines a node in a tree and also a namespace (e.g. iho : is the namespace for any identifier the IHO is responsible for.) using the producer code directly in the next level of the tree defines a namespace but the semantic is not clear. It is not clear that the element is a producer code. And in addition, each code cannot be used anymore as a registered sub element under the iho namespace.

My proposal is to amend the URN as follows: urn:mrn:iho:producerCode:aa

Alternatively, the CN field could contain only the producer code.

If using an URN it should be done in a proper way, the currently used structure more or less destroys the concept of MRNs for the IHO from day one. :-(

rmalyankar commented 1 month ago

This refers to the draft 1.2.0 of Annex C which was circulated only by email. It would save time to have that on GitHub. I recommend either submitting a pull request or Yong or I should be able to post it here (unless there is an objection for some reason).

kusala9 commented 2 weeks ago

I've (finally) got access to the repository so I've upload the two subsequent versions in preparation for the next S-164/S-98 meeting.

in terms of this issue I think the phrase "more or less destroys the concept of MRNs for the IHO from day one. :-(" is a slightly harsh :-) I agree the IHO could use a specific namespace for producer codes as suggested but the proposed (and agreed) namespace doesn't stop them from using MRNs in the future. The issue is that IHO has no agreed guidance for MRN (although a lot of dicusssion has been had in the past about it). The main task they have is to delegate MRN namespaces to each data producer in an agreed way (hopefully along the same lines as they do with FOID). So, I suggest IHO has some time to establish a way of dividing up their urn:mrn:iho: namespace and then if that requires a producerCode namespace we can define one - however, the risk of delay is far greater. Hence the solution we have, which was agreed by NIPWG and S100WG. November S100WG is probably the last chance to change this (and also bear in mind the IHO secretariat have software that uses these agreed namespaces so would require change (but I agree it's small)). I will bring up the concept at the NIPWG VTC next week at the MRN update.