Subject: [pkix] Gathering Consensus for progressing PKI standards (?)

From: Massimiliano Pala <[email-masked]>
Date: Thu, 24 Jul 2014 13:45:58 -0400

Hi PKIX-ers,

I would like to have your opinion about a new proposal for resuming some 
work about PKIX.

I am working on some interesting items that I think they might be useful 
to work on in the PKI (not only for just browser's authentication) area 
and I was wondering if anybody would be interested in re-open the PKIX 
WG and/or start a new WG where this work can be accomplished.

(I know many people when they hear about re-opening work in the PKIX WG 
probably will have goose bumps, but I really feel there is the need to 
progress in this area)

In particular I would like to gather your opinion on the following items 
that I think it would be very important to work on:

  * Dissemination of Revocation information via DNS (i.e., OCSP over
    DNS) - improving the availability of OCSP responses and reducing
    operational costs for supporting revocation for high-volume websites.
  * Implementation of a more compact OCSP-like response format
    (different format from OCSP that might provide the same level of
    security, but more compact responses and lower network impact) for
    online authentication
  * PKI Service Discovery - in other words, how to find services related
    to a certificate (following up on the PRQP draft)
  * Provisioning of PKI services via 0-configuration protocols that
    would allow current standards (e.g., CMS, CMC, etc.) to be routed
    over self-organizing networks (e.g., P2P)
  * Integrating new advancements in crypto (ECC) into PKIX

For all these topics, I have a hard time identifying the right WG where 
the right expertise can be found and discussions / standardizations can 
happen. If there is no consensus on resuming a pkix or pkix-like WG. It 
also seems that there are some requests from the SEC area meeting 
suggesting that some discussions about PKIX could be a good thing.

To limit the lifetime of this WG, this work could be split into smaller 
WGs with very limited scope (e.g., PKIXREV, PKIXECC, PKIX2P) for the 
different projects (revocation, crypto, p2p, etc.) instead of having a 
PKIX-like one that would have a more extended charter.

I hope this e-mail will spawn some interesting discussion and possibly a 
path to move forward.

Cheers,
Max

---

From: Scott Rea <[email-masked]>
Date: Thu, 24 Jul 2014 16:10:44 -0600

+1 Max

Lots of folks I talk with still reference PKIX for this and that, and
struggle to know where to go to get consensus around implementation and
interoperability issues relating to PKI...

_Scott

On 7/24/2014 11:45 AM, Massimiliano Pala wrote:
> Hi PKIX-ers,
>
> I would like to have your opinion about a new proposal for resuming
> some work about PKIX.
>
> I am working on some interesting items that I think they might be
> useful to work on in the PKI (not only for just browser's
> authentication) area and I was wondering if anybody would be
> interested in re-open the PKIX WG and/or start a new WG where this
> work can be accomplished.
>
> (I know many people when they hear about re-opening work in the PKIX
> WG probably will have goose bumps, but I really feel there is the need
> to progress in this area)
>
> In particular I would like to gather your opinion on the following
> items that I think it would be very important to work on:
>
>   * PKI Service Discovery - in other words, how to find services
>     related to a certificate (following up on the PRQP draft)
> For all these topics, I have a hard time identifying the right WG
> where the right expertise can be found and discussions /
> standardizations can happen. If there is no consensus on resuming a
> pkix or pkix-like WG. It also seems that there are some requests from
> the SEC area meeting suggesting that some discussions about PKIX could
> be a good thing.
>
> To limit the lifetime of this WG, this work could be split into
> smaller WGs with very limited scope (e.g., PKIXREV, PKIXECC, PKIX2P)
> for the different projects (revocation, crypto, p2p, etc.) instead of
> having a PKIX-like one that would have a more extended charter.
>
> I hope this e-mail will spawn some interesting discussion and possibly
> a path to move forward.
>
> Cheers,
> Max
>
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

-- 
Scott Rea, MSc, CISSP
VP GOV/EDU Relations & Sr. PKI Architect
DigiCert, Inc.
2600 West Executive Parkway
Suite 500
Lehi, Utah 84043
http://www.digicert.com
(800) 896-7973

Em [email-masked]
Ph#(801) 701-9636
Ce#(801) 874-4114

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Jul 2014 23:30:46 +0100

Hi Max,

> I would like to have your opinion about a new proposal for resuming some

I guess s/PKIX/x.509-based PKI/ in the above would be more accurate.

As I told Max when we chatted, if there were a credible proposal for
a specific, constrained set of work items that would be likely to get
implemented and deployed and done within a reasonable period, I'd be
fine with helping making that happen.

Personally, I don't agree that resurrecting PKIX as a long lived
catch-all WG would be a good plan.

S.

---

From: "Dr. Pala" <[email-masked]>
Date: Thu, 24 Jul 2014 19:00:25 -0400

Hi Stephen,

I agree with you that having a well-chartered and well-defined scope is essential for not dragging this work for too long.

Thanks for pointing it out so we can clear the path from any possible confusion about the scope of the proposal :-) 

Cheers,
Max

> On Jul 24, 2014, at 6:30 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Max,
>

---

From: Tony Rutkowski <[email-masked]>
Date: Thu, 24 Jul 2014 20:19:50 -0400

Hi Steve,

You might want to consider the PKIX work within
the context of this material generated by
IEC/TC57/WG15.  Seems like if the world is
using PKIX's version of X.509, maybe
that's where ideas like this should be vetted, no?
.
--tony

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 25 Jul 2014 08:29:59 +0200

On 2014-07-24 19:45, Massimiliano Pala wrote:
> Hi PKIX-ers,
>
> I would like to have your opinion about a new proposal for resuming some work about PKIX.
>
> I am working on some interesting items that I think they might be useful to work on in the PKI (not only for just browser's authentication) area and I was wondering if anybody would be interested in re-open the PKIX WG and/or start a new WG where this work can be accomplished.

I would consider a somewhat slightly different angle on this if you don't mind.

There's probably very little interest in additional "PKIX" standards but there are quite a bunch of PKI use-cases which still are not working particularly well and on the horizon you have IoT (Internet of Things)that surely will depend on PKI.

Another issue is if an actual work item would require integration by platform vendors.  AFAIK the platform vendors did not participate in EST which means that it won't be a mainstream protocol.

Here is my list of things that after all these years still aren't working great:

- If you buy a blank PIV-card and insert it in a modern client platform nothing happens.  The PIV project was entirely based on the US federal government's ideas of how credentials are to be distributed.  Unfortunately for them, the majority of users outside of their community need a more dynamic scheme.  The lack of a real standard in this space is a major inhibitor for large-scale use of PKI.

- Mobile banking.  All mobile banks that use PKI (=everyone in Europe) write their entire PKI-clients since the built-in are all-over-the-map and mostly unusable.

- You mention browser-login.  Believe it or not but it is actually not a deal done.  More recent schemes like Google/FIDO U2F uses application-level challenge-response level schemes which currently are lacking for PKI.

- An even more interesting observation is that the card-industry have succeeded in deploying chip-cards for payments (not in the US but everywhere else...) but completely failed on making these useful on the Internet where the "UserID" (Card number) and "Password" (CCV in clear on the back of a card) is still the standard way of authorizing a transaction.

Well, that's quite a list of thorny problems but this is what is requested :-)

Anders

>
> (I know many people when they hear about re-opening work in the PKIX WG probably will have goose bumps, but I really feel there is the need to progress in this area)
>
> In particular I would like to gather your opinion on the following items that I think it would be very important to work on:
>
>   * Dissemination of Revocation information via DNS (i.e., OCSP over DNS) - improving the availability of OCSP responses and reducing operational costs for supporting revocation for high-volume websites.
>   * Implementation of a more compact OCSP-like response format (different format from OCSP that might provide the same level of security, but more compact responses and lower network impact) for online authentication
>   * PKI Service Discovery - in other words, how to find services related to a certificate (following up on the PRQP draft)
>   * Provisioning of PKI services via 0-configuration protocols that would allow current standards (e.g., CMS, CMC, etc.) to be routed over self-organizing networks (e.g., P2P)
> For all these topics, I have a hard time identifying the right WG where the right expertise can be found and discussions / standardizations can happen. If there is no consensus on resuming a pkix or pkix-like WG. It also seems that there are some requests from the SEC area meeting suggesting that some discussions about PKIX could be a good thing.
>
> To limit the lifetime of this WG, this work could be split into smaller WGs with very limited scope (e.g., PKIXREV, PKIXECC, PKIX2P) for the different projects (revocation, crypto, p2p, etc.) instead of having a PKIX-like one that would have a more extended charter.
>
> I hope this e-mail will spawn some interesting discussion and possibly a path to move forward.
>
> Cheers,
> Max
>
>
>

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 25 Jul 2014 10:04:36 -0400

Hi Anders,

responses inline :-D

On 7/25/14, 2:29 AM, Anders Rundgren wrote:
> [...]
> There's probably very little interest in additional "PKIX" standards 
> but there are quite a bunch of PKI use-cases which still are not 
> working particularly well and on the horizon you have IoT (Internet of 
> Things)that surely will depend on PKI.
That is exactly what I am trying to understand. I had some input from 
some commercial PKIs (and not only them) that some PKI operational 
requirements in today's internet are not completely addressed an some 
improvements in current solution should be provided in order to address 
high-volume transactions environments.

Most noticeably I would put, at the top of the list (as stated in my 
first message to the list), revocation and certificates/keys/services 
discovery (work that was started in PKIX but I did not have time to 
finish before the WG was closed down).

For reference to the Internet of "things", I would say that there are 
other WGs that are more appropriate for the discussion (e.g., ace, dice, 
?). I feel this to be out of scope and I would like to avoid what 
Stephen was talking about: a catch all for integrating other WGs work 
and or re-inventing the wheel again. I am not saying it is not 
important, but I see others more-specific WGs to be more appropriate 
targets.
> Another issue is if an actual work item would require integration by 
> platform vendors.  AFAIK the platform vendors did not participate in 
> EST which means that it won't be a mainstream protocol.
>
> - If you buy a blank PIV-card and insert it in a modern client 
> platform nothing happens.  The PIV project was entirely based on the 
> US federal government's ideas of how credentials are to be 
> distributed.  Unfortunately for them, the majority of users outside of 
> their community need a more dynamic scheme.  The lack of a real 
> standard in this space is a major inhibitor for large-scale use of PKI.
I believe that this pain point is more related to device-drivers 
standards than PKI ones. There are some defined like PKCS#11, PKCS#15, 
PC/SC - however implementations are not very consistent in providing 
standard interfaces to applications. I believe this to be a real pain 
point, but out of scope of the proposed WG.

>
> - Mobile banking.  All mobile banks that use PKI (=everyone in Europe) 
> write their entire PKI-clients since the built-in are all-over-the-map 
> and mostly unusable.
>
IMHO (and this is my personal point of view) this stems more from lack 
of expertise and not-invented-here syndrome than lack of flexibility in 
PKIs standards. This said, I do not believe that requiring specific 
clients is a problem as long as the follow the standard protocols. I 
would keep this discussion out of the scope.

> - You mention browser-login.  Believe it or not but it is actually not 
> a deal done.  More recent schemes like Google/FIDO U2F uses 
> application-level challenge-response level schemes which currently are 
> lacking for PKI.
>
I agree that some vendors might tend to use their predominant position 
in the market to experiment / impose their vision on users without 
defining standards that can be implemented by other vendors (fast moving 
standards are not really standards - IMHO). I would also keep this 
discussion out of scope since it is not related to X.509 PKI operations.

> - An even more interesting observation is that the card-industry have 
> succeeded in deploying chip-cards for payments (not in the US but 
> everywhere else...) but completely failed on making these useful on 
> the Internet where the "UserID" (Card number) and "Password" (CCV in 
> clear on the back of a card) is still the standard way of authorizing 
> a transaction.
>
You are absolutely right - there have been many reasons why not 
deploying chip-based authentication the right way (mostly because it 
would cost more maintaining the right infrastructure than dealing with 
CC fraud - just a personal opinion). Since this is not related about 
X.509 PKI operations but choices made by banks and CC companies, I this 
this should be left out of scope as well.

> Well, that's quite a list of thorny problems but this is what is 
I agree with you that these are issues (that I have seen solved in many 
"closed" environments), however, I would keep these topics outside the 
scope. Maybe, if there is consensus on working on device integration 
that could be work for a different WG than what I am trying to gather 
consensus on.

Anders, thanks for providing these points. I know you have been working 
on these for long time and I understand your frustration - maybe you 
might try to gather consensus on working on these items in other (more 
application-level related) WG or propose specific WGs for those - I 
would be interested in some of the work you are proposing. However, I 
still think they should not be included in this proposal.

Cheers,
Max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 25 Jul 2014 18:40:40 +0200

> Hi Anders,

Hi Max,
I'm trying to understand what you want to do but I fail :-(

I believe you are slightly exaggerating the universality of IETF standards;
FIDO/Google U2F is the to date *only* standard (which have gotten wide
industry support) offering end-to-end security enrollment of keys.
It is technically infeasible doing that on top of established APIs
such as PKCS #11.

OCSP which you mentioned has been integrated in TLS through "stapling"
which sounds like a very good approach.  Not good enough?

You are talking below about needs by high-volume transaction systems.
I'm not aware of any fundamental difficulties here; could you enlighten
us a bit on this?

I'm probably very stupid but what is the use-case you are targeting here:

  "Provisioning of PKI services via 0-configuration protocols that would
   allow current standards (e.g., CMS, CMC, etc.) to be routed over
   self-organizing networks (e.g., P2P)"

Maybe discovery is your actual project?  Can't such a thing be built
using a universal discovery mechanism?

Cheers,
Anders

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 28 Jul 2014 13:57:29 +0200

Anders,

Anders Rundgren wrote on 25.07.2014 08:29:
> Mobile banking.  All mobile banks that use PKI (=everyone in Europe)

everyone? FinTS (HBCI) does not use certificates but raw public keys. And 99% of online banking transactions in Germany
don't use FinTS but simple PIN/TAN.

-- 
Johannes

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 28 Jul 2014 14:29:35 +0200

> Anders,
Hi Johannes,

> everyone?

Slight exaggeration...

 > FinTS (HBCI) does not use certificates but raw public keys.

Even if they do they don't use a built-in solution which is my main point.

> And 99% of online banking transactions in Germany don't use FinTS but simple PIN/TAN.

For mobile phone banking?  BSI must been sleeping yunder a rock the last 10 years or so :-)

Anders

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 28 Jul 2014 14:57:09 +0200

> For mobile phone banking?  BSI must been sleeping yunder a rock the last 10 years or so :-)

Actually, the banks have developed secure TAN generators based on banking cards, symmetric crypto and photographic
interfaces
http://en.wikipedia.org/wiki/Transaction_authentication_number#chipTAN_.2F_cardTAN
http://en.wikipedia.org/wiki/Transaction_authentication_number#photoTAN_.2F_CrontoSign

-- 
Johannes

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Jul 2014 17:18:38 +0300

> http://en.wikipedia.org/wiki/Transaction_authentication_number#photoTAN_.2F_CrontoSign

Amazing the lengths people will go to just to avoid PKI.

Yoav

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 28 Jul 2014 19:31:10 +0200

> Amazing the lengths people will go to just to avoid PKI.

Indeed.

I think that this mainly due to the fact that client-side PKI has from
Microsoft more or less been synonymous with what the US government wanted:
*physically* distributed cards.

Certificate enrollment a la PKIX does not address the larger market, it
rather needs *token enrollment*.  Before FIDO/Google U2F this didn't exist
as anything even remotely standardized.

Anders

---

From: Massimiliano Pala <[email-masked]>
Date: Sun, 27 Jul 2014 14:00:21 -0400

> I'm trying to understand what you want to do but I fail :-(
I am sorry if I was not clear enough.

> which sounds like a very good approach.  Not good enough?

I am not arguing it is not a useful solution - providing another 
transport mechanism might be useful for clients who do not support stapling.

> I'm not aware of any fundamental difficulties here; could you enlighten

High volumes = high number of certificate validation.

> using a universal discovery mechanism?
That would be out of scope - we want something that would be usable with 
X.509 PKIs and that leverage the security properties that come from there.

Cheers,
Max

---

From: Scott Rea <[email-masked]>
Date: Thu, 24 Jul 2014 16:09:31 -0600

+1 Max

_Scott

Em [email-masked]
Ph#(801) 701-9636
Ce#(801) 874-4114