RE: Attribute encryption

A primary difference between XML Encryption and previous encryption specs
like PKCS#7, is that XML Encryption allows an application to be selective
about what is encrypted and what is left in the clear.  I often say that XML
Encryption is important not just for what it can encrypt, but what it can
leave unencrypted.  In PKCS#7, if you needed to secure only part of a
document, too bad, you have to secure the whole thing, and this means that
even applications that only need access to a non-confidential part of a
document also need the ability to decrypt it.  With XML Encryption, you can
leave intact everything that isn't confidential thus minimizing the changes
needed to a business system.  And, of course, there is a security benefit to
not having to give access rights to applications that don't need them as
would have been required before XML Encryption.  When Joseph talks about
keeping security transparent, this is what I think of: security that only
secures what needs to be secured, and, particularly for encryption, leaves
the rest transparent.  Also note that different parts of an XML document can
be encrypted for different entities.
 
So simply put, I have to disagree with the statement "Encryption cannot be
ignored without ignoring the message" because it is too absolute.  With XML
Encryption, only parts of a message need to be encrypted, your application
can know what has been encrypted, what has been encrypted for it, and what
parts haven't been encrypted at all; and if the application is not
interested in the parts it is not allowed to decrypt, then the message
remains valuable.
 
The model Phill presented of XML processing is one that I expect many
applications and protocols will want to use and XML Encryption should
support it.  However, I also suspect that many XML-based systems will have
multiple applications that want to do different things with the same data.
For these system, transformation between a vanilla schema and an XML
Encryption-aware schema will not be optimal.  This is somewhat akin to
Phill's "promiscuous" mode 1 in that I see the same data being shared,
perhaps with different parts encrypted at different stages, among several
applications in no particular order.  So, in fact, I think promiscuous mode
is an important model to support.
 
One question I have about Phill's mode 2 is how does it impact the use of
XML Signatures.  If one wanted to sign (before encrypting) the message,
would one/should one sign just the pre-transformated message, the
transformed message, or both.  I recognize the answer may depend on the
protocol being designed but I'm still not quite comfortable with this.
 
In any event, I want to hear from a variety of people designing XML specs
and systems about their requirements for XML Encryption.
 
Regards, Ed

-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Monday, January 08, 2001 3:40 PM
To: 'Sanjeev Hirve'; Philip Hallam-Baker; xml-encryption@w3.org
Cc: Michael Sakhatsky; Raju Nadakaduty; Marcus A Cuda
Subject: 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.