Subject: [pkix] Comments on draft-ietf-pkix-ocspagility-03.txt

From: "Jim Schaad" <[email-masked]>
Date: Wed, 11 Nov 2009 14:50:04 +0900

1.  Should this document update the mandatory set of algorithms that OCSP
responders much support.  I do not remember seeing that this had been done
anywhere.  Given that the last step in section 4.1 is to use a mandatory
algorithm, upgrading the set of mandatory algorithms at this point in time
would be a good idea.

2.  The sentence "This requirement is clearly insufficient to ensure
interoperability."
Should probably end w/ agility rather than interoperability.  With one
mandatory algorithm there is easily the ability to have interoperability.

3.  For the definition of sigIdentifier - are the parameters always absent
or just in this case?

4.  s/certtIdentifier/certIdentifier/

5.  Old
Although this
   case does not permit the responder to make use of the client data
   directly, the responder may anticipate the client request and
   generate a set of signed responses so as to maximize the probability
   that it is possible to generate a response that is assigned the
   highest preference weighting following the selection logic in 4.1.

Suggested new:
   The case may not permit the responder to make use of the client request
data during the response generation, however the responder still uses the
client request data during the selection of the pre-generated response to be
returned.  Responders may use the historical client requests as part of the
input to the decisions of what different algorithms should be used in
signing algorithms should be used in creating the pre-generated responses.

6.  I wonder if a security consideration should be added to address the
question of a DoS attack on the client by either changing the request data
or by not being able to get a match with the server on what algorithms
can/should be used for the signing process. Esp w/ cached responses.

7.  You are generating ASN.1 that is new - you need to have a new ASN.1
module as part of this document.

Jim

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2009 11:40:07 -0500

>algorithm, upgrading the set of mandatory algorithms at this point in time

good idea if  we get quick agreement on the upgraded set of mandatory 
algorithms.

>mandatory algorithm there is easily the ability to have interoperability.

OK.

>3.  For the definition of sigIdentifier - are the parameters always absent

Stefan?

>4.  s/certtIdentifier/certIdentifier/

OK

>signing algorithms should be used in creating the pre-generated responses.

OK.

>can/should be used for the signing process. Esp w/ cached responses.

good idea.

>module as part of this document.

right.

Steve

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 16 Nov 2009 12:08:37 -0500

Hi all,

as we are updating the OCSP protocol, I was wondering if we could add a
feature that has been widely investigated in Academia, but no fallback
has happened in the real world, yet: Privacy.

The OCSP protocol raises possible privacy concerns: by requesting the
revocation status of a specific certificate a possible ``eve'' could infer
the user's activity (or even one's location if the cert is used for
physical access to a building!). This issue is not present when using
CRLs as no disclosure of which certificate is being checked occurs.

A simple solution exists based on obfuscating the serial number of the
requested certificate. It also can be easily implemented as an extension
to the current protocol.

Is anybody interested in solving this issue ? I can probably write an
initial draft very easily. Shall this be a separate draft or an update
of the OCSP one ?

Looking forward to reading your points of view...

Best,
Max

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 16 Nov 2009 17:08:04 +0000

> initial draft very easily. Shall this be a separate draft or an update

Would've thought an https URL for the responder would be a simpler way.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 16 Nov 2009 12:38:03 -0500

Hi Stephen,

true. But there might be issues with handling the trust anchors when the service
is outsourced, behind a load balancing server, or simply when the https cert is
not the same as the ocsp one (how to verify that one via the ocsp ?). As a
result, AFAIK, many current OCSP servers are over HTTP, not HTTPS (just checking
the URLs embedded in certificates...)

HTTPS is a good point.. but currently under-deployed.. that's why I am rising
the point...

Later,
Max

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 16 Nov 2009 18:46:01 +0100

>> Would've thought an https URL for the responder would be a simpler way.

Basic problem with a HTTPS OCSP responder: Validating the responder's own  
certificate. If the certificate specify the OCSP responder itself as a the  
validator for its own certificate there is a infinite loop problem.

Solution: Certificates for OCSP responders must not specify OCSP URIs,  
only CRLs.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Nuno Ponte <[email-masked]>
Date: Mon, 16 Nov 2009 18:00:42 +0000

Em 16-11-2009 17:46, Yngve Nysaeter Pettersen escreveu:
> Basic problem with a HTTPS OCSP responder: Validating the responder's 
> own certificate. If the certificate specify the OCSP responder itself 
> as a the validator for its own certificate there is a infinite loop 
> problem.
>

     You may also add the OCSP nocheck extension to the responder's 
certificate (http://tools.ietf.org/html/rfc2560#section-4.2.2.2.1)

     Cheers,

                 Nuno

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Nov 2009 13:52:13 -0500

Max,

I think the preferred approach is to use TLS, if there is a privacy concern.
If an RP is configured to know the names of suitable OCSP responders, 
and to have certs them, it should be possible to provision a cert for 
TLS purposes as well.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 17 Nov 2009 08:17:06 -0500

> Solution: Certificates for OCSP responders must not specify OCSP URIs,  

Simpler:  OCSP responder SSL certs assert id-pkix-ocsp-nocheck.

-- Tim

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 17 Nov 2009 08:20:03 -0500

> Simpler:  OCSP responder SSL certs assert id-pkix-ocsp-nocheck.

Even more simple: use partitioned CRLs where OCSP is used

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 17 Nov 2009 14:44:33 +0100

Jim, 

Thanks for the review. Comments in line.

> good idea if  we get quick agreement on the upgraded set of mandatory

Agree.

I had some discussion about this and recall that RSA with SHA-1 and SHA 256
should be adequate, but I would like to hear the opinion of the list.

>> mandatory algorithm there is easily the ability to have interoperability.

Not sure I agree on this one. One mandatory to implement algorithm does not
ensure interoperability if other algorithms are allowed. This opens up the
possibility that the server chooses an algorithm based on it's own
preferences that the receiver does not support.

I think the text is more correct as is.

>> 3.  For the definition of sigIdentifier - are the parameters always absent

Presence and structure of parameters is defined by each signature algorithm
identifier. However, most signature algorithm identifiers have an absent
parameter structure such as signature algorithms based on DSA, RSA and
ECDSA.

The text in the draft is not correct. I have changed to:

"sigIdentifier specifies the signature algorithm the client prefers. e.g.,
algorithm=ecdsa-with-sha256. Parameters are absent for most common signature
algorithms."

>> 4.  s/certtIdentifier/certIdentifier/

Fixed

>> signing algorithms should be used in creating the pre-generated responses.

Your last sentence have some problems ("what different algorithms should be
used in signing algorithms should be used in creating the pre-generated
responses"). But I have pasted a modified version of your text

>> can/should be used for the signing process. Esp w/ cached responses.

Could do. Feel free to suggest text, otherwise I will try to add something.

>> module as part of this document.

Thanks Jim, your ASN.1 modules are included in the next version of the
draft.

/Stefan

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 17 Nov 2009 10:39:55 -0500

Hi Carl,

that would be simple... if the software out there would support
partitioned CRLs correctly.. :( I am not sure how much deployed
software actually supports them, do you have any stats ?

Also, with respect to all the https solution, it does not
consider that the privacy of the user can be compromised on
the server itself (malicious admins or the server gets hacked).
So the https does protect against MITM on the net, but nothing
more...

this could be a problem when the service is outsourced... or run
by a big CA provider whilst and the certificate is issued to an
employee of a company/gov organization/etc.. are they willing to
share those info with the CA provider ? Is the CA liable if the
logs of the server are compromised ? Can the CA use the OCSP logs
for its own purposes ?

Am I the only one concerned with this type of problems ?

Later,
Max

On 11/17/2009 08:20 AM, Carl Wallace wrote:
[...]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Nov 2009 10:52:06 -0500

Stefan,

>...
>ensure interoperability if other algorithms are allowed.

We should probably clarify this by noting that "mandatory to 
implement" algorithms MUST be supported by both servers and clients. 
However, the choice of which of these algorithm to USE in a given 
context is a local matter, and this means that a server may choose to 
restrict the algs that it supports, and thus interoperability may be 
impaired.

Steve

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 17 Nov 2009 10:53:16 -0500

No stats.  I'd guess many or all of the clients cited in David's RFC
5280 implementation report support partitioned CRLs correctly.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Massimiliano Pala
> Sent: Tuesday, November 17, 2009 10:40 AM
> Cc: [email-masked]
> Subject: Re: [pkix] OCSP and Privacy Issues
> 
> Hi Carl,
> 
> Also, with respect to all the https solution, it does not consider
that
> the privacy of the user can be compromised on the server itself
> (malicious admins or the server gets hacked).
> So the https does protect against MITM on the net, but nothing more...
> 
> this could be a problem when the service is outsourced... or run by a
> big CA provider whilst and the certificate is issued to an employee of
> a company/gov organization/etc.. are they willing to share those info
> with the CA provider ? Is the CA liable if the logs of the server are
> compromised ? Can the CA use the OCSP logs for its own purposes ?
>

---

From: "Liaquat Khan" <[email-masked]>
Date: Tue, 17 Nov 2009 20:37:06 +0400

Hi Max

I am a bit confused by your statement:

"Also, with respect to all the https solution, it does not consider that the
privacy of the user can be compromised on the server itself (malicious
admins or the server gets hacked)."

With your proposed solution of obfuscating the certID, the server would
still need to unravel this in order to check the certificate status, so you
have to accept the certID being revealed to the OCSP responder.  

Maybe by "server" you mean a front-end TLS server which then forwards the
request to OCSP responder in the back-end. However your threat scenario of
malicious admins who can penetrate TLS server may also do the same to OCSP
server.  It is true front-end TLS servers may be more exposed than back-end
OCSP servers. 

Now and then we get asked for lots of strange and wonderful things from our
OCSP responder, but so far none of our clients have asked for this.  Most
seem happy with OCSP over HTTP, although some do prefer HTTPS (mainly for
reasons of strongly authenticating the client access to the server, using
TLS/SSL client certs).

Regards
LK

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Massimiliano Pala
Sent: 17 November 2009 19:40
Cc: [email-masked]
Subject: Re: [pkix] OCSP and Privacy Issues

Hi Carl,

that would be simple... if the software out there would support partitioned
CRLs correctly.. :( I am not sure how much deployed software actually
supports them, do you have any stats ?

Also, with respect to all the https solution, it does not consider that the
privacy of the user can be compromised on the server itself (malicious
admins or the server gets hacked).
So the https does protect against MITM on the net, but nothing more...

this could be a problem when the service is outsourced... or run by a big CA
provider whilst and the certificate is issued to an employee of a
company/gov organization/etc.. are they willing to share those info with the
CA provider ? Is the CA liable if the logs of the server are compromised ?
Can the CA use the OCSP logs for its own purposes ?

Later,
Max

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 17 Nov 2009 12:33:41 -0500

Answers inline...

[...]
> have to accept the certID being revealed to the OCSP responder.

No, what you really do is to ask for a range that is sufficiently large
to guarantee n out of m type of privacy... the concept is not new (partitioned
CRLs), the addition is the use of hash functions to mask the real serial
and to evenly spread the revoked certs' identifiers in the hash-function
space. Efficient and easy to implement on top of regular OCSP servers.

> server.  It is true front-end TLS servers may be more exposed than back-end

True, that does not apply to the solution that I envisage...

> reasons of strongly authenticating the client access to the server, using

I agree. It seems to me that, as usual, in PKIs we forget privacy issues..
and we are ok with it.. :) But if we want people to be comfortable with
using PKIs, we shall try to address the issue (as well as usability) at
each level when we design our PKIs... :D

Thanks,
Max

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 18 Nov 2009 00:15:14 +0100

Max,

First I don't understand your threat scenario.
Exactly what is who able to do using a conventional OCSP responder?

You mention something like knowing what building I have entered if my cert
was used for building access. Exactly how is that attack carried out?

Secondly, partitioned CRLs are supported by any client that supports basic
CDP, IDP matching as required by RFC 5280. The complexity lies totally in
the creation of partitioned CRLs, not in using them.

Thirdly, how would your proposed solution affect backwards compatibility.
E.g. What would happen if an old client asked a new server or a new client
asked an old server of an OCSP response?

/Stefan

On 09-11-17 6:33 PM, "Massimiliano Pala" <[email-masked]>
wrote:

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 18 Nov 2009 08:31:43 +0100

Steve,

The situation in my opinion is that since algorithms other than the
mandatory to implement algorithms are allowed and since the client currently
has no mechanism to indicate it's algorithm preferences, there is always a
risk that a server choosing a non mandatory algorithm, generates a response
that the client may not support.

If you think a clarification is needed, then that is what I think should be
said.

/Stefan

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 18 Nov 2009 12:29:10 -0500

Hi Stefan,

for the threat scenario:
- A user uses his badge (with a certificate) to access a room in a
   building
- A request for the validity of the certificate is made by the access
   control system to the OCSP server

Possible threats:
- If the request is not over HTTPS an eavesdropper could know that
   that particular person is in the building (is at work, etc.)
   [physical case]
- On the server, usually, logs are kept about received requests. If
   not properly treated the activities of a particular user can be
   traced by looking at the requests on the OCSP server (and in logs
   backups...)
My point is: the data is out there and it can be used (maybe together
with `temporal' data about access to services, etc...) to collect
information about users' activities - something that can be not
acceptable especially when the service is outsourced...

for the partitioned CRLs: do you know which software is capable of
using them properly ? (I really never looked at it... I am curious
if apps out there really are able to use them - if so I might consider
adding it to OpenCA...)

for backward compatibility: by using an extension in the request the
format of the request/responses would be the same except the presence
of the extension in the request/response that mark them as "privacy
enhanced". So:
- requests made by privacy-enhanced clients could mark the extension
   as critical so that OCSP servers will reply with a malformed request;
- requests made to privacy-enhanced servers that do not support normal
   requests (but they can support both..) can simply reply with a
   malformed request or internal error messages as well.
So, basically, the required changes to the protocol is supporting an
extension in requests and responses.

In case old servers do not check for the critical extension and reply
anyway with the 'old style' - the response will carry revocation info
about a fictitious certificate and the client can easily detect if the
server supports the privacy-enhanced request by checking the presence
of the `privacy' extension in the response :D

I know that without an initial RFC it is difficult to discuss any
possible solution.. but before investing time into writing one, I'd
like to know if the list thinks it is an idea worth pursuing :D

Cheers,
Max

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 18 Nov 2009 19:00:00 +0100

Max,

>    that particular person is in the building (is at work, etc.)

This is what I guessed. If this is your threat, then I agree that running
over https should be the appropriate solution rather than obfuscating serial
numbers of the request.

>    traced by looking at the requests on the OCSP server (and in logs

I have a hard time believing that a person having access to the server logs
would be prevented from determining the users activities even if requested
certificate serial numbers was protected.

> if apps out there really are able to use them - if so I might consider
All that is needed to properly consume a partitioned CRL is to do the
required IDP/CDP match. I.e if an IDP is present in the CRL, It need to
match the CDP. That way you know that the CRL in question is the one
intended for your certificate (partitioned or not).

Any Windows client (XP and beyond) supports this.

> extension in requests and responses.

This to me appears as a too drastic change of the basic protocol compared
with the presented problem.

> like to know if the list thinks it is an idea worth pursuing :D

An initial I-D would be better :)

But I'm afraid that my position at this stage is not supportive of the
approach.

/Stefan

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 18 Nov 2009 13:38:32 -0500

On 11/18/2009 01:00 PM, Stefan Santesson wrote:
[...]
> over https should be the appropriate solution rather than obfuscating serial

Understood.

[...]
> certificate serial numbers was protected.

It is not very difficult. What you are doing with this approach is to
ask for a range of serials instead of a single serial. The domain is
in the HASH space (that's how we mask the serial) and the range is
large enough to guarantee the level of privacy required by the client.
This way it is not possible to pin-point the exact serial even if you
have full access to the OCSP server.

[...]
> Any Windows client (XP and beyond) supports this.

Thanks.. I'll make some tests to better understand how it works :D

[...]
> with the presented problem.

Mmmmm.. really ? It would be just an extension that would enable
a different behaviour that is completely compatible with the current
request/response bits on the wire... I can not think of a less drastic
approach...

[...]
> An initial I-D would be better :)

Yep, that is what I was thinking too...

> But I'm afraid that my position at this stage is not supportive of the

Thanks for replying.. it is important to have different points of view :D

Cheers,
Max

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Nov 2009 13:45:45 -0500

>If you think a clarification is needed, then that is what I think should be

I think this is a useful clarification.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 20 Nov 2009 16:50:08 -0500

Max,

I could imagine a brief document that suggests that a client who 
wishes to obscure the ID of the cert of interest can make requests 
for multiple certs,
or that the client just use CRLs.  I do worry that a client might not know
valid serial numbers for other certs from the CA in question and, as 
a result, might have a hard time producing queries that were 
consistent i this regard.

In any case, I am not enthusiastic about any changes to the base protocol,
as opposed to guidance on how to use the protocol in a more 
privacy-preserving fashion.

Steve

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 21 Nov 2009 15:14:58 -0500

Hi Steve,

thanks for the comments. I see there is no interest from the list about
this issue -- so I do not think I will invest time and effort in it. I
am a bit surprised about the fact that people are not interested, but
I will adapt.

Maybe I'll just add the extension to our software and as a browser
extension.. :D

Later,
Max

On 11/20/2009 04:50 PM, Stephen Kent wrote:
> Max,
>
> I could imagine a brief document that suggests that a client who wishes
> to obscure the ID of the cert of interest can make requests for multiple
> certs,
> valid serial numbers for other certs from the CA in question and, as a
> result, might have a hard time producing queries that were consistent i
> this regard.
>