[Gen-art] Gen-ART Review of draft-ietf-eppext-tmch-smd-03

Russ Housley <housley@vigilsec.com> Wed, 25 November 2015 22:50 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D40F21B320D; Wed, 25 Nov 2015 14:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hPMrt2FqSq4h; Wed, 25 Nov 2015 14:50:18 -0800 (PST)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net []) by ietfa.amsl.com (Postfix) with ESMTP id BE0E51B320B; Wed, 25 Nov 2015 14:50:17 -0800 (PST)
Received: from localhost (unknown []) by odin.smetech.net (Postfix) with ESMTP id 0B804F24045; Wed, 25 Nov 2015 17:50:07 -0500 (EST)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([]) by localhost (ronin.smeinc.net []) (amavisd-new, port 10024) with ESMTP id I9h3Tpa7szyr; Wed, 25 Nov 2015 17:48:37 -0500 (EST)
Received: from [] (pool-108-51-128-219.washdc.fios.verizon.net []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 235E9F2402A; Wed, 25 Nov 2015 17:49:46 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
Date: Wed, 25 Nov 2015 17:49:35 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <FFFAD0E8-F497-4E06-BCB8-5B666C23286D@vigilsec.com>
References: <46A1A261-E9F4-414D-AAD8-9C85A8B53283@vigilsec.com>
To: draft-ietf-eppext-tmch-smd.all@ietf.org
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/jBbrcEzrRlSPWGcjEVdvTO41ckQ>
Cc: IETF Gen-ART <gen-art@ietf.org>, IETF <ietf@ietf.org>
Subject: [Gen-art] Gen-ART Review of draft-ietf-eppext-tmch-smd-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2015 22:50:21 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

Document: draft-ietf-eppext-tmch-smd-03
Reviewer: Russ Housley
Review Date: 2015-11-25
IETF LC End Date: 2015-12-04
IESG Telechat date: unknown

Summary:  Not Ready

Major Concerns: 

Section 1 needs to be expanded; it needs to provide the answers to the
following questions.  Does the presence or absence of a digital
signature on the mark impact its handling?  What is the purpose of the
digital signature?  Who is applying the signature?  Why are they

In section 2.1, the document says: "A <mark:name> MUST be specified in
case <mark:org> is not specified."  I see two possible ways to interpret
this statement.  One way is that <mark:name> must always be included.
The other way is that <mark:name> must be include if <mark:org> is not.
I think you mean the second interpretation.  Please clarify.

In Section 2.1. the document says: "A <mark:org> MUST be specified in
case <mark:name> is not specified."  As above, there are two possible
ways to interpret this sentence.  Please clarify.

In Section 2.3, there is not enough information provided to validate
the digital signature.  It seems to me that the digital signature can
be validated using the public key of a trust anchor or the public key
obtained from a valid X.509 certification path originating with a
trust anchor.  If I have understood that properly, then RFC 5280 is
needed as a normative reference.  In addition, most protocols that
make use of certificates perform some checks on the certificate
subject name.  If any certificate that chains to the trust anchor is
as good as any other, then this should be stated explicitly.  Otherwise
the checks the determine that this is an appropriate certificate for
this mark need to be specified.

In the IANA Considerations, the authors are listed as the contacts for
the name space and schema registrations.  Since this is a standards
track document, is the IESG a better point of contact for these entries
in the IANA registry?

Minor Concerns:

Section 2.5 has this heading: "Appendix A. base64 encoded signedMark".
If it is intended to be an Appendix, then it should be moved to the
end of the document.

Sections 3.1 and 3.2 include "Copyright (c) 2012 ...".  Is this the
correct year for the copyright?

The Security Considerations might make suggestions about
canonicalization to avoid breaking the XML digital signature.

Other Editorial Comments:

Section 5 talks about "special suggestions".  I have no idea what
that means.