RE: Attribute encryption

I also agree that XSLT is useful for encrypting arbitrary fragments, but
the use of XSLT will impact on decryption performance because, before
decrypting encrypted data, a whole document containing the encrypted data
has to be parsed into a tree to resolve XPathes in a stylesheet.  This may
be serious for some applications ...

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
E-mail: imamu@jp.ibm.com



From: Philip Hallam-Baker <pbaker@verisign.com>@w3.org on 2001/01/10 01:53

Please respond to Philip Hallam-Baker <pbaker@verisign.com>

Sent by:  xml-encryption-request@w3.org


To:   "'Ed Simon'" <ed.simon@entrust.com>, Philip Hallam-Baker
      <pbaker@verisign.com>, "'Joseph M. Reagle Jr.'" <reagle@w3.org>,
      Sanjeev Hirve <shirve@cyberelan.com>
cc:   xml-encryption@w3.org
Subject:  RE: Attribute encryption






 I  am in agreement with following  provisos:

1.  I definitely agree we should allow the use of XSLT to  allow
    encryption or arbitrary  fragments, such as attributes,
    but  I don't think we should make it
     required for encrypting attributes (if indeed the WG
    decides encrypting attributes is a good idea).   Though
    I'm a big fan of XSLT, I'm  not convinced it is the best
     approach for supporting attribute encryption.

No, in mode 2 you  design your schema to the constraints of the XML
encryption  standardso that it will work without XSLT transforms. The
choice of attribute or element with attribute is an arbitrary one. The
choice of  element data over attributes appears to have fewer  constraints.

So in the design  process there should not be a case where it is necessary
to go for an  attribute.

If the spec  requires you to design the schema with all the secret info
contained in an  element whose tag and attributes are not themselves secret
that is what you  do.

<MySchema>
     <NonSecretStuff>
     <NotReadable>awpe9857q2h9827598ywaetaw98375iu23a56y89==</NotReadable>
</MySchema>

    A big difference between XSLT/XPath in XML  Signature and
    in XML Encryption, is  that in Signature it need only be
     one-way because you don't reconstruct the original data from
    the hash.  In Encryption, your mode 2 (as I  understand it)
    requires an XSLT  transformation for encrypting attributes and
    then another XSLT for the reverse transformation to  go from
    the encrypted version to  the plaintext.

2.  In XML Signature, you can sign attributes with the  lightweight
    XPath rather than  XSLT.  However, XPath, which is basically a
    point and retrieve mechanism, is not capable of  doing the
    transformations required  by mode 2; you can use it to select
     a subset for encrypting but you cannot use XPath to recreate
    the original, that requires XSLT. Though XSLT is  more powerful,
    it also requires  more processing capability which, I think,
    is one major reason why XPath was supported for XML  Signature.

I  agree, XPath is useful for Signature but not  in encryption.

Phill, please clarify some things for me:
1.  Do you think XML Encryption should specify a mechanism for
    encrypting  attributes?

 No

2.  Do you think that XML Encryption should discuss the  use of
    XSLT transformations like  those you have described for mode 2?

I  think that the use of XSLT should be allowed but that it is only
relevant in  cases where a legacy schema is being addressed (mode 1). The
XSLT  transformation rearanges things to give the original  message.

3.  If the answer to question 2 is yes, do you think that
    XML Encryption should specify syntax for XSLT
    transformations analagous to XML Signature's  <XSLT> element?

I  think the two specs should be aligned and use the same transformation
pipeline.

-----Original Message-----
From:  Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Monday, January 08, 2001 5:46 PM
To: 'Joseph M. Reagle Jr.'; Sanjeev Hirve
Cc:  Philip Hallam-Baker; xml-encryption@w3.org
Subject:  RE: Attribute encryption

It is easier to ignore a message signature than message  encryption.

But XML Signature is certainly not 'transparent' in the sense  that the
signature can be scoped to arbitrary message  fragments - without the use
of
another XML  layer.

It is possible to use XSLT or XPath to identify and sign a  fragment of an
XML message. It would seem sensible to  allow the use of XSLT to allow
encryption of arbitrary  fragments of an XML message.

Equally it is possible for applications to profile XSLT and  XPATH or avoid
them entirely while using XML  Signature. I think that as presently
specified
XML  Signature and Encryption have compatible and comparable approaches.

                 Phill

> -----Original Message-----
>  From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
> Sent: Monday, January 08, 2001 3:34 PM
> To: Sanjeev Hirve
> Cc: Philip  Hallam-Baker; xml-encryption@w3.org
> Subject: Re:  Attribute encryption
>
>
> At 15:11 1/8/2001 -0500, Sanjeev Hirve  wrote:
> > >Case 2:
> > >    Message B states only that it is in  schema PQR which
> is the standard
> > schema for the application and incorporates the XML
> > > encryption schema. The node encryption was  considered at
> the time the
> > schema was created.
> >In this  case, the schema designer, primarily an business
>  expert, must also
> >tale into account  encryption requirements, sometimes there may be
>  >conflicting design goals.  This assumption could be fraught with
> >pitfalls.  It may be better to keep  security as
> "transparent" as possible.
>
> In general, this is the  approach we took in xmldsig. We could
> not presume
> that schema authors would know about xml  signature/encryption
> and design
> their schema accordingly.
>
> __
> Joseph Reagle  Jr.
> W3C Policy  Analyst                 mailto:reagle@w3.org
> IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
>

Received on Thursday, 11 January 2001 08:41:20 UTC