RE: encryption in XML & in SMIME

In response to my text:
Recognizing the applications where XML is intended to be used,
the XML Signature WG has even made the <KeyInfo> element optional
in XML Signatures; which I, and I thing the WG, still think was
the right one.  (<KeyInfo> provides the verification public key,
or at least a hint about it.)  The reason for making <KeyInfo>
optional was to allow applications to handle keys behind the
scenes.

Don wrote:
   i'm sorry to disagree with you, but you seem to be saying,
"this so-called security problem is unimportant, because
the purported fix isn't compatible with the way xml does
things."  such a "no compromise" policy will not serve xml's
users well.   

My reply to Don's reply:
To be clear, I am NOT saying:  "this so-called security problem 
is unimportant, because the purported fix isn't compatible with 
the way xml does things." 

In fact, quite the opposite.  If it can be shown that XML 
REQUIRES an application to use it in such a way that is not 
secure, then XML MUST be fixed.  

In my statement, I was explaining why the XML Signature WG made 
its decision to exclude <KeyInfo> from the signed bits.  As I 
did say before, if this is an XML Signature security issue, 
then it needs to be discussed on the XML Signature list.  At 
this point, I see the problem as primarily an application/protocol 
design issue rather than an XML Signature/Encryption one.

The question has been raised at both the recent Pittsburgh and 
Santa Barbara meetings of how far should the XML Signature and 
Encryption specifications go in trying to ensure that applications 
don't shoot themselves in the foot.  I like the way Philip 
put it: something like "If we don't stop implementors 
from shooting themselves in the foot; they'll shoot us in the head.".  

I agree that XML's power and flexibility will give apps many 
opportunities to muck up security if they are not reviewed by 
someone with a good understanding of both XML and security.  
However, I don't what to unnecessarily restrict apps that DO 
understand XML's security gotchas from being able to do exactly 
what they want to do.  So my own feeling is that the XML Signature 
and XML Encryption specs should restrict themselves to specifying 
the basic building blocks of security.  That said, I also feel 
that there needs to be papers and books written about how apply 
these building blocks because XML presents such a new paradigm 
for application/protocol design.   I think it would be great if 
there was a paper that addressed the naming issue that has been raised. 

So at this point, I still see the naming issue we're discussing as 
being properly resolved in the application design space rather than the 
XML Security space.  However, I don't mind hearing more about it.  
Note that the next meeting of the XML Encryption interest group will 
likely be in Boston in October so we could discuss it then.

Ed

Received on Tuesday, 29 August 2000 11:57:12 UTC