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

[Otmar Lendl <lendl at nic.at>]

On 2005/10/11 03:10, Peter Williams <home_pw at msn.com> wrote:
> 
> I have not read the I-D, deliberately, but I did read anbd re-read the 
> summary. 

You might want to read the architecture draft by Mayrhofer/Hoeneisen.
(ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-enum-validation-arch-00.txt)

My token draft operates within the role models and trust-relationships 
defined there.

> have retain open mind before I review the text formally:
> 
> The summary says: a validation token conveys (securely) information 
> pertainting to the completion of a validation method, by a Validation 
> Entity. Presumably, the token conveys the result of the validation, and 
> induces the relying party to verify the authority of the token's issuer.
> 
> Becuase the security (of the token's communication) depends upon signed 
> XML, we know that the token's origin authentication depends itself on the 
> relying party first authenticating the token signature's verification key 
> (assuming that the signing method for the XML stream depends on crypto).
> 

> (a) are we assuming that ENUM and/or secure DNS protocols shall be used to 
> distributed information allowing relying parties to authenticate signature 
> verification keys, identifed as being associated with the authority of 
> particular Verification Entities to issue Verification Tokens?

No.

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

It's only the Tier1 registry which really has to check the validity
of a Token while processing a delegation request. If that check
goes though, the domain is delegated in a normal fashion. 

You have to separate the questions

* who is authorized to act as a VE? (i.e. whose Tokens will be trusted and
  accepted by the Registry?)

* how does the Registry makes sure that the Token it receive is authentic?

Both are local policy choices. In the case of Austria's +43 ENUM
production system, the answers are:

* Prospective VEs have to sign a contract with the Registry. The content
  of that contract derives from the NRA's contract with the Registry.

* The VE uses out-of-band mechanisms to send its X.509 Cert to the
  Registry. The Registry will then accept all Token signed with the
  corresponding key. 

> (c) are we assuming that trust model for distributing the signing/issuing 
> authority of Verification Entities shall be "tied to" (or derived from) the 
> the number issuing hierarchy, for the identities being Verified?

Local policy choice. From a technical point of view, it's the Tier1
Registry which decides what to do. On the policy side, the Registry
always has to act within the framework set by the NRA. After all
the NRA is the one who decided (via the IETF/RIPE/ITU agreement) who
can run the Tier1 registry.

> (d) What IETF disclosures, discussions or contacts have there been between 
> IAB and ISO concerning the relationship of the trust model, providing for 
> authentication of the tokens conveying an Verification Entities 
> confirmation of the domain-name<->E.164 identity?

As this model does not in any way touch the delegation of country-code
ENUM domains from the Tier0, everything happens in the Tier1 space.

This draft only proposes how individual countries can structure the
local role model and provisioning protocols *within* that country's 
ENUM domain.

/ol

(NRA = National Regulatory Authority)
-- 
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >

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