Re: Comments on 22 June Version...

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Message-Id:  <4.3.2.7.2.20010627143826.024c9de8@localhost>
Date:  Wed, 27 Jun 2001 14:51:48 -0400
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  w3c-ietf-xmldsig@w3.org
In-Reply-To:  <200106261137.HAA0000078863@torque.pothole.com>
References:  <Your message of "Mon, 25 Jun 2001 14:51:08 EDT." <4.3.2.7.2.20010625144353.00b28c30@localhost>

>[resulting new revision: 1.88]
>
>At 07:37 6/26/2001, Donald E. Eastlake 3rd wrote:
>> >I think you mean 4.3.3.4? We dropped the XLST element, <stylesheet> can be
>> >included by the app.
>> >http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0025.html
>>
>>Yes, I meant 4.3.3.4. I said nothing about an XSLT element.  There is
>>a sytlesheet element.  For consistency, "stylesheet" should appear in
>>the Schema for Transform.  Otherwise, what namespace is it in? Why
>>should this be the application's problem?
>
>I'm still not understanding, 6.6.5 says, "The normative specification for 
>XSL Transformations is [XSLT]. The XSL transformation is encoded within a 
>namespace-qualified stylesheet element which MUST be the sole child of the 
>Transform element." Transform permits ANY, so you'd have
>
><ds:Transform>
>   <xsl:stylesheet version="1.0"
>     xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>       ....
>     </xsl:stylesheet>
></ds:Transform>

OK. That meets our criterion that such parameter child elements must
be in the dsig namespace or an algorithm specific namespace. I belive
that such an example should be included or the text should make it
clear that the stylesheet element is in that XSL namespace.

Thanks,
Donald

>> >>Maybe I'm just missing something but why, in 4.4.3, does it say that
>> >>keying information obtained by a RetrievalMethod "may need to be
>> >>canonicalized"? Even if the KeyInfo is signed, the signature is over
>> >>the RetrievalMethod element and content, not over what is retrieved,
>> >>right?
>> >
>> >I think this is because you "may" sign the data obtained by 
>> RetrievalMethod.
>>
>>If you signed it, it would only be because it was pointed at by a
>>Reference. The signing of it would have nothing to do with
>>RetrievalMethod.  This wording is confusing and should drop references
>>to canonicalization.
>
>Ok.
>
>/- Note, if the result of dereferencing and transforming the specified 
>URI  is a node set, it may need to be canonicalized. Consequently the 
>Signature application is expected to attempt to canonicalize the nodeset via 
>the The Reference Processing Model (section 4.3.3.2) -/
>
>> >>Section 4.4.5: Seems a bit odd in just saying that PGPKeyID is a
>> >>string.  Actually, I belive, PGPKeyID's are 8 octet binary quantities
>> >>so it would seem like it should say they are Base64 encoded...
>
>Ok:          <element name="PGPKeyID" type="base64Binary"/>
>
>--
>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Wednesday, 27 June 2001 22:38:19 UTC