Subject: [saag] Considerations about the need to resume PKIX work

From: "Dr. Pala" <[email-masked]>
Date: Thu, 20 Jul 2017 13:35:09 +0200

Hi all,

I would like to draw the Sec Area attention on an issue that I think is 
becoming more relevant every day.

It seems quite clear that today there is a lot of work around 
authentication and encryption that make use of PKIX certificates. 
However, there is no place in IETF, today, where problems related to 
PKIX can be effectively tackled. In the following paragraphs I try to 
summarize the issue and the proposed work and a call for discussion 
around the feasibility of resuming the work in two particular areas: 
revocation and discoverability.

*The Problem

*What I noticed in recent proposals in many working groups (when it 
comes to certificate management) is that more and more people turn 
towards the use of short-lived certificates to avoid checking revocation 
information. Sometimes this choice is motivated by real technical 
considerations, but in many cases the choice is "forced" because nobody 
is currently working on fixing the two main issues related to trust 
infrastructures: efficient revocation and discoverability of services.

*The Revocation Situation*

Most of the times, when interacting with PKIs, we are still stuck with 
CRLs, OCSP if we are lucky (including stapling - available in TLS 
connections if really really lucky), and in most cases even these 
mechanisms are criticized widely by people as being inadequate today. 
This resulted in applications to use proprietary methods for checking 
revocation (e.g., CRLSet) or to skip checking all together (or mandate 
for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, 
the generation of new keys require (a) a lot of resources, and (b) a 
good source of randomness. Requiring apps / devices to generate new keys 
might seem a good idea at first, but is this better than checking 
revocation ? What about the complexity of key management ?

/Examples of possible work to address the issues are OCSP over DNS and 
some more efficient ways to verify the validity of a whole chain of 
certificates efficiently./

*The Discoverability Situation*

As far as I know, there are no standardized mechanisms that would 
provide discoverability of services that would help users and 
applications to discover Public Key Services providers and associated 
services in a dynamic fashion. When I brought it up during the BoFs of 
possible working groups where the issue could be discussed.. well, the 
proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of 
infrastructure that would facilitate interacting with PKIs ? After all, 
PKIs are the core Trust mechanism that enables reliable authentication 
and encryption over the Internet today. Such infrastructure could really 
improve the security of the Internet and make PKIs more usable from an 
application (and users) standpoint of view.

/Examples of possible work to address the issue are a PKI Resource Query 
Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms 
for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 
0-configuration support for PK)./

*Deployment Trends in the Real World*

Today I am witnessing the deployment of arguably not-well-designed PKIs 
(or, in other terms, what I call Weak PKIs) that do not provide support 
for revocation and that are expected to use CAs and EE certificates with 
validity periods of 30, 35, or 50 years (yes, also EE - especially for 
devices). Besides the fact that it is a common assumption that the 
algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT 
going to pass the test of time, ignoring the revocation could really 
affect the privacy of millions of people - and we are currently not 
doing anything at the IETF to prevent this issue.

/There is the need for simple revocation services, but arguably we do 
not have what's needed today (requires improvements)./

*IETF Specific Situation and Issues*

Why are we so unprepared to face these issues ? I would say (still 
personal point of view - based on almost 20 yrs of participation in PKI 
discussions) that these might be some of the main reasons:

  * *There are NO venues where to discuss possible solutions to existing
    problems.* The PKIX working group has been closed down (very
    arbitrarily, I might say, since there is still a lot of work needed
    to be done around PKIX as highlighted above)

  * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very
    narrow scoped Charters and only few items**(mostly quite marginal
    issues, IMO) are actually accepted as working items (w/ reference to
    SPASM and LAMPS in particular).* Solving revocation and
    discoverability issues should be the 1st item and the most important
    on the list (at least revocation) but they are not - actually when
    that was proposed to be included as part of the charter(s), the
    requests were not even acknowledged or rejected with no real
    technical reasons.

  * *The constant**nonsense of people saying that PKIs do not work as an
    excuse not to improve them while they (PKIs) are the reason we can
    deploy secure protocols and provide privacy. *It is evident that
    PKIs are here to stay, this is a fact. Their usage has increased
    exponentially in the past years and they have, so far, passed the
    test of time. IoT is one use-case. ANIMA is another. ACME is
    another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 
Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on 
these problems is really scary to me. The world moves forward, fast, and 
the IETF is standing still on this topic./*I really do not understand why.*/

*Final Considerations*

In this message I try to summarize the reasons why I think there is the 
need to provide a venue where these problems are discussed and the need 
for key people to not actively block the possibility for people that are 
willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to 
understand what the position of the whole security area is around these 
points and the proposed work.

/I hope that the discussion around this message can spark some interest 
and that work in the PKIX area can finally resume at the IETF - which 
was, in the past, thought of as the lighthouse where these issues could 
be addressed./

A small request, please, try to read this e-mail carefully and consider 
the implications of NOT taking on these tasks when replying and/or 
discussing the topic. Also, since I know this (PKIX) is a minefield for 
"political" reasons (which should not be a drive here), please keep the 
discussion on the positive / constructive side (thanks).

/If you feel like a private response is better than on the mailing list, 
please just reply privately./

Looking forward to hear your opinions on this hoping that this e-mail 
can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Jul 2017 06:05:49 -0700

Thank you very much for your thoughtful note.

I share a number of the concerns you have articulated, particularly about
the increasing proliferation of poorly-thought-through certificate schemes,
both within IETF and outside of it.  While it is not clear to me that
having an IETF forum for discussion of PKIX issues would necessarily
reverse these trends (since dubious schemes began to proliferate while PKIX
WG was active, particularly in the wireless arena), I believe your concerns
are real and deserve thorough discussion.

In general, the IETF likes WGs to operate with narrow charters for finite
periods of time, whereas some other SDOs maintain standing groups with
broad charters for long periods.

This makes it possible for widely deployed protocols to not have an active
IETF WG (although sometimes mailing lists may remain operational).  When a
WG is active,  Chairs have a tendency to strongly encourage a focus on
topics relating to the Charter so as to encourage forward progress.  This
can lead to IETF WGs being ineffective in reviewing related work in other
IETF WGs, let alone in other SDOs.

One potential solution to your concerns might be to create a WG to deal
with "PKIX extensions".  However, if the core need is to create a forum
which can be used to strengthen PKI utilization both in the IETF and
outside of it, this may not be sufficient.  For example, provision may need
to be made for review of specifications (e.g. "PKIX doctors"), or for
suitable liaison arrangements so as to encourage cooperation between SDOs
on PKI topics.

With respect to the meme that "PKIs do not work", my observation is that
the IETF seems to pay more attention to developments in the "big I"
Internet, than to developments within "little i" internets, such as private
deployments in enterprise.  Part of the reason is that participation within
IETF among users has been in decline for a very long time.  Without that
customer participation, it can be difficult for the IETF to assess protocol
success.  However, having been involved in some of the world's largest PKI
deployments, I think it is safe to say that PKI can be considered
"successful" if not "widely successful" by the criteria of RFC 5218.

On Thu, Jul 20, 2017 at 4:35 AM, Dr. Pala <[email-masked]> wrote:

> authentication and encryption that make use of PKIX certificates. However,
> there is no place in IETF, today, where problems related to PKIX can be
> effectively tackled. In the following paragraphs I try to summarize the
> issue and the proposed work and a call for discussion around the
> feasibility of resuming the work in two particular areas: revocation and
> discoverability.
>
>
>
> *The Problem *What I noticed in recent proposals in many working groups
> (when it comes to certificate management) is that more and more people turn
> considerations, but in many cases the choice is "forced" because nobody is
> currently working on fixing the two main issues related to trust
> mechanisms are criticized widely by people as being inadequate today. This
> resulted in applications to use proprietary methods for checking revocation
> (e.g., CRLSet) or to skip checking all together (or mandate for short-lived
> certificates only as in the case, for example, of STIR).
>
> the generation of new keys require (a) a lot of resources, and (b) a good
> source of randomness. Requiring apps / devices to generate new keys might
> seem a good idea at first, but is this better than checking revocation ?
> What about the complexity of key management ?
>
> *Examples of possible work to address the issues are OCSP over DNS and
> certificates efficiently.*
>
> As far as I know, there are no standardized mechanisms that would provide
> discoverability of services that would help users and applications to
> discover Public Key Services providers and associated services in a dynamic
> fashion. When I brought it up during the BoFs of possible working groups
> where the issue could be discussed.. well, the proposal was redirected to
> /dev/null (e.g., ACME, SPASM, and LAMPS).
>
> PKIs are the core Trust mechanism that enables reliable authentication and
> encryption over the Internet today. Such infrastructure could really
> *Examples of possible work to address the issue are a PKI Resource Query
> 0-configuration support for PK).*
>
> (or, in other terms, what I call Weak PKIs) that do not provide support for
> revocation and that are expected to use CAs and EE certificates with
> going to pass the test of time, ignoring the revocation could really affect
> the privacy of millions of people - and we are currently not doing anything
> at the IETF to prevent this issue.
>
> *There is the need for simple revocation services, but arguably we do not
> have what's needed today (requires improvements).*
>
>    - *There are NO venues where to discuss possible solutions to existing
>    arbitrarily, I might say, since there is still a lot of work needed to be
>    done around PKIX as highlighted above)
>
>    - *The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very
>    narrow scoped Charters and only few items** (mostly quite marginal
>    issues, IMO) are actually accepted as working items (w/ reference to SPASM
>    and LAMPS in particular).* Solving revocation and discoverability
>    issues should be the 1st item and the most important on the list (at least
>    revocation) but they are not - actually when that was proposed to be
>    included as part of the charter(s), the requests were not even acknowledged
>    or rejected with no real technical reasons.
>
>    - *The constant** nonsense of people saying that PKIs do not work as
>    an excuse not to improve them while they (PKIs) are the reason we can
>    deploy secure protocols and provide privacy. *It is evident that PKIs
>    are here to stay, this is a fact. Their usage has increased exponentially
>    in the past years and they have, so far, passed the test of time. IoT is
>    one use-case. ANIMA is another. ACME is another. Just to cite few of them.
>
> Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these
> problems is really scary to me. The world moves forward, fast, and the IETF
> is standing still on this topic.* I really do not understand why.*
>
> *Final Considerations*
>
> need to provide a venue where these problems are discussed and the need for
> key people to not actively block the possibility for people that are
> *I hope that the discussion around this message can spark some interest
> and that work in the PKIX area can finally resume at the IETF - which was,
> in the past, thought of as the lighthouse where these issues could be
> addressed.*
>
> *If you feel like a private response is better than on the mailing list,
> please just reply privately.*
>
> Looking forward to hear your opinions on this hoping that this e-mail can
> be the beginning of the end of PKIX still-standing issues :D
>
> Cheers,
> Max
>
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
>

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 20 Jul 2017 18:14:33 +0200

Hi Bernard, all,

thanks for the support - we need people that chime in and say they are 
interested so we can convince WE Chairs and ADs that there is support 
for this work to happen.

I do not know where this work might happen, it is always difficult to 
find the correct venue.

Russ Housley (thanks Russ) suggested to write down separate charter 
items with a description of the deliverable and milestones for a 
possible LAMPS (spasm) WG recharter and adoption.

Is anybody interested in helping me to provide Russ with the required 
items ?

Please let me know.

Cheers,
Max

P.S.: Again, thanks for replying to this message. I would encourage, 
again, other people to reply and indicate if they think this work might 
be important.

On 7/20/17 3:05 PM, Bernard Aboba wrote:
> I share a number of the concerns you have articulated, particularly 
> about the increasing proliferation of poorly-thought-through 
> certificate schemes, both within IETF and outside of it.  While it is 
> not clear to me that having an IETF forum for discussion of PKIX 
> issues would necessarily reverse these trends (since dubious schemes 
> began to proliferate while PKIX WG was active, particularly in the 
> wireless arena), I believe your concerns are real and deserve thorough 
> discussion.
>
> In general, the IETF likes WGs to operate with narrow charters for 
> finite periods of time, whereas some other SDOs maintain standing 
> groups with broad charters for long periods.
>
> This makes it possible for widely deployed protocols to not have an 
> active IETF WG (although sometimes mailing lists may remain 
> operational).  When a WG is active,  Chairs have a tendency to 
> strongly encourage a focus on topics relating to the Charter so as to 
> encourage forward progress.  This can lead to IETF WGs being 
> ineffective in reviewing related work in other IETF WGs, let alone in 
> other SDOs.
>
> One potential solution to your concerns might be to create a WG to 
> deal with "PKIX extensions".  However, if the core need is to create a 
> forum which can be used to strengthen PKI utilization both in the IETF 
> and outside of it, this may not be sufficient.  For example, provision 
> may need to be made for review of specifications (e.g. "PKIX 
> doctors"), or for suitable liaison arrangements so as to encourage 
> cooperation between SDOs on PKI topics.
>
> With respect to the meme that "PKIs do not work", my observation is 
> that the IETF seems to pay more attention to developments in the "big 
> I" Internet, than to developments within "little i" internets, such as 
> private deployments in enterprise.  Part of the reason is that 
> participation within IETF among users has been in decline for a very 
> long time. Without that customer participation, it can be difficult 
> for the IETF to assess protocol success.  However, having been 
> involved in some of the world's largest PKI deployments, I think it is 
> safe to say that PKI can be considered "successful" if not "widely 
> successful" by the criteria of RFC 5218.
>
>
>
>
>
> On Thu, Jul 20, 2017 at 4:35 AM, Dr. Pala <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     I would like to draw the Sec Area attention on an issue that I
>     think is becoming more relevant every day.
>
>     However, there is no place in IETF, today, where problems related
>     to PKIX can be effectively tackled. In the following paragraphs I
>     try to summarize the issue and the proposed work and a call for
>     discussion around the feasibility of resuming the work in two
>     particular areas: revocation and discoverability.
>
>     *The Problem
>
>     *What I noticed in recent proposals in many working groups (when
>     it comes to certificate management) is that more and more people
>     turn towards the use of short-lived certificates to avoid checking
>     revocation information. Sometimes this choice is motivated by real
>     technical considerations, but in many cases the choice is "forced"
>     because nobody is currently working on fixing the two main issues
>     related to trust infrastructures: efficient revocation and
>     discoverability of services.
>
>     Most of the times, when interacting with PKIs, we are still stuck
>     with CRLs, OCSP if we are lucky (including stapling - available in
>     TLS connections if really really lucky), and in most cases even
>     these mechanisms are criticized widely by people as being
>     inadequate today. This resulted in applications to use proprietary
>     methods for checking revocation (e.g., CRLSet) or to skip checking
>     all together (or mandate for short-lived certificates only as in
>     the case, for example, of STIR).
>
>     Many people today ignore the fact that, when coupled with small
>     devices, the generation of new keys require (a) a lot of
>     resources, and (b) a good source of randomness. Requiring apps /
>     devices to generate new keys might seem a good idea at first, but
>     is this better than checking revocation ? What about the
>     complexity of key management ?
>
>     /Examples of possible work to address the issues are OCSP over DNS
>     and some more efficient ways to verify the validity of a whole
>     chain of certificates efficiently./
>
>     applications to discover Public Key Services providers and
>     associated services in a dynamic fashion. When I brought it up
>     during the BoFs of possible working groups where the issue could
>     be discussed.. well, the proposal was redirected to /dev/null
>     (e.g., ACME, SPASM, and LAMPS).
>
>     Isn't that curious that still today nobody is working on some sort
>     of infrastructure that would facilitate interacting with PKIs ?
>     After all, PKIs are the core Trust mechanism that enables reliable
>     authentication and encryption over the Internet today. Such
>     infrastructure could really improve the security of the Internet
>     and make PKIs more usable from an application (and users)
>     standpoint of view.
>
>     /Examples of possible work to address the issue are a PKI Resource
>     Query Protocol (PRQP) and/or the use of P2P systems as
>     distribution mechanisms for Public Key related operations (e.g.,
>     EST, BRSKI, or ACME over P2P - 0-configuration support for PK)./
>
>     Today I am witnessing the deployment of arguably not-well-designed
>     PKIs (or, in other terms, what I call Weak PKIs) that do not
>     provide support for revocation and that are expected to use CAs
>     and EE certificates with validity periods of 30, 35, or 50 years
>     (yes, also EE - especially for devices). Besides the fact that it
>     is a common assumption that the algorithms (e.g., P-256) used in
>     these environments (e.g. IoT) are NOT going to pass the test of
>     time, ignoring the revocation could really affect the privacy of
>     millions of people - and we are currently not doing anything at
>     the IETF to prevent this issue.
>
>     /There is the need for simple revocation services, but arguably we
>     do not have what's needed today (requires improvements)./
>
>     personal point of view - based on almost 20 yrs of participation
>     in PKI discussions) that these might be some of the main reasons:
>
>       * *There are NO venues where to discuss possible solutions to
>         existing problems.* The PKIX working group has been closed
>         down (very arbitrarily, I might say, since there is still a
>         lot of work needed to be done around PKIX as highlighted above)
>
>       * *The LAMPS, SPASM, and ACME WGs have/have had, on purpose,
>         very narrow scoped Charters and only few items**(mostly quite
>         marginal issues, IMO) are actually accepted as working items
>         (w/ reference to SPASM and LAMPS in particular).* Solving
>         revocation and discoverability issues should be the 1st item
>         and the most important on the list (at least revocation) but
>         they are not - actually when that was proposed to be included
>         as part of the charter(s), the requests were not even
>         acknowledged or rejected with no real technical reasons.
>
>       * *The constant**nonsense of people saying that PKIs do not work
>         as an excuse not to improve them while they (PKIs) are the
>         reason we can deploy secure protocols and provide privacy. *It
>         is evident that PKIs are here to stay, this is a fact. Their
>         usage has increased exponentially in the past years and they
>         have, so far, passed the test of time. IoT is one use-case.
>         ANIMA is another. ACME is another. Just to cite few of them.
>
>     Moreover, things are happening in environments outside IETF (WIFI
>     2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of
>     working on these problems is really scary to me. The world moves
>     forward, fast, and the IETF is standing still on this topic./*I
>     really do not understand why.*/
>
>     *Final Considerations*
>
>     In this message I try to summarize the reasons why I think there
>     is the need to provide a venue where these problems are discussed
>     and the need for key people to not actively block the possibility
>     for people that are willing to work on this to have a venue where
>     the work can be carried out.
>
>     I think that this work is of the utter importance and I would like
>     to understand what the position of the whole security area is
>     around these points and the proposed work.
>
>     /I hope that the discussion around this message can spark some
>     interest and that work in the PKIX area can finally resume at the
>     IETF - which was, in the past, thought of as the lighthouse where
>     these issues could be addressed./
>
>     A small request, please, try to read this e-mail carefully and
>     consider the implications of NOT taking on these tasks when
>     replying and/or discussing the topic. Also, since I know this
>     (PKIX) is a minefield for "political" reasons (which should not be
>     a drive here), please keep the discussion on the positive /
>     constructive side (thanks).
>
>     /If you feel like a private response is better than on the mailing
>     list, please just reply privately./
>
>     Looking forward to hear your opinions on this hoping that this
>     e-mail can be the beginning of the end of PKIX still-standing
>     issues :D
>
>     Cheers,
>     Max
>
>     -- 
>     Best Regards,
>     Massimiliano Pala, Ph.D.
>     OpenCA Labs Director
>     OpenCA Logo
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/saag>
>
>

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 20 Jul 2017 22:28:19 +0000

Hi,

I do share most of Max’ concerns and would definitely like to see a way of addressing them, and the IETF seems a good place for doing it. To Bernard’s comment about the width and length of charters I’d reply asking whether we could attempt an “PKIXOPS” group, in the same style of other *ops groups, dedicated to operational issues. All in all, those concerns are essentially operational, as far as I can tell…

Be goode,

On 20 Jul 2017, at 15:05 , Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:

I share a number of the concerns you have articulated, particularly about the increasing proliferation of poorly-thought-through certificate schemes, both within IETF and outside of it.  While it is not clear to me that having an IETF forum for discussion of PKIX issues would necessarily reverse these trends (since dubious schemes began to proliferate while PKIX WG was active, particularly in the wireless arena), I believe your concerns are real and deserve thorough discussion.

In general, the IETF likes WGs to operate with narrow charters for finite periods of time, whereas some other SDOs maintain standing groups with broad charters for long periods.

This makes it possible for widely deployed protocols to not have an active IETF WG (although sometimes mailing lists may remain operational).  When a WG is active,  Chairs have a tendency to strongly encourage a focus on topics relating to the Charter so as to encourage forward progress.  This can lead to IETF WGs being ineffective in reviewing related work in other IETF WGs, let alone in other SDOs.

One potential solution to your concerns might be to create a WG to deal with "PKIX extensions".  However, if the core need is to create a forum which can be used to strengthen PKI utilization both in the IETF and outside of it, this may not be sufficient.  For example, provision may need to be made for review of specifications (e.g. "PKIX doctors"), or for suitable liaison arrangements so as to encourage cooperation between SDOs on PKI topics.

With respect to the meme that "PKIs do not work", my observation is that the IETF seems to pay more attention to developments in the "big I" Internet, than to developments within "little i" internets, such as private deployments in enterprise.  Part of the reason is that participation within IETF among users has been in decline for a very long time.  Without that customer participation, it can be difficult for the IETF to assess protocol success.  However, having been involved in some of the world's largest PKI deployments, I think it is safe to say that PKI can be considered "successful" if not "widely successful" by the criteria of RFC 5218.

On Thu, Jul 20, 2017 at 4:35 AM, Dr. Pala <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

I would like to draw the Sec Area attention on an issue that I think is becoming more relevant every day.

It seems quite clear that today there is a lot of work around authentication and encryption that make use of PKIX certificates. However, there is no place in IETF, today, where problems related to PKIX can be effectively tackled. In the following paragraphs I try to summarize the issue and the proposed work and a call for discussion around the feasibility of resuming the work in two particular areas: revocation and discoverability.

The Problem

What I noticed in recent proposals in many working groups (when it comes to certificate management) is that more and more people turn towards the use of short-lived certificates to avoid checking revocation information. Sometimes this choice is motivated by real technical considerations, but in many cases the choice is "forced" because nobody is currently working on fixing the two main issues related to trust infrastructures: efficient revocation and discoverability of services.

The Revocation Situation

Most of the times, when interacting with PKIs, we are still stuck with CRLs, OCSP if we are lucky (including stapling - available in TLS connections if really really lucky), and in most cases even these mechanisms are criticized widely by people as being inadequate today. This resulted in applications to use proprietary methods for checking revocation (e.g., CRLSet) or to skip checking all together (or mandate for short-lived certificates only as in the case, for example, of STIR).

Many people today ignore the fact that, when coupled with small devices, the generation of new keys require (a) a lot of resources, and (b) a good source of randomness. Requiring apps / devices to generate new keys might seem a good idea at first, but is this better than checking revocation ? What about the complexity of key management ?

Examples of possible work to address the issues are OCSP over DNS and some more efficient ways to verify the validity of a whole chain of certificates efficiently.

The Discoverability Situation

As far as I know, there are no standardized mechanisms that would provide discoverability of services that would help users and applications to discover Public Key Services providers and associated services in a dynamic fashion. When I brought it up during the BoFs of possible working groups where the issue could be discussed.. well, the proposal was redirected to /dev/null (e.g., ACME, SPASM, and LAMPS).

Isn't that curious that still today nobody is working on some sort of infrastructure that would facilitate interacting with PKIs ? After all, PKIs are the core Trust mechanism that enables reliable authentication and encryption over the Internet today. Such infrastructure could really improve the security of the Internet and make PKIs more usable from an application (and users) standpoint of view.

Examples of possible work to address the issue are a PKI Resource Query Protocol (PRQP) and/or the use of P2P systems as distribution mechanisms for Public Key related operations (e.g., EST, BRSKI, or ACME over P2P - 0-configuration support for PK).

Deployment Trends in the Real World

Today I am witnessing the deployment of arguably not-well-designed PKIs (or, in other terms, what I call Weak PKIs) that do not provide support for revocation and that are expected to use CAs and EE certificates with validity periods of 30, 35, or 50 years (yes, also EE - especially for devices). Besides the fact that it is a common assumption that the algorithms (e.g., P-256) used in these environments (e.g. IoT) are NOT going to pass the test of time, ignoring the revocation could really affect the privacy of millions of people - and we are currently not doing anything at the IETF to prevent this issue.

There is the need for simple revocation services, but arguably we do not have what's needed today (requires improvements).

IETF Specific Situation and Issues

Why are we so unprepared to face these issues ? I would say (still personal point of view - based on almost 20 yrs of participation in PKI discussions) that these might be some of the main reasons:

  *   There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)

  *   The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.

  *   The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Moreover, things are happening in environments outside IETF (WIFI 2.0 Alliance, OpenADR, CMI, etc.) and IETF un-willingness of working on these problems is really scary to me. The world moves forward, fast, and the IETF is standing still on this topic. I really do not understand why.

Final Considerations

In this message I try to summarize the reasons why I think there is the need to provide a venue where these problems are discussed and the need for key people to not actively block the possibility for people that are willing to work on this to have a venue where the work can be carried out.

I think that this work is of the utter importance and I would like to understand what the position of the whole security area is around these points and the proposed work.

I hope that the discussion around this message can spark some interest and that work in the PKIX area can finally resume at the IETF - which was, in the past, thought of as the lighthouse where these issues could be addressed.

A small request, please, try to read this e-mail carefully and consider the implications of NOT taking on these tasks when replying and/or discussing the topic. Also, since I know this (PKIX) is a minefield for "political" reasons (which should not be a drive here), please keep the discussion on the positive / constructive side (thanks).

If you feel like a private response is better than on the mailing list, please just reply privately.

Looking forward to hear your opinions on this hoping that this e-mail can be the beginning of the end of PKIX still-standing issues :D

Cheers,
Max

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director

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

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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Thu, 20 Jul 2017 17:03:05 -0700

I do support reconstituting a PKIX-like group, but my personal opinion is that the PKIX architecture is fundamentally broken. The whole idea that an auditor in Canada can attest that a certificate issued in Switzerland accurately represents a server in the office next door to me is simply wrong.

Before it was closed down it appeared that the people in the group had no interest in fixing any fundamental problems. For example: the CRL/OCSP content was revised, but intentionally did not address the disconnect between the “unknown” state in the response and the “unknown” real-world state where a CA has never heard of the certificate.

I wonder if we can avoid the problems which the PKIX WG had in the past. I also wonder if some work on X.509 alternatives/successors isn’t in order. While the situation has improved, X.509 software is still generally buggy and unreliable. Something simpler would be better.

It’s silly to pretend that “PKIs don’t work” since, e.g., the Scandinavian banking industry proves they can. The issue is we need to discourage the multiplicity of variations and ambiguity which make it difficult to interoperate and difficult to exhaustively test. We also need certs to be issued by the organizations which actually know about what the certs represent (and so you don’t have to read a CPS).

I do think a new PKIX group could be extremely useful, but only if it focuses on eliminating real-world complexity (like disconnects between semantics and representation). New, shiny extensions will generally make the situation worse.

> On Jul 20, 2017, at 3:28 PM, Diego R. Lopez <[email-masked]> wrote:
> 
> Hi,
> 
>> On 20 Jul 2017, at 15:05 , Bernard Aboba <[email-masked]> wrote:
>> 
>> 	• There are NO venues where to discuss possible solutions to existing problems. The PKIX working group has been closed down (very arbitrarily, I might say, since there is still a lot of work needed to be done around PKIX as highlighted above)
>> 
>> 	• The LAMPS, SPASM, and ACME WGs have/have had, on purpose, very narrow scoped Charters and only few items (mostly quite marginal issues, IMO) are actually accepted as working items (w/ reference to SPASM and LAMPS in particular). Solving revocation and discoverability issues should be the 1st item and the most important on the list (at least revocation) but they are not - actually when that was proposed to be included as part of the charter(s), the requests were not even acknowledged or rejected with no real technical reasons.
>> 
>> 	• The constant nonsense of people saying that PKIs do not work as an excuse not to improve them while they (PKIs) are the reason we can deploy secure protocols and provide privacy. It is evident that PKIs are here to stay, this is a fact. Their usage has increased exponentially in the past years and they have, so far, passed the test of time. IoT is one use-case. ANIMA is another. ACME is another. Just to cite few of them.

Personal email.  [email-masked]

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 21 Jul 2017 03:30:03 +0000

Henry B (Hank) Hotz, CISSP <[email-masked]> writes:

>It’s silly to pretend that “PKIs don’t work” since, e.g., the Scandinavian
>banking industry proves they can

The Scandinavian banking industry, or specifically the Norwegian one, isn't
proof that PKI works, it's proof that given a sufficiently contorted and
convoluted design you can do something that involves certificates while not
really doing anything that resembles what most people would regard as PKI.
That's literally something pretending PKIs do work, I really wouldn't use that
as an example.

And don't even talk about the Norwegian healthcare PKI, which managed to do to
their healthcare system what no Russian hacker ever could...

Peter.