RE: XKMS: Was: Validation policy in DPV/DPD rqmts

[Peter Williams <peterw@xxxxxxxxxxxx>]

PPP over ATM/Ethernet used in broadband DSL contains a nice 
discovery  protocol. It seems a shame we cant do something 
a little more useful with PKIX like merge IPSEC/IKE tunnel 
and channel setup with PPP over "media" discovery modes and 
perhaps leverage network-discovery techniques to implement 
the DPV/DPD  requirements in support of IKE tunnels/paths 
working alongside PPP setup.  

Effective networking on a large-scale involves merging 
private and switched level 2 net architectures with the  
various Internet Layer 3 ISP architectures. US and European 
Internet backbones are quite different in their 
connectivity achitectures, of course.  This reality has 
major impact upon the needs for cert discovery  mechanisms, 
when cert paths are attempting to help secure virtual  
tunnels and paths for datagrams in real, bridged level-2 
networks, where bridges are operated under different govt 
regulations, have different security policies, tap points 
for cell-level surveillance, etc, or just have simply 
different concepts for linking ISPs to form a public 
infrastructure.

Rather than bicker about XKMS, lets focus on real needs for 
PKI, where some world class IETF engineering is required. 
Fiddling with  ASN.1 and XML msg specs is not the kind of  
engineering IETF should be overly focusing on. We really 
need to address bridging and switching problems which have 
actual requirements  for discovery engineering - 
requirements that are hard  to address, once we scale IPSEC 
for real, for real layer 2 nets.  

If we can make discovery requirements adapt to the network, 
we could make PKI almost useful to IKE or SSL handshakes, 
so that cert discovery can actually play a part in net-
subscriber management, and net-service access control. We 
really need to ensure cert discovery is not a 
directory/DNS-function or application function, but a 
network  function.

Surely, part of the  benefit of putting up a discovery 
service for PKI  applications is enabling the selection of 
cert paths to select the right security context and 
mechanism strength for the traffic type at level 2, at  the 
right QoS, for the bridges and switches and translation 
tables packets  must cross in practice. We cannot expect 
applications to know about any of this (everything is just 
a datagram or a pipe), so we have to focus on the  realtime 
network to gather real requirements for DPV/DPD behaviour.  

In conclusion, Anders, IETF could have lots to contribute 
to a valuable  DPV/DPD protocol. This is not to say that 
W3C will not do just fine in fashioning an application-
layer infrastructure using XKMS, and good luck to them and 
the work. But, we need to focus here on network properties 
to add any real value. A mix of DPD/DPV with cert policies
and qualifiers, feels just about the right toolkit
for all this, to me. The trick is now to formulate 
actual protocol(s) that implement the abstract protocols
of the requirement specs.

Peter.


---------

For historical perspective, if the IETF believed what the "industry" 
said the major trends were in the past (as widely reported and 
endorsed by trade magazines and in industry conferences), we would 
all be communicating via OSI protocols over ATM, or, more recently, 
over 3G wireless!

Steve