Re: [bdx] BDX address recipe outline.

[Mike Edwards <mike_edwards@uk.ibm.com>]

Dale,

I don't mean to be rude, but your post
sounds like a solution looking for a problem.

Just because DNS permits the approach
you describe, it isn't clear to me what real usecases are dealt with using
this sort of technique.  Perhaps
you could cover the major usecases that you see addressed by such a solution?


As far as the cryptographic hash is
concerned, if my memory serves me correctly, it was introduced somewhat
unwillingly
into the PEPPOL model once we realized
that there were types of participant ID that could not be accommodated
in
standard address strings used for DNS
lookups.  The hash technique chosen has the advantage of always generating
a string that works for the lookup while
at the same time being available ubiquitously and so easily accessible
to any
software looking to implement the PEPPOL
protocols.  The masking of the ID for commercial purposes was not
part of
the considerations as far as I recall.


Yours, Mike

Dr Mike Edwards		Mail Point 137, Hursley Park
STSM		Winchester, Hants SO21 2JN
SCA, Cloud Computing & Services Standards		United Kingdom
Co-Chair OASIS SCA Assembly TC
Chair UK ISO SC38 mirror committee (Cloud & SOA)
IBM Software Group
Phone:	+44-1962 818014
Mobile:	+44-7802-467431 (274097)
e-mail:	mike_edwards@uk.ibm.com

From:	Moberg Dale <dmoberg@axway.com>
To:	Business Document Exchange TC List <bdx@lists.oasis-open.org>
Date:	25/10/2011 18:51
Subject:	[bdx] BDX address  recipe outline.
Sent by:	<bdx@lists.oasis-open.org>

---

In this message, a way to use IETF DNS
functionality for the BDX address resolution is sketched.  The resolution
using a canonical concatenated string of bdx metadata that has been made
opaque (in whole or part) by using a cryptographic hash. Apparently this
masking has been required  to meet some commercial concerns about
not disclosing what organizations use which providers).
 
The main point here is to show that BDX
address lookup requirements are met by using a known registry (DNS) with
known internet scalability and manageability, using already existing approved
standards.
 
By analogy with ENUM, (see information
box below for an introduction to ENUM from voip-info.org), we can therefore
concatenate BDX service metadata identifiers to a string in a canonical
way, use sha-256 to produce a resource identifier, introduce a DNS NAPTR
record for that identifier in the “peppol.org” domain or whatever , do
a DNS query on the resulting value, and  resolve in a standardized
way (indicated by the “A” flag of the NAPTR record) to A, AAAA or A6
address records. 
 
(For extra spice, add DNSSEC to prevent
cache poisoning at the “peppol.org” domain. Use DANE for DNS based PKI
if desired for TLS. Many variations are possible for the NAPTR string on
 concatenation order, separators, hashing procedures to meet visibility
or nondisclosure concerns. Another variation would insert a “S” flag
in the NAPTR RR, and then look up SRV records for a domain name key, from
which address records would be obtained. This additional step would allow
multiple BDX servers to be advertised for a provider, e.g.)
 
IETF has evolved DNS to support many use
cases beyond simple FQDN to Inet address lookups. Isn’t it preferable
to actually use DNS, its query system, and its zone update management procedures
instead of creating a hybrid Web Service and DNS mashup for a use case
that is already easily handled by a simple profile of current specifications?
 
 
From http://www.voip-info.org/wiki/view/ENUM
 
You can dial a telephone number and reach
a SIP,
H.323
or any other Internet Telephony user. This all happens in the background;
you do need to do anything special while calling someone.

A server with ENUM support will lookup a dialed telephone number in the
ENUM tree of the DNS to see if there's alternate ways to set up the call
instead of just calling out on the PSTN
telephone line. ENUM may contain a reference to a SIP
URI, a telephone number to dial,
a web page or an e-mail address.

Enum uses DNS
NAPTR resource records.
 
DNS NAPTR resource records are documented
in RFC 2915: This document describes a Domain Name System (DNS) resource
record which specifies a regular _expression_ based rewrite rule that, when
applied to an existing string, will produce a new domain label or Uniform
Resource Identifier (URI). […] This allows the DNS to be used to
lookup services for a wide variety of resource names (including URIs) which
are not in domain name syntax. Reasons for doing this range from
URN Resource Discovery Systems to moving out-of-date services to new domains.

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU