RE: Attribute encryption

I don't see why a separate transform layer would be less efficient.
Requiring all applications to support encrypted attributes would add
significantly to complexity and thus impair performance of all applications
- including those that do not require encrypted attributes.
 
I do not anticipate dealing with encrypted attributes. I strongly believe
that the set of all XML applications that require encryption to be added
under the constraint of inflexible adherence to a legacy schema is the empty
set.
 
I simply do not believe that message level encryption is a zero impact
change to a protocol. A signature can be ignored by the recipient.
Encryption cannot be ignored without ignoring the message.
 
The requirement for field level security only makes sense if you have a
message that A sends to B and B forwards to C where you want to control the
amount of information that is visible to B. Otherwise why not encrypt the
whole thing and be done with it?
 
I don't see how the impact on C can be avoided, if C is going to implement
encryption tweaking the schema is unlikely to be a major change.
 
The impact on B however will inevitably be significant since B will now have
less information than before. In fact it is almost certain that some
additional information will now have to be provided to B as a surrogate for
the information that is now hidden - such as returning the last four digits
of an encrypted CC number.
 
I don't understand the statement about keeping security transparent.
Encryption is never transparent to all parties, if it is then it isn't
security.
 
The designer of any schema has to understand both the business requirements
and the security requirements, the security requirements are simply a
refinement of the business requirements. 
 
        Phill

-----Original Message-----
From: Sanjeev Hirve [mailto:shirve@cyberelan.com]
Sent: Monday, January 08, 2001 3:11 PM
To: Philip Hallam-Baker; xml-encryption@w3.org
Cc: Michael Sakhatsky; Raju Nadakaduty; Marcus A Cuda
Subject: Re: Attribute encryption



>I simply do not agree that Mode 1 has any real utility. XML frameworks are
by design flexible. If there is a need for backwards >compatibility then
XSLT can be used to paper over any inconsistency. Viz
 
Yes, it is always possible to use Transformations or other means to cater
for any feature/function not supported directly by the encryption standard.
So the question is really whether a feature should be mandated by the
standard.  If a commonly required feature is excluded we run the risk of
losing inter-operability or efficiency (I assume a separate transform costs
more).
   I am arguing for consistency of treatment.  Sensitive data appear as
attributes as frequently as in child nodes.  Whether the standard addresses
it or not, applications will have to address it one way or the other.
 
>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.