I think views on trust models will differ
from community to community. I'm from the country that brought us
Diginotar, a company which had mostly government customers. I'm sure you
can imagine that they have had some busy weeks this year. The level of
trust in trusted third parties has seen better days. Does a BDX
agreement require the AP operator to store their keys in a HSM ?
Does it require them to obtain security clearance for
any staff with access to the messaging software ? Does it require them to
have regular security audits, penetration tests etc.?
Not all communities need the same level of trust.
I'm in favour of an architecture that is more
fine-grained and supports options, without either compromising security for
those that need it or increasing cost and complexity for those that
don't.
Pim
From:
[mailto:] On Behalf Of Markus
Gudmundsson
Sent: 23 November 2011 12:42
To: Pim van der
Eijk; 'Mike Edwards'; 'Moberg Dale'
Cc: 'Business Document Exchange TC
List'
Subject: RE: [bdx] BDX address recipe
outline.
Thank
you Pim.
I
am not going to comment so much on the DNS issues, but the proposed methodology
works ok, there may be other ways and better to implement it, but I think it is
quite important that the technology does allow fast and relatively simply
updates to the registry, without requiring time-consuming tasks like opening
specific ports on firewalls, etc.
I
think we have to move a little bit away from the idea of ?fixed trading
contracts? and ?closed network lines?. The EU is aiming for higher adoption and
since validation logic for business documents is getting more and more advanced,
we can expect ?electronic invoices? to be much more strictly compliant with
regards to content and business rules than before, and therefore companies
should be able to publish their endpoint for invoices in certain formats and
expect them all to be valid and readable by their system. This could be the
strongest driver for adoption for SMEs.
It
may depend on how strict the network is, how much trust there is. If we assume
that in BDX you can only participate as an Access Point after signing an
agreement dictating responsibilities, then there is certain trust and assuming
the technology is secure enough, spamming and Denial of Service Attacks should
not become a serious issue.
I
am not saying that there should not be a possibility of ?blacklisting? certain
access points or sending parties, however it should not be the default to
promote adoption.
Of
course a ?generic invoice? could be an open endpoint, whereas an industry
specific option, could be restricted to certain parties. I believe a good
registry should have this capability and therefore it should be possible to
publish some business profiles e.g. BII04 (and transactions therein) as ?open?
and other, more specific ?under contract with trading partners?. So I strongly
support either reusing other registry standards, where applicable or
borrowing features and incorporating into the current SMP.
My
views, at least.
Markús
From:
[mailto:] On Behalf Of
Pim van der Eijk
Sent: 23. nóvember 2011 11:04
To: 'Mike
Edwards'; 'Moberg Dale'
Cc: 'Business Document Exchange TC
List'
Subject: RE: [bdx] BDX address recipe
outline.
Today I
can only attend the first part of the meeting, so here is some written input in
case we don't get to discuss this.
First of
all, I think it is not just the people asking questions about, or proposing
alternatives to, the various specifications submitted to this TC who
should provide use cases and requirements. I would even more like to
see some more discussion of (and justification by their authors for) the
requirements and use cases that underly SML/SMP and related specifications
themselves, if memory serves the authors of those specifications
correctly. This will help us all to understand how general and reusable
these specifications are, and find and fix any aspects that perhaps are too
hard-wired to the specific PEPPOL context to be of general
use.
To
elaborate a bit: SML/SMP are not the first or only attempts at
specifications for e-business registry or capability _expression_
functionality, and there are both strong similarities and differences
compared to these earlier approaches. So as a start, an overview that
explains how the design of SML/SMP relates to (and why it differs from)
them would be useful. Some of these differences are interesting, but
not all of them strike me as improvements. I've mentioned before the absence of
the equivalents of ebXML CPP "CanSend"s in SMP. Another is the absence of a
concept of an agreement or service versioning. Without similar
concepts, in BDX, if I publish that I can receive a particular
version of a UBL invoice, how do I express that I only want that option to be
used by a specific limited set of trading partners? How can I
express that I only support a deprecated version for some established partners,
or for partners that sent me a a document of some related type before, but
want others to only use the newer one? How can I express that any
messages from me will be not be sent from any Access Point, but only
from a particular named Access Point that I trust using specific
credentials? Earlier established protocols like CPA support this very well
and are used in production today, I don't see how SML/SMP/BDX handles
this.
As an
analogy: in social networking, someone first has to connect to you before
he/she can send you messages or flood you with their network updates. You
have an option to not accept a connection
invitation. You even have an option to no longer accept invitations at all
(if you've set up your closed community). This seems to be something that
a register-based collaboration architecture should support if it wants to be a
general solution. The majority of e-government networks are closed or
semi-closed, e-procurement networks are the exception rather than the
rule. The OASIS EnergyInterop TC has a party registration service concept,
which could be combined with a limited capability matching/intersection
functionality. And no, I'm not buying that this functionality would be too
complex. SSL has long had a handshake mechanism and is one of the most
widely used Internet protocols. There are even handshakes in Web Services
protocols such as WS-ReliableMessaging. Capability intersection has been
implemented in CPPA and other specifications, all of which could be used or
profiled further if desired.
On the
particular subject of DNS, I read Dale's email (as far as I understand it)
as stating that it can do a lot more than SML/SMP use it for. So for
architectural coherence it might make sense to use it more generally in the BDX
architecture. I would rather raise a different issue: a major
drawback of a system that depends on DNS updates is administration overhead,
because DNS management is often outsourced to hosting providers or telcos. You
cannot typically update DNS records from a business application directly, but
have to go through some (often horribly slow) service management processes,
at best partly automated. Today, in some ebMS 2.0
environments I've worked in, connecting a new partner means writing
a CPA, which is usually simple and done in a few minutes, then waiting
a week or even longer for all the firewall changes, NAT rules etc. to be
implemented. I'm sure they're not looking forward to adding DNS update
dependencies in this mix ...
So I'm
wondering what problem DNS is a problem for. I know it offers scalability,
but is this level of scalability even needed for a business registry?
Previous e-business registry standards failed to take off, but lack of
scalability does not seem to rank highly on the list of reasons why.
Similar business registries, such as the GS1 GEPIR, or the various national
systems of chambres of commerce, seem to not have found the need for it,
yet they process (I have some hands-on experience with this) huge amounts of
queries using regular HTTP-based exchanges.
Pim
From: [mailto:]
On Behalf Of Mike Edwards
Sent: 31 October 2011
17:07
To: Moberg Dale
Cc: Business Document Exchange TC
List
Subject: Re: [bdx] BDX address recipe
outline.
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:
From:
Moberg Dale
<>
To:
Business
Document Exchange TC List <>
Date:
25/10/2011
18:51
Subject:
[bdx] BDX
address recipe outline.
Sent
by:
<>
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
