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

[Otmar Lendl <lendl at nic.at>]

On 2005/10/11 16:10, Peter Williams <home_pw at msn.com> wrote:
> 
> 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.

My draft does not specify what which algorithm of XML DSIG MUST be used,
though it suggests RSA-SHA1.

So basically the openess of the Token can vary depeding on the crypto used:

* SHA-1 with a shared symmetrical key:
 
 	Only Registry and VE can validate the signature 

* RSA-SHA1 without a PKI infrastructure:

	Everybody can verify the correctness of the signature, but needs 
	external information on whether that signature should be
	trusted.

* RSA-SHA1 with a PKI

	If the Token is signed with a VE-key whose (included) cert is 
	signed by the NRA's CA-key, then no external info 
	(except that CA-cert) is needed to test and judge a Token.

Right now, we opted for the second option for User ENUM in Austria.

What other word would you use to describe our Tokens?

> 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.

We developed our validation model for the User ENUM case. 

As you note, Carrier ENUM has different requirements which may well
lead to a different solution.

/ol
-- 
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >

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