Subject: [pkix] OCSP POST vs GET

From: daniel bryan <[email-masked]>
Date: Thu, 19 Jul 2012 20:26:27 -0400

I am using windows 2k8r2 certificate services, win2k8r2 IIS, and a 3rd
party OCSP responder made by actividentity.  According to my CAPI2 log on
the IIS server, its sending a GET request to my OCSP responder, and getting
an error saying malformed ocsp request.  If I use a 3rd party CAPI plugin
on the IIS machine it sends POST request to the OCSP responder and recieves
no errors.

Is there a way I can tell windows to send OCSP request as a POST instead of
a GET?

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 20 Jul 2012 08:30:28 +0200

You should ask ActivIdentity to correct the issue. It's probably something
stupidly simple.
If they can't or don't want to, then go on POST, but that's a regression,
IMHO.

-- 
Erwann.

>
> Is there a way I can tell windows to send OCSP request as a POST instead
of a GET?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Jul 2012 07:55:17 -0400

http://www.ietf.org/rfc/rfc2560.txt

A.1.1 Request

   HTTP based OCSP requests can use either the GET or the POST method to
   submit their requests. To enable HTTP caching, small requests (that
   after encoding are less than 255 bytes), MAY be submitted using GET.
   If HTTP caching is not important, or the request is greater than 255
   bytes, the request SHOULD be submitted using POST.

ActivIdentity is not compliant with the spec here. The original choice
to support use of GET was deliberate as the requests are cacheable.

On Thu, Jul 19, 2012 at 8:26 PM, daniel bryan <[email-masked]> wrote:
> I am using windows 2k8r2 certificate services, win2k8r2 IIS, and a 3rd party
> OCSP responder made by actividentity.  According to my CAPI2 log on the IIS
> server, its sending a GET request to my OCSP responder, and getting an error
> saying malformed ocsp request.  If I use a 3rd party CAPI plugin on the IIS
> machine it sends POST request to the OCSP responder and recieves no errors.
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

-- 
Website: http://hallambaker.com/

---

From: daniel bryan <[email-masked]>
Date: Fri, 20 Jul 2012 12:37:32 -0400

So talking with the actividentity engineer it seems that the responder is
giving an HTTP 200 code to the get Request.

192.168.0.4 - - [20/Jul/2012:12:30:39 -0400] "GET
//MEswSTBHMEUwQzAJBgUrDgMCGgUABBSi2nZd042bpHbA74Tx6u9YvckomQQUdz7WgFFmZnD28j%2ByUZ%2FBusIYxMsCCmG70vsAAAAAAAY%3D
HTTP/1.1" 200 5

yet, IIS recieved a malformed OCSP response.  Is there a way to see the
response that IIS rfecieved and determine why its malformed?

On Fri, Jul 20, 2012 at 7:55 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> party
> of

-- 
Dan Bryan
[email-masked]
443 333 1147

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 20 Jul 2012 19:07:16 +0200

All,

I finally got to tackle the update of RFC2560bis document.

At the last ITEF/PKIX meeting we concluded that this effort needs a restart.
The changes in the 04 draft compared to the original document are so
extensive that it is hard to make sure that the update is actually
compatible with the existing standard.

I have therefore made a new draft almost from scratch, trying to change as
little as possible compared to RFC 2560.

The new draft is available here:
http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_02.txt

A diff compared to RFC 2560 is available here:
http://tinyurl.com/rfc2560bis05diff

The list of changes (this list is included in the draft) is:

This document differs from RFC 2560 in only a few areas:

   o  Section 4.1.1 specifies the ASN.1 syntax for the nonce
      extension, which was missing in RFC 2560.

   o  Section 4.4.7 specifies a new extension that may be included in
      a request message to specify signature algorithms the client
      would prefer the server use to sign the response as specified
      in [RFC6277].

   o  Section 2.3 extends the use of the "unauthorized" error
      response, as specified in [RFC5019].

   o  Section 4.2.1 and 4.2.2.3 states that a response may include
      revocation status information for certificates that were not
      included in the request, as permitted in [RFC5019].

   o  Section 4.3 changes set of cryptographic algorithms that
      clients must support and the set of cryptographic algorithms
      that clients should support as specified in [RFC6277].

   o Section 4.2.2.2 has been updated to clarify when a responder is
      considered an Authorized Responder.

Section headings and numbering are as much as possible kept intact from RFC
2560.
The ASN-1 modules are imported form rfc2560bis draft 04.

What important updates did I miss to cover in this draft?

If this is considered a good starting point for a restarted draft effort,
then I will publish this as draft 05 as soon as the draft submission is
re-opened.

/Stefan

---

From: daniel bryan <[email-masked]>
Date: Fri, 20 Jul 2012 13:07:50 -0400

here is a capture of the packets

-- 
Dan Bryan
[email-masked]
443 333 1147

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 20 Jul 2012 19:16:12 +0200

The "malformedRequest" response is the 5 bytes response it received (the 5
at the end is the body size of the response).

There's an extra leading '/' in the request. It may come from an extra
trailing '/' at the OCSP URL. Check your certificates, read the
authorityInfoAccess extension.

RFC2560 states this:

[...]
GET {url}/{url-encoding of base-64 encoding of the DER encoding of
   the OCSPRequest}
[...]

If your OCSP URL contains a trailing '/', the client will add one, and
you'll come up with 2, that's what you get here.

Ignoring the heading '/' gives a valid request, for an issuerKeyHash equal
to a2:da:76:5d:d3:8d:9b:a4:76:c0:ef:84:f1:ea:ef:58:bd:c9:28:99 and a serial
number equal to 61BBD2FB000000000006 (in hex).

2012/7/20 daniel bryan <[email-masked]>

-- 
Erwann.

---

From: daniel bryan <[email-masked]>
Date: Fri, 20 Jul 2012 13:31:03 -0400

Thanks,

I noticed my AIA does not have a / on the CA , but it does on the cert the
CA issued.  See screen shots.  Any thoughts?

-- 
Dan Bryan
[email-masked]
443 333 1147

---

From: daniel bryan <[email-masked]>
Date: Fri, 20 Jul 2012 13:36:57 -0400

GET
/MEswSTBHMEUwQzAJBgUrDgMCGgUABBSi2nZd042bpHbA74Tx6u9YvckomQQUdz7WgFFmZnD28j%2ByUZ%2FBusIYxMsCCmG70vsAAAAAAAY%3D
HTTP/1.1

Connection: Keep-Alive

Accept: */*

User-Agent: Microsoft-CryptoAPI/6.1

Host: 192.168.0.22:3502

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: application/ocsp-response

Content-Length: 2417

Date: Fri, 20 Jul 2012 17:34:27 GMT

0..m
.....f0..b..+.....0.....S0..O0..........uLAz]_Fby@
....\U...20120720162919Z0...0k0C0...+..........v]....v......X..(...w>..Qffp..?.Q........
.+.......
....20120719220759Z....20120727102759Z0k0C0...+..........v]....v......X..(...w>..Qffp..?.Q........
...t..........20120719220759Z....20120727102759Z0..0C0...+..........v]....v......X..(...w>..Qffp..?.Q........
a.............20120719221700Z..
....20120719220759Z....20120727102759Z0k0C0...+..........v]....v......X..(...w>..Qffp..?.Q........
a.............20120719220759Z....20120727102759Z0k0C0...+..........v]....v......X..(...w>..Qffp..?.Q........
a..h..........20120719220759Z....20120727102759Z0|0C0...+..........v]....v......X..(...w>..Qffp..?.Q........
a.............20120719210300Z..20120719220759Z....20120727102759Z0|0C0...+..........v]....v......X..(...w>..Qffp..?.Q........
a.j...........20120719210300Z..20120719220759Z....20120727102759Z0q0I0...+..........v]....v......X..(...w>..Qffp..?.Q.........rC.m....A.t..v.{....20120719220759Z....20120727102759Z0
..*.H..
.........M..R'..u.g9.U}....F.5#jc.|.W/.....f....?..'3F~.....P....F[......-n.#{r...zG|.+...0.=...Qg>~.....Uk.V.<...........h............=.....0...0...0.........
...u......0
..*.H..
.....0J1.0..
..&...,d....net1.0..
..&...,d....securesub1.0...U....securesub-DC-CA0..
120720161756Z.
140720161756Z0F1.0..
..&...,d....net1.0..
..&...,d....Securesub1.0...U....ocspsigning0..0
..*.H..
.........0........[>.......w..]D2..W.u.K......p.[.y.s..VTz...<*..5.M.^
.d.k....$h.C....s.W;..x....H.9.$*.[..........3|x..(.J....-{13A....{..............F0..B0...U.%..0
..+.......0...U.........uLAz]_Fby@
....\U.0...U.#..0...w>..Qffp..?.Q.......0....U.....0..0...........ldap:///CN=securesub-DC-CA,CN=DC,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=securesub,DC=net?certificateRevocationList?base?objectClass=cRLDistributionPoint0....+..........0..0....+.....0....ldap:///CN=securesub-DC-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=securesub,DC=net?cACertificate?base?objectClass=certificationAuthority0%..+.....0...
http://192.168.0.22:3502/0!..+.....7.......W.e.b.S.e.r.v.e.r0...U...........0
..*.H..
...........QD.=..
.^.9_........x........H.@
)#..nn.2,.+.3.q......s.....X.#.!...T.\.....qx..s.....gO...........&l/b...%.$[...0.K3.*..C[.....(..W0T.H..B.k...5
....P.\
b.........x..t%.M......({n4M............w.....``..|..`.....!.....Y.....e..0.!.t{.."..I.V......`I.h$M.Z

-- 
Dan Bryan
[email-masked]
443 333 1147

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 20 Jul 2012 20:14:42 +0200

The screenshot doesn't show enough information.

The attached certificate has this OCSP URL: http://192.168.0.22:3502/
A trailing '/'. Remove it, get a new certificate, and try it.

>> The "malformedRequest" response is the 5 bytes response it received (the
>> 5 at the end is the body size of the response).
>>
>> Ignoring the heading '/' gives a valid request, for an issuerKeyHash
>> equal to a2:da:76:5d:d3:8d:9b:a4:76:c0:ef:84:f1:ea:ef:58:bd:c9:28:99 and a
>> serial number equal to 61BBD2FB000000000006 (in hex).
>>
>>> So talking with the actividentity engineer it seems that the responder
>>> is giving an HTTP 200 code to the get Request.
>>>
-- 
Erwann.

---

From: daniel bryan <[email-masked]>
Date: Fri, 20 Jul 2012 14:44:50 -0400

Thanks for all the responses.  So the certificate does in deed have "
http://192.168.0.22:3502/ " , but the screen shot of the CA shows the AIA
to be " http://192.168.0.22:3502"

I am unsure on how to remove the / from the issued certificate.

On Fri, Jul 20, 2012 at 2:14 PM, Erwann Abalea <[email-masked]> wrote:

>> I noticed my AIA does not have a / on the CA , but it does on the cert
>> the CA issued.  See screen shots.  Any thoughts?
>>

-- 
Dan Bryan
[email-masked]
443 333 1147

---

From: daniel bryan <[email-masked]>
Date: Fri, 20 Jul 2012 16:00:43 -0400

So I managed to get rid of the OCSP_MALFORMED_REQUEST_RESPONSE error in the
logs by reissuing all certs with the only entry in AIA being "
http://192.168.0.22" I deleted the ldap:///CN= entry that was included in
the AIA extension.

I think I have almost got rid of all the errors by doing that. currently
there is only one error...

Current status:

using native windows I am able to use a revoked certificate to access a
website due to the fact that it says the revocation server is offline" and
it seems to "fail open" allowing me access when I shouldnt be allowed.

Yet, using the actividentity plugin, it is able to intercept
and communicate with the OCSP server and identifies the certificate as
revoked and denys the users from accessing the website.

Would someone kindly look at my 2 attached event logs and help me determine
why windows believes the revocation server is offline? Basically a revoked
user called dano, is attempting to authenticate to
mail.securesub.net(which is a SLL cert required website/). I expect
him to be denied in both
conditions.

On Fri, Jul 20, 2012 at 2:44 PM, daniel bryan <[email-masked]> wrote:

>>> On Fri, Jul 20, 2012 at 1:16 PM, Erwann Abalea <[email-masked]>wrote:
>>>
>>>> The "malformedRequest" response is the 5 bytes response it received
>>>> (the 5 at the end is the body size of the response).
>>>>
>>>>> yet, IIS recieved a malformed OCSP response.  Is there a way to see
>>>>> the response that IIS rfecieved and determine why its malformed?
>>>>>
>>>>
>> --
>> Erwann.
>>
>
>
>
> --
> Dan Bryan
> [email-masked]
> 443 333 1147
>
>

-- 
Dan Bryan
[email-masked]
443 333 1147

---

From: daniel bryan <[email-masked]>
Date: Fri, 20 Jul 2012 17:01:30 -0400

One final note...

the 4 most recent requests were done with windows CAPI (it looks like its
encoded).  The others were done with the actividentity CAPI plugin (with
all the successes).

On Fri, Jul 20, 2012 at 4:00 PM, daniel bryan <[email-masked]> wrote:

> So I managed to get rid of the OCSP_MALFORMED_REQUEST_RESPONSE error in
> the logs by reissuing all certs with the only entry in AIA being "
> Would someone kindly look at my 2 attached event logs and help me
> determine why windows believes the revocation server is
> offline? Basically a revoked user called dano, is attempting to
> authenticate to mail.securesub.net (which is a SLL cert required
> website/). I expect him to be denied in both conditions.
>
>
>
> On Fri, Jul 20, 2012 at 2:44 PM, daniel bryan <[email-masked]>wrote:
>
>> http://192.168.0.22:3502/ " , but the screen shot of the CA shows the
>> AIA to be " http://192.168.0.22:3502"
>>
>>>>>> So talking with the actividentity engineer it seems that the
>>>>>> responder is giving an HTTP 200 code to the get Request.
>>>>>>

-- 
Dan Bryan
[email-masked]
443 333 1147

---

From: Sean Turner <[email-masked]>
Date: Sun, 22 Jul 2012 23:14:11 -0400

Stefan,

In terms of figuring out what's changed in the draft, this version is 
much easier to follow.

The addition of the list of changes was definitely a good idea 
(definitely saved yourself a comment from me during AD review).

I haven't checked this but did you incorporate the verified errata and 
considered the HFDU (hold for document update) errata?

spt

On 7/20/12 1:07 PM, Stefan Santesson wrote:
> I have therefore made a new draft almost from scratch, trying to change
> as little as possible compared to RFC 2560.
>
> Section headings and numbering are as much as possible kept intact from
> RFC 2560.
> If this is considered a good starting point for a restarted draft
> effort, then I will publish this as draft 05 as soon as the draft
> submission is re-opened.
>
> /Stefan
>
>
>
>
>
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 Jul 2012 12:11:38 +0200

Sean,

Good point,

I actually forgot to process the erratas. I'll go ahead and do that and
will put up a new version.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 23 Jul 2012 15:40:33 +0200

Agenda for Vancouver is up:
http://www.ietf.org/proceedings/84/agenda/agenda-84-pkix

Please let me know if I missed anything.

/Stefan

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Jul 2012 20:13:41 -0400

Sean will no doubt bring it up, but he wants to discuss the tree
walking thing. I can make slides.

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 24 Jul 2012 16:43:37 +0200

Reposted the draft now with all but one errata included:
http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_03.txt

Diff to RFC 2560:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/rfc/rfc2560.txt&u
rl2=http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_03.txt

The only errata not adopted is editorial errata 3251
The errata does not suggest any text that is better in my mind, and that
section is in any way the main subject for final wordsmithing in the
process to complete this update (section 4.2.2.2)

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 24 Jul 2012 16:56:00 +0200

Agenda updated.

Status is still preliminary.

/Stefan

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 25 Jul 2012 12:17:31 +0200

§4.4.1, the OID definitions paging is messed (id-pkix-ocsp-nonce is split).
§4.2.2.2.1, that seems stupid, but couldn't you also add an ASN.1 syntax
for the ocspNoCheck extension? OCSP responders with an empty value for this
extension have been seen (it's not permitted by the standard).

2012/7/24 Stefan Santesson <[email-masked]>

-- 
Erwann.

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 26 Jul 2012 16:53:47 +1000

Stefan,

Will the ASN.1 module [Appendix B.1] be replaced with the updated module in RFC5912 “New ASN.1 for PKIX” section 4?
I think it should be replaced.

I would add the following to the OCSP module in RFC5912, between the “-- Response Extensions” and “-- Object Identifiers” parts (perhaps I should submit this as an errata to RFC5912 as well):

  -- Certificate Extension

  ext-ocsp-nocheck EXTENSION ::= { SYNTAX
    NULL IDENTIFIED BY id-pkix-ocsp-nocheck }

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Erwann Abalea
Sent: Wednesday, 25 July 2012 8:18 PM
To: Stefan Santesson
Cc: [email-masked]
Subject: Re: [pkix] RFC2560bis update

§4.4.1, the OID definitions paging is messed (id-pkix-ocsp-nonce is split).
§4.2.2.2.1, that seems stupid, but couldn't you also add an ASN.1 syntax for the ocspNoCheck extension? OCSP responders with an empty value for this extension have been seen (it's not permitted by the standard).
2012/7/24 Stefan Santesson <[email-masked]<mailto:[email-masked]>>

Diff to RFC 2560:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/rfc/rfc2560.txt&u
rl2=http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_03.txt<http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/rfc/rfc2560.txt&u%0d%0arl2=http://aaa-sec.com/ietf/rfc2560bis/draft-ietf-pkix-rfc2560bis-05_03.txt>

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 30 Jul 2012 09:49:17 -0700

The final agenda has been posted:
http://www.ietf.org/proceedings/84/agenda/agenda-84-pkix

/Stefan