James, The assertion is not that "removal of whitespace is more correct", but that "removal of whitespace will reduce the risk of validation errors". With the number of participants and implementations involved with processing the SMD's, it's best to reduce the likelihood of errors due to imperfect implementations. -- JG [cid:E8099923-0AE9-4B10-8862-A8AE17579308] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: James Mitchell <james.mitchell@ausregistry.com.au<mailto:james.mitchell@ausregistry.com.au>> Date: Monday, August 5, 2013 7:13 PM To: "Wodjenski, Sharon" <Sharon.Wodjenski@neustar.biz<mailto:Sharon.Wodjenski@neustar.biz>>, James Gould <jgould@verisign.com<mailto:jgould@verisign.com>>, Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Cc: "tmch-tech@icann.org<mailto:tmch-tech@icann.org>" <tmch-tech@icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Subject: Re: [gtld-tech] [tmch-tech] Test SMDs files now available 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@neustar.biz<mailto:Sharon.Wodjenski@neustar.biz>> Date: Tuesday, 6 August 2013 5:05 AM To: "'Gould, James'" <JGould@verisign.com<mailto:JGould@verisign.com>>, Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Cc: "tmch-tech@icann.org<mailto:tmch-tech@icann.org>" <tmch-tech@icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@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@icann.org<mailto:tmch-tech-bounces@icann.org> [mailto:tmch-tech-bounces@icann.org] On Behalf Of Gould, James Sent: Monday, August 05, 2013 1:57 PM To: Gustavo Lozano Cc: tmch-tech@icann.org<mailto:tmch-tech@icann.org>; gtld-tech@icann.org<mailto:gtld-tech@icann.org> Subject: Re: [tmch-tech] Test SMDs files now available Gustavo, My feedback is below. -- JG [cid:image001.png@01CE91EB.D8A5F520] James Gould Principal Software Engineer jgould@verisign.com<mailto:jgould@verisign.com> 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Date: Monday, August 5, 2013 1:28 PM To: James Gould <jgould@verisign.com<mailto:jgould@verisign.com>> Cc: "tmch-tech@icann.org<mailto:tmch-tech@icann.org>" <tmch-tech@icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@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@verisign.com<mailto:JGould@verisign.com>> Date: Saturday, August 3, 2013 7:33 AM To: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Cc: "tmch-tech@icann.org<mailto:tmch-tech@icann.org>" <tmch-tech@icann.org<mailto:tmch-tech@icann.org>>, "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@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@verisign.com<mailto:jgould@verisign.com> On Jul 16, 2013, at 1:41 AM, "Gustavo Lozano" <gustavo.lozano@icann.org<mailto:gustavo.lozano@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-reposito... 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
