ENUM Validation Token Format Definition
draft-ietf-enum-validation-token-04

[Ballot comment]
The idea of the infinite validity seems very scary. I would prefer to see the expirationDate not be optionally. My worry is that, it is very likely that expirationDate will not be implemented at all.

I think it would be better of the XML for civil address information lined up with the XML for civic location in geopriv.

The signature seem to be computed across all the data meaning that the tokendata information can not be removed. I can't decide if this is a bug or a feature.

[Ballot discuss]
These are all discuss discuss comments and I will sort them into delete/discuss/comment after the call.

This looks a lot like the the ENUM group is constructing an XML based certificate. However the chaining here is very unclear to me. If the registrarID in the token is reg-4711, does the certificate used to sing the token have to have reg-4711 somewhere in it or will just any certificate do to sign?


From that point of view I'm confused on how validationEntityID and registrarID are kept unique unless this is only meant for used in a walled garden. I have not gone and read the background, I could be just very confused on this. It seems like if these were URI that would resolve it. Similarly, is an registry needed around the methodID.

The idea of the infinite validity certificate seems sort of scary given LNP. I would prefer to see the expirationDate not be optionally.

I think it would be better of the XML for civil address information lined up with the XML for civic location in geopriv.

The signature seem to be computed across all the data meaning that the tokendata information can not be removed. I can't decide if this is a bug or a feature.

[Ballot discuss]
These are all discuss discuss comments and I will sort them into delete/discuss/comment after the call.

This looks a lot like the the ENUM group is constructing an XML based certificate. However the chaining here is very unclear to me. If the registrarID in the token is reg-4711, does the certificate used to sing the token have to have reg-4711 somewhere in it or will just any certificate do to sign?


From that point of view I'm confused on how validationEntityID and registrarID are kept unique unless this is only meant for used in a walled garden. I have not gone and read the background, I could be just very confused on this. It seems like if these were URI that would resolve it. Similarly, is an registry needed around the methodID.

The idea of the infinite validity certificate seems sort of scary given LNP. I would prefer to see the expirationDate not be optionally.

I think it would be better of the XML for civil address information lined up with the XML for civic location in geopriv.

The signature seem to be computed across all the data meaning that the tokendata information can not be removed. I can't decide if this is a bug or a feature.

[Ballot discuss]
These are all discuss discuss comments and I will sort them into delete/discuss/comment after the call.

This looks a lot like the the ENUM group is constructing an XML based certificate. However the chaining here is very unclear to me. If the registrarID in the token is reg-4711, does the certificate used to sing the token have to have reg-4711 somewhere in it or will just any certificate do to sign?


From that point of view I'm confused on how validationEntityID and registrarID are kept unique unless this is only meant for used in a walled garden. I have not gone and read the background, I could be just very confused on this. It seems like if these were URI that would resolve it. Similarly, is an registry needed around the methodID.

The idea of the infinite validity certificate seems sort of scary given LNP. I would prefer to see the expirationDate not be optionally.

I think it would be better of the XML for civil address information lined up with the XML for civic location in geopriv.

The signature seem to be computed across all the data meaning that the tokendata information can not be removed. I can't decide if this is a bug or a feature.

[Ballot discuss]
This specification is silent with respect to RSA key sizes.  To promote interoperability and
ensure a migration path, all implementations need to support 1024 and 2048 bit RSA at a
minumum!  This should apply to both VEs and the Registry.  I would prefer to see text
addressing key sizes in Section 3, but the security considerations section is another
possibility.

The specification is also unclear with respect to conformance requirements with
resoect to digital signature algorithm support.  In section 3, the document specifies:

  Validation Entities MUST be able to sign tokens according to XML-
  DSIG, MUST support at least SHA-256 as the digest algorithm and MUST
  be able to embed X.509 [10] certificates. 

XML-DSIG (RFC 3275) defines RSA-SHA1 and DSA-SHA1.  RSA-SHA256 is
the only signature algorithm with SHA-256 specified in RFC 4051.  (I am
assuming the refernce to 4051 based on the previous paragraph...)  Does
this sentence imply that VEs MUST implement RSA-SHA1, DSA-SHA1, and
RSA-SHA256?

I would suggest calling out RSA-SHA1 and RSA-SHA256 explicitly as
mandatory to implement, and DSA-SHA1 as a SHOULD implement.

[Ballot discuss]
This specification is silent with respect to RSA key sizes.  To promote interoperability and
ensure a migration path, all implementations need to support 1024 and 2048 bit RSA at a
minumum!  This should apply to both VEs and the Registry.  I would prefer to see text
addressing key sizes in Section 3, but the security considerations section is another
possibility.

The specification is also unclear with respect to conformance requirements with
resoect to digital signature algorithm support.  In section 3, the document specifies:

  Validation Entities MUST be able to sign tokens according to XML-
  DSIG, MUST support at least SHA-256 as the digest algorithm and MUST
  be able to embed X.509 [10] certificates. 

XML-DSIG (RFC 3275) defines RSA-SHA1 and DSA-SHA1.  RSA-SHA256 is
the only signature algorithm with SHA-256 specified in RFC 4051.  (I am
assuming the refernce to 4051 based on the previous paragraph...)  Does
this sentence imply that VEs MUST implement RSA-SHA1, DSA-SHA1, and
RSA-SHA256?

I would suggest calling out RSA-SHA1 and RSA-SHA256 explicitly as
mandatory to implement, and DSA-SHA1 as a SHOULD implement.

[Ballot comment]
Section 3.

  Validation Entities MUST be able to sign tokens according to XML-
  DSIG, MUST support at least SHA-256 as the digest algorithm and MUST
  be able to embed X.509 [10] certificates.

I would propose to remove "at least". If one likes to point out that you may also support other algorithms, then add "and MAY support other algorithms". I also think there should be a referene for "SHA-256".

[Ballot comment]
Section 4., paragraph 0:
> 4.  Field Descriptions

  Definitions and descriptions of the elements should use RFC2119
  terminology.

Section 11.2., paragraph 1:
>    [12]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
>          RFC 3730, March 2004.

  Obsoleted by RFC 4930.

[Ballot comment]
From the PROTO write-up:

4. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?
*Not really. Maybe some XML experts could have a look on the final version of this draft.

It would be useful indeed to confirm that some XML expert review happened and record it in the tracker.

IANA Last Call Comments:

Upon approval of this document, the IANA will take the
following Actions:

Action 1:

Upon approval of this document, the IANA will make the
following assignments in the "ns (XML Namespace)" registry
located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration Template Reference
------------- ------------ -------------- ----------
enum-token-1.0 urn:ietf:params:xml:ns:enum-token-1.0
[ Section 8 ] [RFC-enum-validation-token-03]
enum-tokendata-1.0 urn:ietf:params:xml:ns:enum-tokendata-1.0
[ Section 8 ] [RFC-enum-validation-token-03]


Action 2:

Upon approval of this document, the IANA will make the
following assignments in the "schema (XML Schema)" registry
located at

http://www.iana.org/assignments/xml-registry/schema.html


ID URL Filename Reference
------------- ------------ -------- ----------
enum-token-1.0 urn:ietf:params:xml:schema:enum-token-1.0
[ Section 6.1 ] [RFC-enum-validation-token-03]
enum-tokendata-1.0 urn:ietf:params:xml:schema:enum-tokendata-1.0
[ Section 6.2 ] [RFC-enum-validation-token-03]


We understand the above to be the only IANA Actions for
this document.

IANA Last Call Comments:

Upon approval of this document, the IANA will take the
following Actions:

Action 1:

Upon approval of this document, the IANA will make the
following assignments in the "ns (XML Namespace)" registry
located at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration Template Reference
------------- ------------ -------------- ----------
enum-token-1.0 urn:ietf:params:xml:ns:enum-token-1.0
[ Section 8 ] [RFC-enum-validation-token-03]
enum-tokendata-1.0 urn:ietf:params:xml:ns:enum-tokendata-1.0
[ Section 8 ] [RFC-enum-validation-token-03]


Action 2:

Upon approval of this document, the IANA will make the
following assignments in the "schema (XML Schema)" registry
located at

http://www.iana.org/assignments/xml-registry/schema.html


ID URL Filename Reference
------------- ------------ -------- ----------
enum-token-1.0 urn:ietf:params:xml:schema:enum-token-1.0
[ Section 6.1 ] [RFC-enum-validation-token-03]
enum-tokendata-1.0 urn:ietf:params:xml:schema:enum-tokendata-1.0
[ Section 6.2 ] [RFC-enum-validation-token-03]


We understand the above to be the only IANA Actions for
this document.

PROTO Write-up

1. Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication?
*Yes the document has been reviewed by the WG chairs.

2. Has the document had adequate review from both key WG members and key non-WG members?
*Yes, the document was reviewed by WG members as well as other persons. The concepts represented in this document have influence on other documents in the ENUM scene. In addition, a presentation on a recent IETF meeting about the document was given. This document is part of a series on ENUM validation.

3. Do you have any concerns about the depth or breadth of the reviews that have been performed?
*There are no concerns about depth or breadth of the reviews.

4. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?
*Not really. Maybe some XML experts could have a look on the final version of this draft.

5. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up.
*No concerns.

6. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?
*The majority of the working group members have expressed their appreciation of the document. Suggestions from members have been incorporated into the document.

7. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director.
*No, there are no known threats to appeal.

8. Have the chairs verified that the document adheres to all of the ID Checklist items ?
*Yes.

9. Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.)
**References are properly split, there are no normative references to IDs.
However, there are two non-normative references to IDs:
* draft-ietf-enum-validation-arch (Publication Requested)
* draft-ietf-enum-validation-epp (I-D Exists),

10. What is the intended status of the document? (e.g., Proposed Standard, Informational?)
*The intended status is Proposed Standard.

11. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections:
o Technical Summary
o Working Group Summary
o Protocol Quality
Technical Summary (Same as Abstract):

An ENUM domain name is tightly coupled with the underlying E.164 number. The process of verifying whether the Registrant of an ENUM domain name is identical to the Assignee of the corresponding E.164 number is commonly called "validation". This document describes a signed XML data format -- the Validation Token -- with which Validation Entities can convey successful completion of a validation procedure in a secure fashion.

Working Group Summary:

No controversial issues with this document.


Protocol Quality:

* Are there existing implementations of the protocol?

* enum.at implemented a Perl module to handle the Validation Token generation and checking. This is in use in the production ENUM registry for +43, as well as on the side of the registrar sil.at.
* IPcom implemented a Java version of the Token generation for the my-enum.at portal.
* Internic.at interfaces with the ENUM registry using their own implementation.

* Is this protocol used in practice?

The Austrian ENUM registry for +43 is using an earlier version of the protocol. The changes to the current draft were made to support number blocks (as used in closed numbering plans), to make the address format less specific to Austrian needs, and to harmonize the XML tag names as used in other drafts.

* Have a significant number of vendors indicated they plan to implement the specification?

Registrars for 3.4.e164.arpa need to implement this (unless they use the toolkit enum.at is providing).

* Are there any reviewers that merit special mention as having done a thorough review (i.e., that resulted in important changes or a conclusion that the document had no substantive issues)?
Alexander Mayrhofer had a thorough review and provided substantial feedback, which has been incorporated into the document. No substantive issues.