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 <anders.rundgren....@gmail.com> > wrote: > >> On 2014-11-15 02:42, Dr. Massimiliano Pala wrote: >> 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 > >> >> 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 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 mailing >> list because we thought 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 >> >> >> _______________________________________________ >> pkix mailing list >> p...@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
