Subject: [pkix] Proposal for working on PKIX revocation open issues

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Fri, 14 Nov 2014 15:42:31 -1000

Dear PKIX Enthusiasts,

Although great work has been done in the past... 20 years.. (?) on 
providing very good protocols in the PKIX work, I think that we all 
agree that we still have some unresolved issues. In particular, the 
revocation is still a hot topic (especially for online environments) 
could use improvement over the current status of things. In particular, 
by looking at current specifications, some work is needed to address 
concerns especially in non-web environments.

For example, current specifications about OCSP stapling do not address 
the case of client authentication (which is a widespread use case 
outside the web environment) or, again, defining some new transport 
protocols for delivering OCSP responses which might reduce operational 
costs for revocation service providers.

After proposing the idea to Stephen Farrell and Kathleen Moriarty, we 
would like to know if there might be interests in participating in 
updating the status of the current revocation mechanisms for PKIX. This 
said, the scope of the work I am proposing is very limited. Specifically:

(a) Defining new transport protocols for revocation information 
availability (e.g., OCSP over DNS or OCSP over LDAP)
(b) (Possibly) defining a more lightweight revocation mechanisms (e.g. 
Lightweight Revocation Tokens)
(c) (Possibly) helping other working groups to revise and update how 
revocation information are provided (e.g., the client authentication case)
(d) (Possibly) introducing privacy consideration when it comes to 
revocation checking

Because of these considerations, I am proposing to start a conversation 
- for now, Stephen and Kathleen suggested we use (or "abuse") the "The 
Right Key" mailing list to see if there might be enough interest in the 
work from implementers to address these issues. I know that we (OpenCA) 
are interested in implementing these features, and we would like that 
the work would be standardized.

At minimal, I would like (a) to happen. This could be achieved in 6 
months (and we might not even need to meet). (b) and (c) are also 
desirable in order to provide better support for non-browsers and small 
devices (AFAIK, some work might be relevant for DICE). (d) is something 
that we should, I think, all be mindful and at least some considerations 
should be provided. The scope of the work, however, will be limited to 
revocation.

Please, if you are interested and would like to start the discussion, 
post your opinion on [email-masked] - also, please, circulate this 
proposal to anybody who might be interested in collaborating on this issue.

Please also note that we did decide not to use the [email-masked] mailing 
list because we thought [email-masked] might provide a more active 
pool of implementors.

Looking forward to receive all your inputs and start working on the topics.

Cheers,
Max

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 15 Nov 2014 05:31:55 +0100

> Dear PKIX Enthusiasts,

Thanx :-)

Just for my curiosity, have the OpenCA team implemented EST?

If not, I think this highlights the core problem which is adoption of standards.
Microsoft, Intel, et. al. spent *hundreds of millions of dollars* on standardization
of TPMs only to find that the bulk of the mobile device market (their competitors...)
had taken another, more agile path.

Since HTTP seems to the lowest common denominator for all networked
devices, it looks like that you will run into serious adoption issues.

I must admit that I don't understand what problem you want to solve
in the context of *client authentication*.  The client's ability
to gather revocation information abouts its own keys?  That's hardly
a problem worth solving.  It sounds like a W3C proposal that I once saw
which was about introducing an API at the client-side for revoking your
own certificate(s).

As you can see the remains of the PKIX WG still don't want to discuss
requirements like imposed by "Derived Credentials" which actually is
a core PKI application that eventually will be used by everybody.

Anders

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

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 15 Nov 2014 06:11:42 +0100

Since you want to do something in revocation I would like to
describe an existing potentially global PKI-using system that
maybe could be improved.

The EU e-passport system needs for crossborder-checking of biometrics
a pretty elaborate PKI scheme which among many things require
the parties to expose two public ports on the Internet; one for
the actual communication using HTTPS[1] and another for publishing
CRLs using HTTP.  This isn't rocket-science but it still requires
multiple FW settings and proxies.  If OCSP responses could be
stapled (TLS client cert auth is used), relying parties would only
have to open a single inbound port.  Cross-border reliability would
probably also be improved since the client (sender) wouldn't be able
to submit any data unless its OCSP is running (the PKIs are unique
per country).

TLS 1.3 and 2.0 are in the workings so the timing is right...

Anders

1] I might add that I believe HTTPS with client certificate auth
is a very poor choice for cross-border communication when each party
run their own PKI. Signed messages permit a multi-tier architecture
and quarantining of not yet trusted messages, greatly simplifying
operation.  BSI are experts on crypto, but n00bs on IT :-)

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 14 Nov 2014 23:55:44 -0800

Hi Anders,

thanks for the reply. The scope of this proposal was restricted on purpose to see if we gather consensus on a specific area:  revocation, therefore I am limiting my reply to that area to allow the conversation to be focused. Maybe your proposal could be future work for some other pkix-related wg, but it is not in scope with this proposal.

For the HTTP comment, I respectfully disagree. There are many areas where applications use authentication and confidentiality but do not talk HTTP. However, even if they do, they are not browsers and requirements and their capabilities might be different. However, as I see it, this work will be orthogonal to the application protocol.

For the question about client authentication, the only thing that I see missing today is the possibility, for clients, to present their own revocation information (i.e. being able to staple OCSPD responses for the presented certificate) [RFC 6961 only defines client requests for certificate status]. This would provide the server side with the possibility to request/require the client to provide information about their certificate chains.

I think this might have the positive effects for client-side certificate authentication and, ultimately, deployment.

Cheers,
Max

> On Nov 14, 2014, at 8:31 PM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 15 Nov 2014 09:04:58 +0100

> For the question about client authentication, the only thing that I see missing today is the possibility, for clients, to present their own revocation information (i.e. being able to staple OCSPD r…

Good, this was what I proposed in another posting.

The only real problem I know of here is that many commercial client PKIs do not "publish" revocation information, they only make it available for paying RPs which excludes clients from the plot.

Anders

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 15 Nov 2014 00:42:05 -0800

Thanks Anders!

Do you have any contacts for people working at that project? We might want to reach out to them as possible implementors and maybe start a conversation with them about possible requirements ? And eventually let them know about the progresses we might accomplish in the area.

Cheers,
Max

P.S.: Since Stephen and Kathleen asked me to have the conversation on The Right Key mailing list ([email-masked]), please could you send the replies only there? We should not use both therightkey and the pkix MLs :-)

> On Nov 14, 2014, at 9:11 PM, Anders Rundgren <[email-masked]> wrote:
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Nov 2014 10:12:47 -0800

On Nov 14, 2014, at 5:42 PM, Dr. Massimiliano Pala <[email-masked]> wrote:
> (a) Defining new transport protocols for revocation information availability (e.g., OCSP over DNS or OCSP over LDAP)

If you mean "pre-recorded (sometimes called 'stapled') OCSP responses", yes, this is useful. Maybe even over HTTP!

> (b) (Possibly) defining a more lightweight revocation mechanisms (e.g. Lightweight Revocation Tokens)

Not interested.

> (c) (Possibly) helping other working groups to revise and update how revocation information are provided (e.g., the client authentication case)

Not interested.

> (d) (Possibly) introducing privacy consideration when it comes to revocation checking

Slightly interested.

--Paul Hoffman

---

From: Ben Laurie <[email-masked]>
Date: Mon, 17 Nov 2014 15:52:48 +0000

> (d) (Possibly) introducing privacy consideration when it comes to

FWIW, we (Google) are interested in doing the same thing for revocation
that CT does for certs - i.e. providing a verifiable log/map of revocation
status.

Not sure if that fits into your remit above (on the face of it, it does
not).

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Nov 2014 10:31:06 -0600

> (e.g., OCSP over DNS or OCSP over LDAP)

OCSP lacks for various bindings to various transports.  I think
defining more such bindings would be nice.

> Lightweight Revocation Tokens)

What would that look like?  I think stapled DANE is about as
light-weight as it's going to get.

> revocation information are provided (e.g., the client authentication case)

They can do this themselves.  Assuming TLS 1.3 retains user
authentication with certificates, let the TLS WG add stapled OCSP.

> (d) (Possibly) introducing privacy consideration when it comes to revocation

If you staple OCSP then the main privacy considerations are:

a) how the end entities' certs and OCSP responses are transported
(e.g., we'd need TLS to have a mode that provides confidentiality to
the client cert, which IIUC is not in the cards for 1.3),

b) how to provide privacy protection for DNS (the elephant in the room).

Anything to be done in TLS belongs squarely in the TLS WG.  I'd love
to see DNS confidentiality, but I think we should get our priorities
straight: opportunistic security, TLS 1.3, CT, DNSSEC/DANE deployment,
...  I confess that my list of priorities is something one could argue
about, and that if we have the energy to do more of these things
concurrently, then we should.

Nico
--