+1 to using a CT-like structure to also provide revocation information.
On 11/17/2014 8:52 AM, Ben Laurie wrote:
On Sat Nov 15 2014 at 1:42:31 AM Dr. Massimiliano Pala
<massimiliano.p...@gmail.com <mailto:massimiliano.p...@gmail.com>> wrote:
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
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).
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 therightkey@ietf.org
<mailto:therightkey@ietf.org> - 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 p...@ietf.org
<mailto:p...@ietf.org> mailing
list because we thought therightkey@ietf.org
<mailto:therightkey@ietf.org> might provide a more active
pool of implementors.
Looking forward to receive all your inputs and start working on
the topics.
Cheers,
Max
_______________________________________________
therightkey mailing list
therightkey@ietf.org <mailto:therightkey@ietf.org>
https://www.ietf.org/mailman/listinfo/therightkey
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
_______________________________________________
therightkey mailing list
therightkey@ietf.org
https://www.ietf.org/mailman/listinfo/therightkey
