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 standard so 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
<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 <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
<mailto:reagle@w3.org>  
> IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
<http://www.w3.org/People/Reagle/>  
>