Subject: [provreg] SMD: Restriction of XML DSIG parameter space ...

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 27 May 2013 14:39:53 +0000

All,

looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft currently doesn't seem to restrict the set of XML Signature parameters to be used. The signature and normalization algorithm examples look surprisingly similar to RFC5105 (written by my colleague Otmar Lendl back in 2006/2007). 

During his journey to implement the signature technoloy in our ENUM registry software, he found out that some options in XML DSIG (particularly the normalization options) are rather cumbersome and error-prone (AFAIR whitespace changes created by the validating XML parser  triggering validation errors, etc.). Based on this practical experience, he restricted the parameter range for XML DSIG in http://tools.ietf.org/html/rfc5105#section-3 of RFC5105, in order to increase interopability. The concept described in RFC5105 has since been validated in implementations of a few ENUM registry installations (servers), as well as their ENUM registrars (clients). 

Since SMD essentially uses the same technology, i'm proposing that the authors also consider restricting the parameter range of XML DSIG in order to reduce implementation effort, and increase interopability.

Comments?

Alex

---

From: Anthony Kirby <[email-masked]>
Date: Tue, 28 May 2013 10:14:03 +0000

+1

interoperability for ENUM tokens was hard to achieve, even with this specified

thanks
Anthony

________________________________________
From: [email-masked] [[email-masked]] on behalf of Alexander Mayrhofer [[email-masked]]
Sent: 27 May 2013 15:39
To: [email-masked]; [email-masked]
Cc: Otmar Lendl
Subject: [provreg] SMD: Restriction of XML DSIG parameter space ...

All,

Comments?

Alex

_______________________________________________
provreg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/provreg

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 28 May 2013 06:06:39 -0700

Alex, all,

Thank you for your feedback.

TMVs (there is only one at the moment) are the only actors generating SMDs
and TMVs must use: xml-exc-c14n, RSA-SHA256, SHA256 and the RSA key size
is 2048 bits. During the LA meeting, we agreed on RSA2048 and SHA256. I
will add text in the new version of the draft to clarify this.

The SMD file downloaded by the TMH from the TMV is encoded in base64 (see
6.4 of draft-lozano-tmch-func-spec). The reason for the base64 encoding is
to mitigate the possiblity that the signature is invalidated by mistake
(e.g. sending the SMD by email).

There is no recommendation/requirement for using an
<smd:encodedSignedMark> instead of <smd:signedMark> in the communication
channel between Registrars and Registries. Maybe a recommendation or
requirement for using <smd:encodedSignedMark> in this channel is worth it?
Maybe the risk is low? Sometimes, it is cheaper wasting CPU cycles
(decoding base64) instead of troubleshooting. Comments?

Regards,

Gustavo

On 5/27/13 7:39 AM, "Alexander Mayrhofer" <[email-masked]>
wrote:

>All,
>
>looking at http://tools.ietf.org/html/draft-lozano-tmch-smd-02, the draft
>currently doesn't seem to restrict the set of XML Signature parameters to
>be used. The signature and normalization algorithm examples look
>surprisingly similar to RFC5105 (written by my colleague Otmar Lendl back
>in 2006/2007). 
>
>During his journey to implement the signature technoloy in our ENUM
>registry software, he found out that some options in XML DSIG
>(particularly the normalization options) are rather cumbersome and
>error-prone (AFAIR whitespace changes created by the validating XML
>parser  triggering validation errors, etc.). Based on this practical
>experience, he restricted the parameter range for XML DSIG in
>http://tools.ietf.org/html/rfc5105#section-3 of RFC5105, in order to
>increase interopability. The concept described in RFC5105 has since been
>validated in implementations of a few ENUM registry installations
>(servers), as well as their ENUM registrars (clients).
>
>Since SMD essentially uses the same technology, i'm proposing that the
>authors also consider restricting the parameter range of XML DSIG in
>order to reduce implementation effort, and increase interopability.
>
>Comments?
>
>Alex
>
>

---

From: "Gould, James" <[email-masked]>
Date: Tue, 28 May 2013 13:29:35 +0000

Gustavo,

My feedback is below.

-- 
 
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

>will add text in the new version of the draft to clarify this.

Providing clarifying text makes sense, but I would make them
recommendations (SHOULD) and not requirements (MUST) to support use of
draft-lozano-tmch-smd beyond the TMCH. I believe this should not be much
of an issue considering that there is a single set of producers following
the same policies. 

>(decoding base64) instead of troubleshooting. Comments?

I assume that you mean adding this as a requirement in
draft-lozano-tmch-func-spec.  I recommend not adding a requirement to use
<smd:encodedSignedMark> instead of <smd:signedMark>, since
draft-tan-epp-launchphase-11 supports both and there are performance
advantages to using <smd:signedMark> over <smd:encodedSignedMark>.  It
would be up to server policy whether to support both
<smd:encodedSignedMark> and <smd:signedMark>, where I see for TMCH
interoperability that <smd:encodedSignedMark> must be supported.  The
<smd:signedMark> can be an option if performance is a factor based on
server policy and based on the preference of the client.