[gtld-tech] [tmch-tech] Test SMDs files now available

Mon Aug 5 23:13:29 UTC 2013

We had no issues with validation of SMDs containing whitespace. Leaving whitespace in would marginally reduce our support costs, however it appears that more people would rather it is removed.

I disagree with the assertion that removal of whitespace is more correct. Validation failures due to whitespace is an indication of a defective implementation. Transformation the SMD XML document prior to signature validation, such as into an object then back into an XML document, is likely subject to further defects.

We support only base64 encoded marks.

Regards,
James Mitchell / Product Owner
ARI Registry Services

From: <Wodjenski>, Sharon <Sharon.Wodjenski at neustar.biz<mailto:Sharon.Wodjenski at neustar.biz>>
Date: Tuesday, 6 August 2013 5:05 AM
To: "'Gould, James'" <JGould at verisign.com<mailto:JGould at verisign.com>>, Gustavo Lozano <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>>
Cc: "tmch-tech at icann.org<mailto:tmch-tech at icann.org>" <tmch-tech at icann.org<mailto:tmch-tech at icann.org>>, "gtld-tech at icann.org<mailto:gtld-tech at icann.org>" <gtld-tech at icann.org<mailto:gtld-tech at icann.org>>
Subject: Re: [gtld-tech] [tmch-tech] Test SMDs files now available

Gustavo,

My comments also inline tagged with [SEW].

Sharon

From: tmch-tech-bounces at icann.org<mailto:tmch-tech-bounces at icann.org> [mailto:tmch-tech-bounces at icann.org] On Behalf Of Gould, James
Sent: Monday, August 05, 2013 1:57 PM
To: Gustavo Lozano
Cc: tmch-tech at icann.org<mailto:tmch-tech at icann.org>; gtld-tech at icann.org<mailto:gtld-tech at icann.org>
Subject: Re: [tmch-tech] Test SMDs files now available

Gustavo,

My feedback is below.

--

JG

[cid:image001.png at 01CE91EB.D8A5F520]

James Gould
Principal Software Engineer
jgould at verisign.com<mailto:jgould at verisign.com>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Gustavo Lozano <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>>
Date: Monday, August 5, 2013 1:28 PM
To: James Gould <jgould at verisign.com<mailto:jgould at verisign.com>>
Cc: "tmch-tech at icann.org<mailto:tmch-tech at icann.org>" <tmch-tech at icann.org<mailto:tmch-tech at icann.org>>, "gtld-tech at icann.org<mailto:gtld-tech at icann.org>" <gtld-tech at icann.org<mailto:gtld-tech at icann.org>>
Subject: Re: [tmch-tech] Test SMDs files now available

James,

Let me discuss this with the development team, but before, I want to have feedback from the community about the following:

I suppose that also the carriage returns should be eliminated and not only white spaces. This will create big lines (between 8K and 16K bytes). Does anyone foresee implementation problems with big lines of text?

That is correct that no extra white space or carriage returns should be included (pretty printing), since including it introduces validation risk when unmarshaling and marshaling the data.  I do not believe the size of the lines should be an issue.

Has anyone have had success in using the test SMD XML (with the white spaces and carriage returns) in their EPP implementations including client libraries?

I have in the Launch EPP SDK although after changes.  The existing Launch EPP SDK holds the attributes of the signed mark and encoded signed mark in attributes of a class, where the marshaling (encoding) and unmarshaling (decoding) is done without keeping a full copy of the source DOM tree.  Re-marshaling of the data will remove the extra white space and carriage returns, whether it's a signed mark or encoded signed mark, thus resulting in invalidating it.  I have updated the Launch EPP SDK to include an immutable signed mark that will hold the full copy of the source DOM tree to keep the extra white space and carriage returns.  The changes allow for the creating of signed marks from scratch and the parsing of signed marks with and without extra white space and carriage returns.  Other client side and server side implementations might have to make similar adjustments to deal with the extra white space and carriage returns.
[SEW] We, too, had to make changes to the RTK to accommodate the white spaces/carriage returns and agree with Jim that the correct thing to do is remove white spaces and carriage returns from the SMD.

Even without whitespaces and carriage returns there is still risk that implementations may break the signature if precautions are not taken. One possibility for mitigating this problem is requiring Registrars to send the base64-encoded blob from the SMD file (decoding base64 sounds cheaper than customer support).

I believe the best answer is to simply not add the extra white space and carriage returns in the signed mark XML within the SMD's.  Since the SMD's base64 encode the signed mark, there is absolutely no benefit in pretty printing the signed mark XML.  We all know that white space is significant with XML signatures, so pretty printing the XML prior to base64 encoding it introduces additional validation risk with no perceived value.

I have received questions about the use of <smd:signedMark> vs <smd:encodedSignedMark> in EPP.

My question to all of you is:
How many of you will require <smd:signedMark>-only by policy?
How many of you will require <smd:encodedSignedMark>-only by policy?
How many of you will support both?

We will support both.  I believe the problem of pretty printing the signed mark XML prior to base64 encoding it is independent of what the servers will require by policy since anyone can decode the base64 encoded signed mark.  If adding the pretty printing of the signed mark XML is not needed and including the pretty printing increases the risk of validation errors, then the pretty printing the signed mark XML should be removed.
[SEW] We will support both.

Thank you,
Gustavo

From: <Gould>, James <JGould at verisign.com<mailto:JGould at verisign.com>>
Date: Saturday, August 3, 2013 7:33 AM
To: Gustavo Lozano <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>>
Cc: "tmch-tech at icann.org<mailto:tmch-tech at icann.org>" <tmch-tech at icann.org<mailto:tmch-tech at icann.org>>, "gtld-tech at icann.org<mailto:gtld-tech at icann.org>" <gtld-tech at icann.org<mailto:gtld-tech at icann.org>>
Subject: Re: [tmch-tech] Test SMDs files now available

Gustavo,

In reviewing the sample SMD's I notice that the decoded signed marks are pretty printed with spaces.  I recommend that no spaces be used with the signed marks since it introduces additional risk of validation errors.  The spaces do not add any value since they are base64 encoded and software could pretty print the XML if needed outside of the validation flow.

JG

James F. Gould
Principal Engineer
Verisign

jgould at verisign.com<mailto:jgould at verisign.com>

On Jul 16, 2013, at 1:41 AM, "Gustavo Lozano" <gustavo.lozano at icann.org<mailto:gustavo.lozano at icann.org>> wrote:
Colleagues,

Information about the recently published test SMDs files can be found in the following link:
http://newgtlds.icann.org/en/about/trademark-clearinghouse/smd-test-repository-15jul13-en.pdf

The different parties involved in the TMCH project have developed test SMDs files in order to obtain feedback from the community and assist implementers of the SMD technology in testing their own implementations. These test SMDs files have been generated using the same models of HSMs (ICANN-TMCH-CA and TMV) that are going to be used in production. The code used to generate them is the latest version of the TMCH code developed by the different parties involved in the TMCH project. These test SMDs files should cover the different test cases and comply with http://tools.ietf.org/html/draft-lozano-tmch-smd-02

We appreciate your feedback no later than July 23, please test them and send your feedback to the mailing list or to me privately. We understand that this is a short period of time and any bug found after this date will be corrected, but it is extremely helpful if you could send your feedback before this date.

Note: These test SMDs files include the TMV and CA certificate embedded in the XML, new test SMDs files are going to be generated soon in order to remove the CA certificate. The inclusion of the CA certificate in the SMD file should not have an impact on the tests performed with these SMDs files.

Thank you,
Gustavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20130805/2c253b7c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4109 bytes
Desc: image001.png
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20130805/2c253b7c/image001-0001.png>