Aleksey:
I *must* have this stuff -- there's not really another way to do this
without using a never-expiring cert from a private CA -- and that has
it's own set of risks and hazards that are commisurate with, or greater
than, the risk you point out of not expiring a signature after it's
release
OpenSSL just don't have the required parameters in X509_STORE
structure. However, it does have the needed stuff in X509_STORE_CTX
so potentially there is a way to handle this, just extra code in xmlsec.
How badly do you really need this stuff? Please, think twice because:
1) XMLDsig has no st
Aleksey:
Since OpenSSL 0.9.7 is still in beta, I'm a bit reluctant to use it in
a release version of my products. We're very close to release right now
and I hate to have to revisit most of the QA process just because I need
to upgrade OpenSSL -- and to an unreleased version also. Can you point
It turns out that there is pretty simple way to set verification
time in OpenSSL (0.9.7) and I did implemented this so you can
find the "certs verification time" in the tommorow nightly snapshot
or in Gnome CVS (http://www.aleksey.com/xmlsec/download.html).
However, this works only with OpenSSL 0.
I had some time to read RFC (in particular, RFC 1422, RFC 1423, RFC 1424,
RFC 2459), and I found that:
1) signature verification requires "valid" certificate;
2) "valid" certificate is application specific;
3) the application may accept "invalid" certs and show application
specific
Rich,
I would be happy to change my position but I need a spec for this.
Meantime, I would like to repeat that this is OpenSSL behaiviour.
Probably, you might want to ask this question in OpenSSL mailing list.
Aleksey.
Rich Salz wrote:
> We have a fundamental disagreement, so I'll stop.
>
We have a fundamental disagreement, so I'll stop.
/r$
___
xmlsec mailing list
[EMAIL PROTECTED]
http://www.aleksey.com/mailman/listinfo/xmlsec
Yes, I am saying this. The signature is not valid forever. It's valid
only why certificate is valid.
If you don't like this scheme then you should use certs with long
expiration time or another scheme.
Cert is your digital identity. It's not you who signs something but your
digital identity. Th
> Yes! When you signed it you claimed that you are the college student.
> When you graduated
> you are not college student anymore and your signature as "college
> student" is *not* valid.
So you're saying that you believe it is impossible to ever do any after
the fact audits. I can never ver
Forgot to mention that I understand that in some cases you might have a
(wrong) requirement
to skip expiration date check. However, I do think that this is really
bad idea from security
point of view and you will have to do this "hack" manually.
Aleksey
Aleksey Sanin wrote:
> Yes! When you si
Yes! When you signed it you claimed that you are the college student.
When you graduated
you are not college student anymore and your signature as "college
student" is *not* valid.
Certificate is not only a key but also your "digital identity". When
certificate expires your
identity is no longe
>The document signed with cert means that
>1) the document was signed by a person to whom the cert was issued;
>2) the document was not changed since the time it was signed.
> The expired cert could not provide you first item (I hope the reasons
> are clear).
Not at all, please explain.
Rich, Moultrie,
I have to disagree with you. The document signed with cert means that
1) the document was signed by a person to whom the cert was issued;
2) the document was not changed since the time it was signed.
The expired cert could not provide you first item (I hope the reasons
ar
Rich Salz wrote:
> Yes, it is important to be able to verify something after the
> credentials have expired.
I forgot to mention: if you are intersetd in truly long-term signatures,
do a google search for "etsi long signatures" and/or look at www.etsi.org
/r$
Yes, it is important to be able to verify something after the
credentials have expired. As long as the signature was *generated*
during the validity period, then you can verify it. There is a reason
why PKCS7, and XML-DSIG, include the ability to put CRL's into a
signature: so you can show
Title: Message
Aleksey:
I'll have to check the spec also -- but it simply *can't* work this way. If
I sign e-mail today and it can't be verified tomorrow even though nothing has
changed, that's *wrong*. I do know that signing of certs works this way but
that's handled by ensuring that the
I believe you are wrong here. The certificate must be valid when signature
is verified.
Where "valid" includes:
1) certificate is signed by another "valid" cert or trusted root cert
2) certificate is not in the CRL
3) the certificate purpose matches the action you are going to do (
Aleksey:
Very important question here -- I want to make sure I understand your
reply. In general, it is not permitted to *sign* data after the signing
certificate has expired but it is allowed to *verify* data after
expiration. An example:
I sign my code today allowing the user to verify that i
From the general security point of view the data are *not valid* if the
cert is expired.
If you really want to do this then you should take a look at the OpenSSL
cert
verification function and remove date check. However, this is DANGEROUSE!
Aleksey.
Roman Bouchner wrote:
>Hello
>I would like
Hello
I would like to verify signed data however signer's certificate has
already expired. I want only verify data integrity.
If I use function xmlSecDSigValidate, it returns negative value, so I
cannot determine if data was changed or not.
If I change local date it does work, however it is not ri
20 matches
Mail list logo
