W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: Comments on 22 June Version...

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Wed, 27 Jun 2001 14:51:48 -0400
Message-Id: <4.3.2.7.2.20010627143826.024c9de8@localhost>
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc: w3c-ietf-xmldsig@w3.org
[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>


> >>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 14:51:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:05 UTC