Re: Post 1.1 xpath functions

Thanks leigh,
I am aware of the man-in-the middle hazard.  The encrypt function is 
only one part of the solution.  The problem is that just saying 'use 
https' has in my mind the following issues:

1. It assumes the xforms is used as part of a web page.
2. It ignores the use of transports over smtp or some form of message 
queueing.
3. It ignores offline forms where the form may be stored on a device 
that could be lost/stolen and have fragments of sensitive information 
within them.
4. Most security breaches occur inside an organization, not from people 
inside a telecom company.  HTTPS is generally used on the internet and 
then the form/submission etc is silently processed inside a company from 
where most information such as credit card numbers/passwords etc are stolen.

So my question is about providing the ability to encrypt the contents of 
an xml fragment, or instance using xml:encryption, not using it it 
replace https or any other internet based security protocol.  How the 
encrypt function works with the certificate store on the browser was not 
part of the question.  I would expect (and this is how I am doing it in 
MozzIE) is that if a certificate is provided for say an RSA encrypted 
element and the certificate is not from a trusted authority and it is 
not provided in a means that can be authenticated, the user is warned.  
This uses the same authentication mechanisms as used by https to 
authenticate the digital certificates.

Hence my question, about whether the wg has considered an encrypt 
function along with all of the issues above, as it is an important 
function of xforms unless of course the intent is to only have xforms 
transmitted over the Internet, and only securable using https.

If it has not been considered, then I would like to start a dialog on 
the issue for consideration of inclusion into a future xforms spec, 
otherwise it will have to fall into the catch-all extension function bucket.

regards