I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

I believe that this document is Not Ready.  The main reason for this is
the editorial concern 1) below.  Due to it I find it difficiult to
complete a proper technical review of the document.  Once 1) is fixed,
I'm happy to take another look and provide final technical feedback.

For easy reference, here is the document that I reviewed:


https://tools.ietf.org/html/draft-ietf-eppext-tmch-smd-03



1) The "Introduction" (section 1) is too thin to give the reader a
useful introduction to the document.  It explains WHAT is described in
the document, but it does not describe for what PURPOSE this is intended
to be used for.  Nor does it give an introduction to the roles of the
various acronyms mentioned, or the terms used.

The document does not explain what a "mark" or a "signed mark" is, which
appears fundamental for understanding any of it.  I can't find anything
in the WG charter that explain what a "mark" or "signed mark" is either.
I also searched through the normative references.

I suggest to add text describing for what purpose this protocol is
intended for, and some context in which it will be useful, and a
reference or definition of the terms used ("mark" and "signed mark").

Further, since section 2 dives directly into XML protocol details, I
believe this document would be greatly improved by having a new section
called "Architecture" that with a few sentences and/or illustration
describe how the solution is actually intended to work and what entities
are involved.  That would be a better place to put some of the security
discussions in (see issue 3 and 6 below).

2) Section 2: Acronyms like XSD should be expanded on first use.

3) Section 2.3: It says that certificates MAY be signed by a CA, but
it does not discuss anything about how a receiver will be able to
trust either the certificate or the CA, nor how the certificate
validation would actually work.  In particular, how would a receiving
entity validate the certificate?  What is the name that the validator
has to look for in the certificate?

4) Section 2.3, re the smd:url, only suggests a HTTP URL.  Wouldn't it
be useful to allow a HTTPS URL to be used?

5) Section 2.1 and 2.3, re mark:voice, mark:fax and smd:voice -- these
descriptions should clarify the format of the phone number.

6) Section 2.3, the algorithm recommendations could probably be
clarified somewhat.  It says:

   SHA256 as suggested by [RFC6194] and RSA-SHA256 SHOULD be used for
   digesting and signing respectively.  The size of the RSA key SHOULD
   be at least 2048 bits.

I don't think the RFC 6194 reference is all that important in this
context.  What matters is the recommendations given.  I suggest:

   The digital signature algorithm used SHOULD be RSA-SHA256 [RFC 4051].
   The size of the RSA key SHOULD be at least 2048 bits.  A valid reason
   for chosing something else would be if RSA-SHA256 would be deemed to
   not provide sufficient security.

7) Regarding section 2.4, I suggest to use RFC 4648 as the reference
for base64.

8) Section 2.5: The example is really long.  Can't you find a shorter
one?  Will people be helped by having this base64 blob in the
document?  Also the section title shouldn't include "Appendix A", this
should be moved to a proper Appendix.

9) Section 3.1 and 3.2: Don't include copyright notice and license,
use the 'BEGIN CODE' and 'END CODE' marker or simply include text
describing that the following is considered code and is available
under the IPR Trust license.

10) The reference for XMLDSIG is the 2008-06-10 version.  Should it
use 1.1 or 2.0 instead?  See 

http://www.w3.org/TR/xmldsig-core1/

 or


http://www.w3.org/TR/xmldsig-core2/



/Simon


Attachment:


signature.asc




Description:

 PGP signature