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 ry-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
Gustavo, When will the interface to the TMCH itself be available for testing, please? Thanks, --Roy Dykes From: Gustavo Lozano [mailto:gustavo.lozano@icann.org] Sent: Tuesday, July 16, 2013 01:37 AM To: tmch-tech@icann.org <tmch-tech@icann.org> Cc: gtld-tech@icann.org <gtld-tech@icann.org> Subject: [tmch-tech] Test SMDs files now available 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
Gustavo, In my testing, I was able to successfully validate the active SMD's, successfully confirm the revoked certificate SMD's, and successfully confirm all the invalid SMD's except for two ( InvalidSignature-Court-Agent-French-Active.smd and InvalidSignature-TreatyStatute-Agent-Chinese-Active.smd) that incorrectly validate. Has anyone else found this? -- JG [cid:1F77A6F0-84A7-4C72-A05A-C5BF32C674D1] James Gould Principal Software Engineer 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: Tuesday, July 16, 2013 1:37 AM To: "tmch-tech@icann.org<mailto:tmch-tech@icann.org>" <tmch-tech@icann.org<mailto:tmch-tech@icann.org>> Cc: "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Subject: [tmch-tech] Test SMDs files now available 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
Jim, We came across the same issue with the file InvalidSignature-TreatyStatute-Agent-Chinese-Active.smd. ICANN has published a new archive containing invalid SMDs, dated 23 July, which I believe addresses several issues with the 15 July SMDs. This new archive is available on ICANN's trademark clearinghouse website. We did not test the file InvalidSignature-Court-Agent-French-Active.smd so cannot confirm whether your issue has been resolved. Regards, James James Mitchell Product Owner ARI Registry Services Level 8, 10 Queens Road Melbourne. Victoria. Australia. 3004. Ph: +61 3 9866 3710 Fax: +61 3 9866 1970 Email: james.mitchell@ariservices.com Web: www.ariservices.com From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Gould, James Sent: Wednesday, 31 July 2013 8:25 AM To: Gustavo Lozano; tmch-tech@icann.org Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] [tmch-tech] Test SMDs files now available Gustavo, In my testing, I was able to successfully validate the active SMD's, successfully confirm the revoked certificate SMD's, and successfully confirm all the invalid SMD's except for two ( InvalidSignature-Court-Agent-French-Active.smd and InvalidSignature-TreatyStatute-Agent-Chinese-Active.smd) that incorrectly validate. Has anyone else found this? -- JG [cid:image001.png@01CE8E0F.E1214270] James Gould Principal Software Engineer 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: Tuesday, July 16, 2013 1:37 AM To: "tmch-tech@icann.org<mailto:tmch-tech@icann.org>" <tmch-tech@icann.org<mailto:tmch-tech@icann.org>> Cc: "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Subject: [tmch-tech] Test SMDs files now available 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
James, Thanks, the updated "Invalid SMD" archive dated 23 July are all correctly invalid. The SMD Testing File Overview PDF needs to be updated as well to reference the correct "Invalid SMD" archive. -- JG [cid:8C3FF620-6120-4430-B496-277F2390C6D2] 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: Wednesday, July 31, 2013 4:20 AM To: James Gould <jgould@verisign.com<mailto:jgould@verisign.com>>, Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>>, "tmch-tech@icann.org<mailto:tmch-tech@icann.org>" <tmch-tech@icann.org<mailto:tmch-tech@icann.org>> Cc: "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 Jim, We came across the same issue with the file InvalidSignature-TreatyStatute-Agent-Chinese-Active.smd. ICANN has published a new archive containing invalid SMDs, dated 23 July, which I believe addresses several issues with the 15 July SMDs. This new archive is available on ICANN’s trademark clearinghouse website. We did not test the file InvalidSignature-Court-Agent-French-Active.smd so cannot confirm whether your issue has been resolved. Regards, James James Mitchell Product Owner ARI Registry Services Level 8, 10 Queens Road Melbourne. Victoria. Australia. 3004. Ph: +61 3 9866 3710 Fax: +61 3 9866 1970 Email: james.mitchell@ariservices.com<mailto:james.mitchell@ariservices.com> Web: www.ariservices.com From: gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org> [mailto:gtld-tech-bounces@icann.org] On Behalf Of Gould, James Sent: Wednesday, 31 July 2013 8:25 AM To: Gustavo Lozano; tmch-tech@icann.org<mailto:tmch-tech@icann.org> Cc: gtld-tech@icann.org<mailto:gtld-tech@icann.org> Subject: Re: [gtld-tech] [tmch-tech] Test SMDs files now available Gustavo, In my testing, I was able to successfully validate the active SMD's, successfully confirm the revoked certificate SMD's, and successfully confirm all the invalid SMD's except for two ( InvalidSignature-Court-Agent-French-Active.smd and InvalidSignature-TreatyStatute-Agent-Chinese-Active.smd) that incorrectly validate. Has anyone else found this? -- JG [cid:image001.png@01CE8E0F.E1214270] 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: Tuesday, July 16, 2013 1:37 AM To: "tmch-tech@icann.org<mailto:tmch-tech@icann.org>" <tmch-tech@icann.org<mailto:tmch-tech@icann.org>> Cc: "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Subject: [tmch-tech] Test SMDs files now available 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
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
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? 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? 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 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? Thank you, Gustavo From: <Gould>, James <JGould@verisign.com> Date: Saturday, August 3, 2013 7:33 AM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: "tmch-tech@icann.org" <tmch-tech@icann.org>, "gtld-tech@icann.org" <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
On Jul 16, 2013, at 1:41 AM, "Gustavo Lozano" <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... y-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
Gustavo, My feedback is below. -- JG [cid:AC7E018C-5AE9-4C1A-813B-0525B5C46F71] James Gould Principal Software Engineer 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. 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. 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
Gustavo, My comments also inline tagged with [SEW]. Sharon From: 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; 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
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
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
On 8/6/2013 6:22 AM, Gould, James wrote:
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.
+1 - ferg -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA "Connect and Collaborate" --> www.internetidentity.com
I agree, as well. On 06-Aug-2013, at 9:24 AM, Paul Ferguson <fergie@internetidentity.com> wrote:
On 8/6/2013 6:22 AM, Gould, James wrote:
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.
+1
- ferg
-- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA "Connect and Collaborate" --> www.internetidentity.com
With a good parser none of this should be an issue. Removing unnecessary whitespace and carrier returns will reduce the size Of the resulting payload which is nice. C14N should take care of format before signature validation. Sent from my iPhone On Aug 5, 2013, at 10:28 AM, Gustavo Lozano <gustavo.lozano@icann.org> wrote:
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?
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?
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 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?
Thank you, Gustavo
From: <Gould>, James <JGould@verisign.com> Date: Saturday, August 3, 2013 7:33 AM To: Gustavo Lozano <gustavo.lozano@icann.org> Cc: "tmch-tech@icann.org" <tmch-tech@icann.org>, "gtld-tech@icann.org" <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
On Jul 16, 2013, at 1:41 AM, "Gustavo Lozano" <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
Francisco, It's actually a factor of the XML parser and the DSIG software, where based on my experience white space is a factor for validation. Troubleshooting validation issues is not a trivial task. Removing the extra white space and carriage returns (pretty print) will reduce the size and reduce the risk of validation errors. -- JG [cid:E2B88BF0-2828-4E99-BBF8-D8B5BDCFEAFE] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Francisco Obispo <fobispo@isc.org<mailto:fobispo@isc.org>> Date: Monday, August 5, 2013 3:41 PM To: Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> Cc: James Gould <jgould@verisign.com<mailto:jgould@verisign.com>>, "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 With a good parser none of this should be an issue. Removing unnecessary whitespace and carrier returns will reduce the size Of the resulting payload which is nice. C14N should take care of format before signature validation. Sent from my iPhone On Aug 5, 2013, at 10:28 AM, Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> wrote: 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? 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? 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 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? 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
I agree, I do use XMLSEC and LibXML and have not yet encountered any problems, but I do see it as a source of possible problems, so the least data to be transferred the better. On Aug 5, 2013, at 1:29 PM, "Gould, James" <JGould@verisign.com> wrote:
It's actually a factor of the XML parser and the DSIG software, where based on my experience white space is a factor for validation. Troubleshooting validation issues is not a trivial task. Removing the extra white space and carriage returns (pretty print) will reduce the size and reduce the risk of validation errors.
Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE
I'm also using the XMLSec and LibXML2 libraries and I'm just finishing off the verification of SMD signatures. Slightly OT but the only issues I've encountered are around the 'id' attribute lacking the prescribed 'xml' prefix, I've had to adjust the invocation to XMLSec to get around the reference errors. See section 3.2 of http://www.aleksey.com/xmlsec/faq.html and http://www.w3.org/TR/xml-id/ (dated 9 Sept 2005) Two questions: Has anyone else encountered this? Which libraries is the TMCH using to generate the SMD signatures? Kind regards, Mike O'Connell -- If you don't know where you are going, any road will get you there. On 06 Aug 2013, at 12:34 AM, Francisco Obispo <fobispo@isc.org> wrote:
I agree,
I do use XMLSEC and LibXML and have not yet encountered any problems, but I do see it as a source of possible problems, so the least data to be transferred the better.
On Aug 5, 2013, at 1:29 PM, "Gould, James" <JGould@verisign.com> wrote:
It's actually a factor of the XML parser and the DSIG software, where based on my experience white space is a factor for validation. Troubleshooting validation issues is not a trivial task. Removing the extra white space and carriage returns (pretty print) will reduce the size and reduce the risk of validation errors.
Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE
Mike, It appears your problem is related to signature verification changes we noticed in the recent java 7u25 update. We observed that by not using a validating parser, id uniqueness could not be guaranteed, which resulted in signature verification failures for security reasons. Our solution was to bind the <signedMark> element's id to the validating context, seemingly equivalent to 3) xmlAddID of section 3.2 of http://www.aleksey.com/xmlsec/faq.html. Implementors who are yet to update to the latest java version, or are having trouble doing so, may find the last comment of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017171 useful. I too am interested in knowing the libraries used by the TMCH to generate SMD signatures. Regards, James Mitchell / Product Owner ARI Registry Services From: Mike O'Connell <mcanix@gmail.com<mailto:mcanix@gmail.com>> Date: Wednesday, 7 August 2013 10:47 PM To: Francisco Obispo <fobispo@isc.org<mailto:fobispo@isc.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 I'm also using the XMLSec and LibXML2 libraries and I'm just finishing off the verification of SMD signatures. Slightly OT but the only issues I've encountered are around the 'id' attribute lacking the prescribed 'xml' prefix, I've had to adjust the invocation to XMLSec to get around the reference errors. See section 3.2 of http://www.aleksey.com/xmlsec/faq.html and http://www.w3.org/TR/xml-id/ (dated 9 Sept 2005) Two questions: 1. Has anyone else encountered this? 2. Which libraries is the TMCH using to generate the SMD signatures? Kind regards, Mike O'Connell -- If you don't know where you are going, any road will get you there. On 06 Aug 2013, at 12:34 AM, Francisco Obispo <fobispo@isc.org<mailto:fobispo@isc.org>> wrote: I agree, I do use XMLSEC and LibXML and have not yet encountered any problems, but I do see it as a source of possible problems, so the least data to be transferred the better. On Aug 5, 2013, at 1:29 PM, "Gould, James" <JGould@verisign.com<mailto:JGould@verisign.com>> wrote: It's actually a factor of the XML parser and the DSIG software, where based on my experience white space is a factor for validation. Troubleshooting validation issues is not a trivial task. Removing the extra white space and carriage returns (pretty print) will reduce the size and reduce the risk of validation errors. Francisco Obispo Director of Applications and Services - ISC email: fobispo@isc.org<mailto:fobispo@isc.org> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE
Gustavo, We too agree that removing white spaces would limit the opportunity for validation issues. We certainly had to go through some struggles to validate the test SMDs because of how the parsers were treating white spaces by default. We will support both signed and encoded signed marks. Cheers, Ben From: tmch-tech-bounces@icann.org [mailto:tmch-tech-bounces@icann.org] On Behalf Of Gustavo Lozano Sent: Monday, August 05, 2013 10:29 AM To: Gould, James Cc: tmch-tech@icann.org; 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? 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? 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 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? 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 ________________________________ Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Demand Media, Inc. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
participants (10)
-
Ben Levac -
Dykes, Roy -
Francisco Obispo -
Gould, James -
Gregory Berezowsky -
Gustavo Lozano -
James Mitchell -
Mike O'Connell -
Paul Ferguson -
Wodjenski, Sharon