Re: [tmch-tech] SMD: Restriction of XML DSIG parameter space ...

Gustavo,

My feedback is below.

-- 
 
JG
 

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





On 5/28/13 9:06 AM, "Gustavo Lozano" <[email protected]> wrote:

>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.

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. 

>
>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?

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.

>
>Regards,
>
>
>Gustavo
>
>On 5/27/13 7:39 AM, "Alexander Mayrhofer" <[email protected]>
>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
>>
>>

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