I just got the OpenSSL ocsp tool option -rmd for specifying the digest
algorithm in signature.
This option is described at the below page,
https://www.openssl.org/docs/manmaster/man1/openssl-ocsp.html
Just out of curiosity, why isn't it at the following man page?
https://www.openssl.org/docs/man1
I just want to know how does OpenSSL implement RFC 6960 section 4.4.7.2
Responder Signature Algorithm Selection.
Could I take a OpenSSL responder to use SHA1withRSA signature algorithm
if the certificate is signed by this algorithm?
[1] https://tools.ietf.org/html/rfc6960#section-4.4.7.2
On Sat,
unsubscribe openssl-users
From: openssl-users On Behalf Of John Jiang
Sent: Friday, July 3, 2020 12:19 PM
To: openssl-users
Subject: OCSP response signature algorithm
Hi,
I'm using OpenSSL 1.1.1.
Can I configure the OCSP response signature algorithm?
For a RSA issuer, it looks SH
On 02.09.2013 10:33, deepak.kathuria wrote:
Hi,
I am using openssl OCSP utility as OCSP Responder in linux platform. OCSP
Requester sends the OCSP Request to OCSP Responder and if OCSP Responder
will not come, then what will be the expected behavior of OCSP Requester in
this case?
this can be co
On 31-07-2013 22:11, Salz, Rich wrote:
Wouldn't it be just as good to have a cRLDistributionPoint which does not restrict the
available ReasonFlags and then put "cACompromise" in the CRL if/when that
disaster happens?
No because with my idea you are a priori restrict the crlDP to be only CA
r
> Wouldn't it be just as good to have a cRLDistributionPoint which does not
> restrict the available ReasonFlags and then put "cACompromise" in the CRL
> if/when that disaster happens?
No because with my idea you are a priori restrict the crlDP to be only CA
revocation.
> Wouldn't it be equall
On 31-07-2013 19:56, Salz, Rich wrote:
This is not possible according to PKIX. RFC5280 states "The trust anchor for the
certification path [of the crl] MUST be the same as the trust anchor used to validate the
target certificate."
The root certificate creates a crl-signing cert. The root certi
> This is not possible according to PKIX. RFC5280 states "The trust anchor for
> the certification path [of the crl] MUST be the same as the trust anchor used
> to validate the target certificate."
The root certificate creates a crl-signing cert. The root certificate includes
a cRLDistributionP
> -Original Message-
> From: Walter H.
>> Eisenacher, Patrick wrote:
> >> -Original Message-
> >> From: Jakob Bohm
>>
> > As I said before, there's no pki-inherent mechanism to revoke a self signed
>> certificate other than to remove it from your truststore.
>
> not really; a CA tha
On 31.07.2013 16:47, Jakob Bohm wrote:
the only cert that can't be checked by OCSP is the root cert itself;
This is where I disagree, can you point me to an actual reason why
not, which is not refuted by my logical ABC argument above.
the Authority Information Access extension does not make an
On 31-07-2013 16:01, Walter H. wrote:
Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 31-07-2013 11:02, Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
Jako
Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 31-07-2013 11:02, Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
Jakob, I don't und
> -Original Message-
> From: Jakob Bohm
>
> On 31-07-2013 11:02, Eisenacher, Patrick wrote:
> >> -Original Message-
> >> From: Jakob Bohm
> >>
> >> On 30-07-2013 20:53, Walter H. wrote:
> >>> On 30.07.2013 19:51, Eisenacher, Patrick wrote:
> > Jakob, I don't understand your reasoni
On 31-07-2013 11:02, Eisenacher, Patrick wrote:
-Original Message-
From: Jakob Bohm
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
In Boolean logic, we have the following possibilities:
- Root is trusted, so the revocation is valid, so the root i
> -Original Message-
> From: Jakob Bohm
>
> On 30-07-2013 20:53, Walter H. wrote:
> > On 30.07.2013 19:51, Eisenacher, Patrick wrote:
>
> In Boolean logic, we have the following possibilities:
>
> - Root is trusted, so the revocation is valid, so the root is not
> trusted. This is a c
On 30-07-2013 20:53, Walter H. wrote:
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
I was wondering how the root cert gets revoked. Anyway thanks for
posting
that request.
A self-signed certificate can't be revoked via a crl, because you
won't be able to successfully verify its signature.
ke
On 30.07.2013 19:51, Eisenacher, Patrick wrote:
I was wondering how the root cert gets revoked. Anyway thanks for posting
that request.
A self-signed certificate can't be revoked via a crl, because you won't be able
to successfully verify its signature.
keep in mind, that in case you detect a p
> -Original Message-
> From: redpath
>
> I agree with this
>
> "Once again, I would like to advocate that the openssl verification code
> should allow a self-signed certificate to revoke itself, using the same
> mechanisms as for revoking anything else. "
>
> I was wondering how the ro
I agree with this
"Once again, I would like to advocate that the openssl verification code
should allow a self-signed certificate to revoke itself, using the same
mechanisms as for revoking anything else. "
I was wondering how the root cert gets revoked. Anyway thanks for posting
that reques
On 23-07-2013 23:56, Steven Madwin wrote:
The short answers is no. An OCSP response has to be signed by the issuer (or
a delegate of the issuer) and a self-signed cert is issued by itself. As a
general rule certs can't revoke themselves so there is no need to get a
revocation response for a self-
Thanks saw that Ruby one also was not sure of it either and it was in Ruby
but will look at that much deeper. And I also saw the EJBCA and all the
orphans
I had to take in to have it work was too much for me. Geez its just a
responder come on.
--
View this message in context:
http://openssl.
Hi,
when I was looking for an OCSP responder in January I also found
OpenCA.org and I also think it is dead.
If you want to use it, read the mailing list. Someone posted important
patches (against memory leaks and other things).
Another thing is, that I am not sure if an OCSP responder, which on
The short answers is no. An OCSP response has to be signed by the issuer (or
a delegate of the issuer) and a self-signed cert is issued by itself. As a
general rule certs can't revoke themselves so there is no need to get a
revocation response for a self-signed cert.
Steve
-Original Message--
On 02/19/2013 02:33 PM, Dr. Stephen Henson wrote:
On Tue, Feb 19, 2013, Jeremy Harris wrote:
On 18/02/2013 22:32, Dr. Stephen Henson wrote:
That's fine except that we're using SSL_CTX_set_verify() callback already
and the docs say it and SSL_CTX_set_cert_verify_callback() should not
be mixed.
On Tue, Feb 19, 2013, Jeremy Harris wrote:
> On 18/02/2013 22:32, Dr. Stephen Henson wrote:
> >>That's fine except that we're using SSL_CTX_set_verify() callback already
> >>and the docs say it and SSL_CTX_set_cert_verify_callback() should not
> >>be mixed.
> >>
> >
> >That explanation could be cl
On 18/02/2013 22:32, Dr. Stephen Henson wrote:
That's fine except that we're using SSL_CTX_set_verify() callback already
and the docs say it and SSL_CTX_set_cert_verify_callback() should not
be mixed.
That explanation could be clearer. In this case it's fine to mix the two.
OK, thankyou. No
On Sun, Feb 17, 2013, Jeremy Harris wrote:
> On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote:
> >So you could supply an application defined callback that just calls
> >X509_verify_cert too which keeps the current behaviour. If that call is
> >successful you can then note the chain for future use
On Sun, Feb 17, 2013 at 10:02 AM, Jeremy Harris wrote:
> On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote:
>>
>> So you could supply an application defined callback that just calls
>> X509_verify_cert too which keeps the current behaviour. If that call is
>> successful you can then note the chain
On 02/16/2013 10:51 PM, Dr. Stephen Henson wrote:
So you could supply an application defined callback that just calls
X509_verify_cert too which keeps the current behaviour. If that call is
successful you can then note the chain for future use using
X509_STORE_CTX_get1_chain().
That's fine exce
On Sat, Feb 16, 2013, Jeremy Harris wrote:
> On 02/09/2013 12:12 PM, Jeremy Harris wrote:
> >I'm working on an implementation of the client side of OCSP stapling.
> >To verify the stapled information I'm using the chain leading to the
> >server certificate, as presented in the (repeated) verify ca
On 02/09/2013 12:12 PM, Jeremy Harris wrote:
I'm working on an implementation of the client side of OCSP stapling.
To verify the stapled information I'm using the chain leading to the
server certificate, as presented in the (repeated) verify callbacks for
the server cert.
Despite the resounding
On 11/30/2012 10:32 PM, Dave Thompson wrote:
...
Hint: OCSP transport is NOT SSL/TLS. It is HTTP-based.
In principle it can be HTTPS, but normally needn't
because it is signed and cert data is public anyway,
and OpenSSL commandline responder only does HTTP
(and a very minimal HTTP at that).
s_c
> From: owner-openssl-us...@openssl.org On Behalf Of Rainer Rill
> Sent: Sunday, 25 November, 2012 08:04 [in zone -5]
I don't know what happened to this post. Headers (as resent)
show originator stamp Nov 25 14:04 +1 and initial transmission
.superkabel.de to .hosteurope.de to master.openssl.org
Hi Steve! What exactly does not work for you?
On Sat, 2012-08-04 at 19:58 -0700, Steven Madwin wrote:
> Has anyone been able to get OCSP working with version 1.0 or later? It works
> for me with version 0.9, but not 1.0.1c. I did see where someone suggested
> using an IPv6 style port address (i.e.
Dr. Stephen & others,
Could you please shed some light on this? I need to talk to an OCSP responder
through a proxy server. I am currently using OCSP_sendreq_nbio(). What is the
best solution (including hacking the openssl code) to make it work?
Thanks in advance,
-binlu
From: owner-openssl-
Hi Tim,
it's quite a while that you've posted this message, but I just ran into
the same problem.
There is a different behavior between openssl versions like 0.9.8n and
1.0.0c listen on the hosts IP addresses. This is exactly what you have
evaluated with your commands.
#> openssl ocsp -por
Carla Coutinho wrote:
> I'm trying to generate an OCSP request containing Issuer Name Hash and
> Issuer Key Hash calculated with hashing algorithm SHA256.
> I've already instaled OpenSSL 1.0.0, which has the option '-sha256', but
> that doesn't seem to be working (the Hash Algorithm is always SHA1)
On March 5, 2010 01:41:48 am Nagendra_U_M wrote:
> Hi All,
>
> I just started working on OCSP...
If I may ask, what are you working on - writing a client, or writing a server,
or using it in some other way?
> And I am trying to set up an OCSP responder using the OpenSSL CLI commands.
> Right
Hi All,
I just started working on OCSP...
And I am trying to set up an OCSP responder using the OpenSSL CLI commands.
Right now, my index.txt file is blank and zero-size (created using the
"touch" command).
I want to know how to fill in revocation information into the index.txt
file, and in
> From: owner-openssl-us...@openssl.org Dr. Stephen Henson
> Sent: Tuesday, 20 October, 2009 09:15
> On Tue, Oct 20, 2009, Daniel Marschall wrote:
> > 18758:error:02006062:system library:bind:Address already in
> > use:b_sock.c:685:port=''
> > 18758:error:20069075:BIO
> routines:BIO_get_acce
Hello Steve.
Dr. Stephen Henson schrieb:
On Tue, Oct 20, 2009, Daniel Marschall wrote:
Hello.
I am trying to set up an ocsp server.
I have following line:
openssl ocsp -index codesign_intermediate/index.txt -url
http://www.myhost.com:/codesign/ -rsigner root_ca/certs/cacert.crt
-rkey
On Tue, Oct 20, 2009, Daniel Marschall wrote:
> Hello.
>
> I am trying to set up an ocsp server.
>
> I have following line:
>
> openssl ocsp -index codesign_intermediate/index.txt -url
> http://www.myhost.com:/codesign/ -rsigner root_ca/certs/cacert.crt
> -rkey root_ca/private/privkey.pem -
On Mon, Apr 13, 2009, Rene Hollan wrote:
> What, if any, support is there in openssl to support OCSP stapling?
>
> I have code that does an OCSP check for received certs, but obviously
> want to "play nice" and make use of any stapled OCSP response first,
>
It is supported in the latest version
1) See openssl-0.9.8g/apps/ocsp
2) See also http://www.openssl.org/docs/apps/ocsp.html#
Best regards,
Abderrahmane,
--- En date de : Jeu 10.7.08, Sergio Yébenes Moreno <[EMAIL PROTECTED]> a
écrit :
De: Sergio Yébenes Moreno <[EMAIL PROTECTED]>
Objet: ocsp from C program
À: openssl-users@o
The code was release in 2006. Does anyone know if a newer version will be
released soon?
Bruce
On Tue, Jun 3, 2008 at 7:00 PM, <[EMAIL PROTECTED]> wrote:
> No docs, but there is working code here:
>
> https://www.openca.org/projects/ocspd/
>
> Best,
> Max
>
> Quoting Brian Smith <[EMAIL PROTEC
No docs, but there is working code here:
https://www.openca.org/projects/ocspd/
Best,
Max
Quoting Brian Smith <[EMAIL PROTECTED]>:
Does anyone know of any substantial documentation/coding examples that may
be available (similar to the Networking with OpenSSL book) for using OpenSSL
as an OC
Wockenfuß schrieb:
Hi all,
I'm looking for some code examples to realise a X.509 certificate verification
over OCSP with C++.
Is there something to find in the Open SSL package? Or are there other places
were I can find something?
I would expect such code in the apps/ocsp.c file of the Op
Christian Wiesbauer wrote:
> I want to know if an ocsp revocation check works with openssl if I'm using a
> proxy?
OCSP isn't HTTP so what kind of proxy do you mean?
__
OpenSSL Project http://www.o
On Mon, Jun 11, 2007, Mikolajczuk, Alan wrote:
> All,
>
> I have an IPv4 OCSP responder setup behind a 6 to 4 gateway. I am make
> requests to the IPv4 address, but when I make a request to the IPv6
> address OpenSSL will time out.
>
> Does OpenSSL support IPv6? Has anyone else run into this pro
p going if an error,
like a bad request, occurs.
Regards,
Simon McMahon
"Sowjanya Malika" <[EMAIL PROTECTED]>
12/13/2006 10:40 PM
To
Simon McMahon/Australia/Contr/[EMAIL PROTECTED]
cc
Subject
Re: ocsp responder certificate generation documentation( reg)
Hi,
hope Ia
howto make the OCSP certificate.
This is the section I added to my openssl.cnf file.
[ ocsp_cert ]
# These extensions are added when 'ca' signs a request for an OCSP
responder.
basicConstraints=CA:FALSE
extendedKeyUsage= OCSP Signing
noCheck = yes
...
Then as my other post said:
add "-e
Great thx again for you advice. If someone suffers the same problem
of retrieving the OCSP URI from a X509 my code can be found here.
char* get_OCSPlocation_from_X509(X509* cert, char** urls)
{
BIO* mem=NULL;
ACCESS_DESCRIPTION* ad=NULL;
STACK_OF(ACCESS_DESCRIPTION)* ads
On Fri, Nov 24, 2006, Michael Stephan wrote:
> Hallo,
>
> is it possible (i know it is but not to me at the moment ): ), to
> "easily" retrieve the OCSP URI from a X509 v3 certificate extension
> list?
>
> X509v3 extensions:
> ..
> Authority Information Access:
> OCSP: URI:http:http://
On Mon, Nov 13, 2006, Simon McMahon wrote:
>
> > Ah that's a bug in the ASN1 module associated with the OCSP request.
> I'll look into fixing that.
>
> Thanks. My other post shows the openssl request (with -no_certs) includes
> an empty sequence for 'certs' which the responder must be looking
error regarding request validation.
Cheers,
Simon McMahon
"Dr. Stephen Henson" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/13/2006 11:56 AM
Please respond to
openssl-users@openssl.org
To
openssl-users@openssl.org
cc
Subject
Re: ocsp signed requests - bug ?
On M
I just found -no_certs works with the OpenSSL OCSP client also. But I dont
know how the OCSP server is validating the signature!
In this case the OpenSSL generated request (attached) has an empty
sequence for the 'certs'. In the failing request (previous post) the
'certs' is not present.
Reg
On Mon, Nov 13, 2006, Simon McMahon wrote:
> Hi,
>
> Not sure if this belongs on users or dev because it might just be me not
> using openssl properly.
>
> I have an OCSP client that signs requests but does not send the
> certificate with the request. It also leaves out the requestorName
> (o
On Wed, Nov 08, 2006, Simon McMahon wrote:
> Hi Steve,
>
> > Err no it doesn't it isn't part of EKU.
> That's what I thought but I couldn't find "noCheck = yes" and stumbled
> onto the eku method.
>
That wasn't documented, though it is now :-)
> When I use "extendedKeyUsage = OCSP Signing, OC
to use OpenSSL correctly for this.
Cheers,
Simon McMahon
"Dr. Stephen Henson" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/07/2006 10:10 PM
Please respond to
openssl-users@openssl.org
To
openssl-users@openssl.org
cc
Subject
Re: ocsp-nocheck
On Tue, Nov 0
On Tue, Nov 07, 2006, Simon McMahon wrote:
> Found it: extendedKeyUsage = OCSP Signing, OCSP No Check
> does the trick.
>
Err no it doesn't it isn't part of EKU.
> The RFC doesn't exactly make this clear that 'nocheck' is a part of
> ExtendedKeyUsage but I guess that is not OpenSSL's prob
Found it: extendedKeyUsage = OCSP Signing, OCSP No Check
does the trick.
The RFC doesn't exactly make this clear that 'nocheck' is a part of
ExtendedKeyUsage but I guess that is not OpenSSL's problem.
Thanks.
__
OpenSSL Pr
Hi,
From my work in this area, I found that the error at the end of the
ocsp command is only a problem
with the running of the command - the contents of the file produced are
not impacted.
However, the way to avoid the error is to concatenate (doing it in a
text editor is fine) all the certs
Thanks Richard. It makes perfect sense.Richard Salz <[EMAIL PROTECTED]> wrote: Look at the end of section 4.1.1 for the details of "target cert identifier"/r$--SOA AppliancesApplication Integration Middleware__OpenSSL Project http
Look at the end of section 4.1.1 for the details of "target cert
identifier"
/r$
--
SOA Appliances
Application Integration Middleware
__
OpenSSL Project http://www.openssl.org
User Support
That makes sense. Thank you Steve."Dr. Stephen Henson" <[EMAIL PROTECTED]> wrote: On Fri, May 12, 2006, John Pattern wrote:> Two questions:> > 1. Why OCSP_cert_to_id requires two certificates? Basically it should > require only the certificate to be checked to construct an OCSP > request, right?>
On Fri, May 12, 2006, John Pattern wrote:
> Two questions:
>
> 1. Why OCSP_cert_to_id requires two certificates? Basically it should
> require only the certificate to be checked to construct an OCSP
> request, right?
>
The certificate identifier needs the issuerNameHash, issuerKeyHash
The following is from RFC 2560: 2.1 Request An OCSP request contains the following data: -- protocol version -- service request -- target certificate identifier -- optional extensions which MAY be processed by the OCSP Responder Upon receipt of a request, an OCSP Responder determines
> 1. Why OCSP_cert_to_id requires two certificates? Basically it should
> require only the certificate to be checked to construct an OCSP
> request, right?
Perhaps you should read the OCSP RFC.
/r$
--
SOA Appliances
Application Integration Middleware
Two questions: 1. Why OCSP_cert_to_id requires two certificates? Basically it should require only the certificate to be checked to construct an OCSP request, right? 2. When OCSP_basic_verify returns 0 does that mean a success or failure? Any comments are appreciated. Thanks.John Pattern
Thanks. I will take a look at ocsp.c.Brad Hards <[EMAIL PROTECTED]> wrote: On Thursday 11 May 2006 23:38 pm, John Pattern wrote:> I want to generate a simple OCSP request. What are the steps I must> follow using OpenSSL? Thank you for your help.There is an openssl tool to do so - see:http://www.op
On Thursday 11 May 2006 23:38 pm, John Pattern wrote:
> I want to generate a simple OCSP request. What are the steps I must
> follow using OpenSSL? Thank you for your help.
There is an openssl tool to do so - see:
http://www.openssl.org/docs/apps/ocsp.html
There is some detail, and a test server a
> Is there any documentation on how I can programmatically
> create OCSP
> requests, ready to be sent on the wire?
>
> Thanks in advance!
> Randy
>
Well, you should look at openssl.org and the openssl source
code. Here I can give you a small code snippet which should
give you a basic idea of wh
One of the authors of OCSP once explained that his motivation was that
debugging could be simpler because a parser doesn't need to know the
syntax behind implicit tags. There was no other particular reason.
sravan wrote:
I thank Steven & David for taking their time in explaining the concept
of
t: Friday, 9 September 2005 8:03 AM
To: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
> I guess I just haven't come across a case in practice (other than
> pretty
> printing) where I needed to decode without knowledge of the format of
> the data.
> I guess I just haven't come across a case in practice (other than pretty
> printing) where I needed to decode without knowledge of the format of the
> data.
Pretty printing can be an important part of testing, debugging, and
securing.
> I also feel that there are worse things done with
: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
Is this a concern for real applications, things other than pretty
printers and protocol dumpers?
Yes.
I agree that it makes it difficult to
understand the
content without a format description, but it'
--
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Thursday, 8 September 2005 10:35 PM
To: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
> Is this a concern for real applications, things other than pretty
> printers and protocol
> Is this a concern for real applications, things other than pretty printers
> and protocol dumpers?
Yes.
> I agree that it makes it difficult to
> understand the
> content without a format description, but it's no worse than some
> proprietary encoding. Is translating into XML without
ssl.org
Subject: Re: OCSP, Nonce and the requestExtensions
Hi Steven,
I understood what will be the encoding when we use explicit & implicit
tagging. that is what you explained.
But what i really want to know is - In which context we will use explict
tagging & in which context we wi
rom: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz
Sent: Thursday, 8 September 2005 4:56 PM
To: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
> I understood what will be the encoding when we use explicit & implicit
> tagging.
> I understood what will be the encoding when we use explicit & implicit
> tagging. that is what you explained.
> But what i really want to know is - In which context we will use explict
> tagging & in which context we will use implicit tagging.
If one or the other is specified in a proto
I thank Steven & David for taking their time in explaining the concept
of tagging.
now with david's mail, i am almost near the point(thanks again, david)
if possible please point me to one practical situation(like x509 cert,
ocsp format...) where in this explicit vs implict tagging matters.
let
> By using explicit tagging the underlying object is encoded as it
> would be if
> standalone. Implict tagging avoids adding a wrapper around the object but
> results in the underlying object being slightly altered.
And it results in it being impossible to tell the type of the object
un
tificate }
MyStructImplicit ::= SEQUENCE {
certificate [0] IMPLICIT Certificate }
Is that any clearer?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of sravan
Sent: Thursday, 8 September 2005 3:53 PM
To: openssl-users@openssl.org
Subject: Re: OCSP, Nonce
}
MyStructImplicit ::= SEQUENCE {
certificate [0] IMPLICIT Certificate }
Is that any clearer?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of sravan
Sent: Thursday, 8 September 2005 3:53 PM
To: openssl-users@openssl.org
Subject: Re: OCSP
September 2005 3:37 PM
To: openssl-users@openssl.org
Subject: Re: OCSP, Nonce and the requestExtensions
Hi Steven,
I am sorry to say that I couldn't get what you have explained in your mail.
I don't say that it is a problem in your explaination but I can't understand
this(may be a pr
2. Curious about when to use explicit vs implicit when specifying a data
model in ASN.1?
3. Something else?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of sravan
Sent: Thursday, 8 September 2005 3:37 PM
To: openssl-users@openssl.org
Subject: Re: OCSP, Non
tead means that the underlying object is
still a standalone certificate.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steven Reddie
Sent: Thursday, 8 September 2005 2:17 PM
To: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
Wh
erlying object is
still a standalone certificate.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steven Reddie
Sent: Thursday, 8 September 2005 2:17 PM
To: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
When working with enco
2005 1:55 PM
To: openssl-users@openssl.org
Subject: Re: OCSP, Nonce and the requestExtensions
Hi Steven and others,
i have a doubt regd these tags in ASN1:
when do we use implicit tags & when do we use explicit tags?
i have read the 'layman's guide to a subset of ASN.1, BER & DE
UENCE, or in a CHOICE.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steven Reddie
Sent: Thursday, 8 September 2005 11:07 AM
To: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
Do a search for a document titled "A Lay
eddie
Sent: Thursday, 8 September 2005 11:07 AM
To: openssl-users@openssl.org
Subject: RE: OCSP, Nonce and the requestExtensions
Do a search for a document titled "A Layman's Guide to a Subset of ASN.1,
BER, and DER". The tags in this case, and generally, are used to identify
t
@openssl.org
Subject: Re: OCSP, Nonce and the requestExtensions
ah, okay. thank you!
now i know what's the number for! :)
Steven Reddie schrieb:
>That's the [2] in:
>
>TBSRequest ::= SEQUENCE {
>version [0] EXPLICIT Version DEFAULT v1,
September 2005 11:37 PM
To: openssl-users@openssl.org
Subject: Re: OCSP, Nonce and the requestExtensions
well, i do not see the CONTEXT SPECIFIC part in the spec!!!
Sascha.
Dr. Stephen Henson schrieb:
On Wed, Sep 07, 2005, Sascha Kiefer wrote:
no, that's misunderstanding (well
IONAL }
2 being the explicit context-specific tag for requestExtensions.
Regards,
Steven
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sascha Kiefer
Sent: Wednesday, 7 September 2005 11:37 PM
To: openssl-users@openssl.org
Subject: Re: OCSP, Nonce an
well, i do not see the CONTEXT SPECIFIC part in the spec!!!
Sascha.
Dr. Stephen Henson schrieb:
On Wed, Sep 07, 2005, Sascha Kiefer wrote:
no, that's misunderstanding (well, my english is not that great);
here is the complete ocsp request generated by openssl (i'm not sure
about the vers
On Wed, Sep 07, 2005, Sascha Kiefer wrote:
> no, that's misunderstanding (well, my english is not that great);
> here is the complete ocsp request generated by openssl (i'm not sure
> about the version; i'm at work and tried it at home):
>
> Offset| Len |LenByte|
> ==+==+===+===
no, that's misunderstanding (well, my english is not that great);
here is the complete ocsp request generated by openssl (i'm not sure
about the version; i'm at work and tried it at home):
Offset| Len |LenByte|
==+==+===+=
On Wed, Sep 07, 2005, Sascha Kiefer wrote:
> Hi list,
>
> openssl makes - for example: OCSP request with nonce - the
> requestExtensions a "context specific" integer.
> Why does it do this? I mean, it works, but is it mandatory?
>
>
Which version of OpenSSL are you using? Some of the older ve
For example OCSP_CERTID_free
is exported in libcrypto.so but I could not find it in the source code
Look at asn1/asn1.h adn asn1/asn1t.h
/r$
--
Rich Salz, Chief Security Architect
DataPower Technology http://www.datapower.com
XS40 XML Security Gateway http:/
1 - 100 of 143 matches
Mail list logo
