By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,294 Members | 2,645 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,294 IT Pros & Developers. It's quick & easy.

XML signing

P: n/a
Two questions. We would like to have users complete
ASP.NET web forms for submission. Once these are
completed I would like to generate an XML document from
the form. The XML document should include the data and
the form so that the orginal document could be recreated
even if the submitting form is changed in the future.

I would also like to sign the XML document so that we can
provide proof that the xml document has not been modified
since its submission. Do you have any ideas to best
accomplish these items.

We will use the XML document to provide proof if our
internal database versions of the documents are ever
questioned.

Todd Richardson
Nov 11 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
If you want to sign XML from within a .NET app,
check
http://msdn.microsoft.com/library/en...classtopic.asp

This won't work, in general, for the scenario you describe, if you want to
sign the XML on the browser side, and then transmit it. This is because
the browser, in general, is not .NET enabled and so does not have the
capability to sign XML docs in this way. (Some browsers may have such
capability)

If on the other hand you can accept having the browser submit the form (http
post), and then the asp.net app receives the post and THEN and THERE
generate the XML, and sign it, and store it somewhere, that should not be
too difficult.
"Todd Richardson" <to***@dmme.com> wrote in message
news:0d****************************@phx.gbl...
Two questions. We would like to have users complete
ASP.NET web forms for submission. Once these are
completed I would like to generate an XML document from
the form. The XML document should include the data and
the form so that the orginal document could be recreated
even if the submitting form is changed in the future.

I would also like to sign the XML document so that we can
provide proof that the xml document has not been modified
since its submission. Do you have any ideas to best
accomplish these items.

We will use the XML document to provide proof if our
internal database versions of the documents are ever
questioned.

Todd Richardson

Nov 11 '05 #2

P: n/a
We are ok with the signing on the server side. However,
what is the best way to include the form which was used to
fill out the XML document with the XML data. We would
like to do this in order to assure that the XML data
matches the submission form. Without this we are
concerned that the document will not meet the e-signing
law requirements.

Todd Richardson
-----Original Message-----
If you want to sign XML from within a .NET app,
check
http://msdn.microsoft.com/library/en- us/cpref/html/frlrfsystemsecuritycryptographyxmlsignedxmlcl
asstopic.asp
This won't work, in general, for the scenario you describe, if you want tosign the XML on the browser side, and then transmit it. This is becausethe browser, in general, is not .NET enabled and so does not have thecapability to sign XML docs in this way. (Some browsers may have suchcapability)

If on the other hand you can accept having the browser submit the form (httppost), and then the asp.net app receives the post and THEN and THEREgenerate the XML, and sign it, and store it somewhere, that should not betoo difficult.
"Todd Richardson" <to***@dmme.com> wrote in message
news:0d****************************@phx.gbl...
Two questions. We would like to have users complete
ASP.NET web forms for submission. Once these are
completed I would like to generate an XML document from
the form. The XML document should include the data and
the form so that the orginal document could be recreated
even if the submitting form is changed in the future.

I would also like to sign the XML document so that we can provide proof that the xml document has not been modified since its submission. Do you have any ideas to best
accomplish these items.

We will use the XML document to provide proof if our
internal database versions of the documents are ever
questioned.

Todd Richardson

.

Nov 11 '05 #3

P: n/a
I think this will pretty quickly get into the details of the e-signing law
and what is required and what qualifies as "sufficient proof".

The normal way an HTTP form submission works, as you know, is this: a server
generates a "form", the client (browser) renders it. The user fills it out
and presses "submit". The form fields are posted back to the server.

But HTTP (as you know) is a stateless protocol. So it is quite possible for
the client to NOT render the form as the server expects. Maybe the client
will omit some of the form fields. Maybe the client will augment the form
with some additional fields. Or, it is possible for the client to not
render a form AT ALL, and instead just submit a bunch of field values. The
server cannot tell what was rendered and what was not rendered. All the
server knows is what fields and values the client has posted.

In order to get to the guarantees you want, you would have to take some
extra steps.

Like:
- use SSL
- establish a session with the client (login)
- when the server is generating the form, generate a "form state" field,
encoded as a "hidden field", which indicates the actual fields that should
be rendered, as well as a timestamp and the encoded session ID. All of this
to prevent replay.
upon post-back, the server should validate the "form state" - values for
the necessary fields are present, the submitted fields match the fields
required in the form-state; the postback is coming from the appropriate
session; the timestamp has not expired, etc. This would have the effect of
guaranteeing that a post back is accepted only within the context of a
conversation (session), and that the client received a description of the
fields to render. It still does not guarantee that the client actually
"rendered" the form.
- at this point the server can generate and sign a record that describes
the form
the submitted values
the time and date
etc

But I don't know the implications of e-signing law, or if this would meet
your needs.
"Todd Richardson" <to***@dmme.com> wrote in message
news:05****************************@phx.gbl...
We are ok with the signing on the server side. However,
what is the best way to include the form which was used to
fill out the XML document with the XML data. We would
like to do this in order to assure that the XML data
matches the submission form. Without this we are
concerned that the document will not meet the e-signing
law requirements.

Todd Richardson
-----Original Message-----
If you want to sign XML from within a .NET app,
check
http://msdn.microsoft.com/library/en-

us/cpref/html/frlrfsystemsecuritycryptographyxmlsignedxmlcl
asstopic.asp

This won't work, in general, for the scenario you

describe, if you want to
sign the XML on the browser side, and then transmit it.

This is because
the browser, in general, is not .NET enabled and so does

not have the
capability to sign XML docs in this way. (Some browsers

may have such
capability)

If on the other hand you can accept having the browser

submit the form (http
post), and then the asp.net app receives the post and

THEN and THERE
generate the XML, and sign it, and store it somewhere,

that should not be
too difficult.
"Todd Richardson" <to***@dmme.com> wrote in message
news:0d****************************@phx.gbl...
Two questions. We would like to have users complete
ASP.NET web forms for submission. Once these are
completed I would like to generate an XML document from
the form. The XML document should include the data and
the form so that the orginal document could be recreated
even if the submitting form is changed in the future.

I would also like to sign the XML document so that we can provide proof that the xml document has not been modified since its submission. Do you have any ideas to best
accomplish these items.

We will use the XML document to provide proof if our
internal database versions of the documents are ever
questioned.

Todd Richardson

.

Nov 11 '05 #4

P: n/a
I am not sure if this meets our needs or not. Do you know
what other organizations have done to assure this kind of
security. I am looking for what most would consider a
best practice. We plan to use SSL. We also considered
only allowing the client to connect to the form if they
matched our supported browser version. Since this is for
a limited number of business users, we felt we could
mandate the version.

I have attached what we consider our requirements below.
The biggest concern is that they data submitted and the
form match. I had thought about using an XML document to
render the form and an XML document to store the data.
That way both the form and the data could be signed and
used to recreate both. I am really just looking for
options and ideas.

Todd
Digital signatures, uniquely, have the following set of
characteristics. The signature is:
a. unique to the signer
b. capable of verification
c. under the signer's sole control
d. linked to the record in such a manner that it can be
determined if any data contained in the record was changed
subsequent to the electronic signature being affixed to
the record
e. and created by a method appropriately reliable for the
purpose for which the electronic signature was used.
Legal Signatures and Electronic Signatures
The American Bar Association (ABA) defines a "legal
signature" as having the following characteristics:

Signer authentication: To provide good evidence of who
participated in a transaction, a signature should indicate
by whom a document or message is signed
and be difficult for any other person to produce without
authorization.

Document authentication: To provide good evidence of the
substance of the transaction, a signature should identify
what is signed, and make it impracticable to
falsify or alter, without detection, either the signed
matter or the signature.

Affirmative act: To serve the ceremonial and approval
functions of a signature, a person should be able to
create a signature to mark an event, indicate approval and
authorization, and establish the sense of having legally
consummated a transaction.

Efficiency: Optimally, a signature and its creation and
verification processes should provide the greatest
possible assurance of authenticity and validity with the
least possible expenditure of resources. (2)

-----Original Message-----
I think this will pretty quickly get into the details of the e-signing lawand what is required and what qualifies as "sufficient proof".
The normal way an HTTP form submission works, as you know, is this: a servergenerates a "form", the client (browser) renders it. The user fills it outand presses "submit". The form fields are posted back to the server.
But HTTP (as you know) is a stateless protocol. So it is quite possible forthe client to NOT render the form as the server expects. Maybe the clientwill omit some of the form fields. Maybe the client will augment the formwith some additional fields. Or, it is possible for the client to notrender a form AT ALL, and instead just submit a bunch of field values. Theserver cannot tell what was rendered and what was not rendered. All theserver knows is what fields and values the client has posted.
In order to get to the guarantees you want, you would have to take someextra steps.

Like:
- use SSL
- establish a session with the client (login)
- when the server is generating the form, generate a "form state" field,encoded as a "hidden field", which indicates the actual fields that shouldbe rendered, as well as a timestamp and the encoded session ID. All of thisto prevent replay.
upon post-back, the server should validate the "form state" - values forthe necessary fields are present, the submitted fields match the fieldsrequired in the form-state; the postback is coming from the appropriatesession; the timestamp has not expired, etc. This would have the effect ofguaranteeing that a post back is accepted only within the context of aconversation (session), and that the client received a description of thefields to render. It still does not guarantee that the client actually"rendered" the form.
- at this point the server can generate and sign a record that describes the form
the submitted values
the time and date
etc

But I don't know the implications of e-signing law, or if this would meetyour needs.
"Todd Richardson" <to***@dmme.com> wrote in message
news:05****************************@phx.gbl...
We are ok with the signing on the server side. However,
what is the best way to include the form which was used to fill out the XML document with the XML data. We would
like to do this in order to assure that the XML data
matches the submission form. Without this we are
concerned that the document will not meet the e-signing
law requirements.

Todd Richardson
>-----Original Message-----
>If you want to sign XML from within a .NET app,
>check
>http://msdn.microsoft.com/library/en-

us/cpref/html/frlrfsystemsecuritycryptographyxmlsignedxmlcl asstopic.asp
>
>This won't work, in general, for the scenario you

describe, if you want to
>sign the XML on the browser side, and then transmit it.

This is because
>the browser, in general, is not .NET enabled and so does
not have the
>capability to sign XML docs in this way. (Some
browsers may have such
>capability)
>
>If on the other hand you can accept having the browser

submit the form (http
>post), and then the asp.net app receives the post and

THEN and THERE
>generate the XML, and sign it, and store it somewhere,

that should not be
>too difficult.
>
>
>"Todd Richardson" <to***@dmme.com> wrote in message
>news:0d****************************@phx.gbl...
>> Two questions. We would like to have users complete
>> ASP.NET web forms for submission. Once these are
>> completed I would like to generate an XML document

from >> the form. The XML document should include the data and >> the form so that the orginal document could be recreated >> even if the submitting form is changed in the future.
>>
>> I would also like to sign the XML document so that we

can
>> provide proof that the xml document has not been

modified
>> since its submission. Do you have any ideas to best
>> accomplish these items.
>>
>> We will use the XML document to provide proof if our
>> internal database versions of the documents are ever
>> questioned.
>>
>> Todd Richardson
>
>
>.
>

.

Nov 11 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.