Re: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt

["Peter Williams" <home_pw at msn.com>]

> From: Otmar Lendl <lendl at nic.at>
> To: enum at ietf.org
> Subject: Re: [Enum] I-D ACTION:draft-ietf-enum-validation-token-00.txt
> Date: Tue, 11 Oct 2005 11:25:19 +0200
>
> >From my draft:
>
> 	Whether the Registry acts as a certificate authority, accepts certs
> 	from a public CA, or only accepts pre-registered keys is a local policy
> 	choice.
>
> > (b) is reliance on a Verification Token a matter for the public, or is
> > reliance on the signature/token intended to be limited to only those
> > parties authorized by the Verification Entity?
>
> I'm not sure whether I understand the question here.

We tend to think of digital signatures as Ron Rivest first characterized 
them, for RSA: replacement for contract signing, where email text (or 
html/xml) plays the role of the piece of paper bearing the contract terms. 
Anyone can verify the signature, as such openness of usage is part of the 
signature function: acknowledge that real people having signed terms on 
paper, forming agreement ands contracts, so disputes are handled using 
normal social processes involving evidence and proof of signing intent.

In the case of RSA-based certs, DESMAC-based OCSP responses and other 
crypto-based signing technologies, which can implement Validation Tokens, we 
may or may not wish the signed token to be a "public" object, that anyone 
can verify as a proof of something having occured: e,g. validation of the 
E.164<->d-n identity.

The term "token" implied to me (given ISO uses this term carefully) that we 
were not intending the object to serve as a proof object (which assumes 
public proving processes), but - like an SSL signed token for client auth - 
its signature may be designed for only one party to consume, in the context 
of earlier protocol exchanges.

Ill read the architecture draft next. Whats in my mind is understanding the 
type of validation infrastructure that is being planned; and, whether there 
is any difference in the deployement models of the Validation Infrastrcuture 
for the User vs Carrier ENUM cases - given we now have the Carrier ENUM 
variant to address in the security model.

------

Some Thoughts:

In Carrier ENUM, we are dealing with largely closed systems, closed to 
create a system which satisfies high minimum levels of QoS via controlled 
peering, in which any security tokens used and shared amongst computers in a 
provider community (e.g. GSM) may be largely hidden from end users. All 
disputes within the telematic system involving ENUM will be handled using 
_regulated_ dispute arbitration, like any other PTT-based telco service. The 
notion of "reliance" on the Validation Token may be mute, as all reliance 
and its legal implications within the regulatory framework is defined by the 
regulator. Many of the legal and policy issues that surrounded certs and 
signatures in the e-commerce space may be irrelevant, as Carrier ENUM is 
intended to be a closed system - and a closed reliance system, at that.

In User ENUM, we have a different set of issues, where Validation Tokens may 
be called upon during a dispute to prove something - for one or other party 
to the dispute. If that argument is free form, and in open litigation, we 
have a token issuing and use/reliance environment similar to the world of 
e-commerce: which will require a different set of controls to limit the 
issuer's risks, and controls on who can and who cannot either use or rely 
upon the tokens for particular purposes.

Peter.



_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum