Subject: [pkix] Proposal for a new Working Item: PKIX API

From: Massimiliano Pala <[email-masked]>
Date: Tue, 21 Sep 2010 12:36:28 +0200

Dear PKI-ers,

I have been juggling with the idea of writing an high-level PKIX API RFC.
The purpose for this work is to enable a common interface reference that
can be implemented across different systems and by using different crypto
providers.

Before some of you will say 'we deal only with bits-on-the-wire here', I
would like to point out that the LDAP API specification is the best thing
that happened. In fact, developing LDAP enabled applications does not
require much efforts when porting.

I think we need the same portability when it comes to PKIX applications.
If you ever developed a real-world PKIX application you know that this
API would improve the usability of PKIX certificates and simplify the
developers' lives - thus resulting in lower costs in developing apps that
support PKIX for companies.

Does anybody is interested in participating to this initial proposal ?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-8734
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Sep 2010 20:04:40 -0400

At 12:36 PM +0200 9/21/10, Massimiliano Pala wrote:
>Content-Type: multipart/signed; 
>protocol="application/pkcs7-signature"; micalg=sha1; 
>boundary="------------ms000702040504030400060906"
>
>Dear PKI-ers,
>

Max,

We have a few significant examples of IETF standards for APIs. Thus 
your proposal is not at all out of scope for the IETF. The critical 
issue will be whether your message attracts sufficient, focused, 
attention.

Steve

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 22 Sep 2010 09:19:25 +0200

Hi Stephen, all,

I agree.. I hope that there's enough practitioners and PKIX experts still
on the list who want to solve the usability of PKIX problem for developers.
I know that the project of writing such an I-D / RFC is very ambitious,
but I think it's worth the shot :)

Later,
Max

On 09/22/2010 02:04 AM, Stephen Kent wrote:
> Max,
>
> We have a few significant examples of IETF standards for APIs. Thus your
> proposal is not at all out of scope for the IETF. The critical issue
> will be whether your message attracts sufficient, focused, attention.

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 22 Sep 2010 09:50:13 +0200

Ambitious indeed. There are so many things to consider.

- what language? Java, C, C#, Lisp, PHP, WebService (soap/rest)
- where there are existing APIs such as with java, how does that fit in?
- etc

The java API for LDAP (as was the example) is admittedly quite usable, 
and makes it rather easy to change implementation. So the goal is sure 
usable.

Regards,
Tomas

On 09/22/2010 09:19 AM, Massimiliano Pala wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 22 Sep 2010 08:41:44 -0400

Maybe we could just adopt a subset of cryptlib and call it done.  :)

I'm only being partially snarky; there's quite a number of PKI abstractions out there, mostly embedded in larger crypto or security APIs, so there certainly plenty of ideas (some good, some bad) to draw from.

I like the idea but don't know what if anything I could contribute.

-- Tim

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Massimiliano Pala
>Sent: Wednesday, September 22, 2010 2:19 AM
>To: [email-masked]
>Subject: Re: [pkix] Proposal for a new Working Item: PKIX API
>
>Hi Stephen, all,
>
>your

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 22 Sep 2010 08:45:26 -0400

>- what language? Java, C, C#, Lisp, PHP, WebService (soap/rest)

Doesn't matter at this level.  We could write it in your pick of IDLs and it would translate.  

>- where there are existing APIs such as with java, how does that fit in?

Two words:  Wrapper library.

-- Tim

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 22 Sep 2010 15:12:55 +0200

Hi Tim, all,

totally agree. In addition, I think that, in the case we to provide some
details about the basic data structures, we should use the C language.
This because:
- the vast majority of OSes are C based
- it is easier going from C to any other language than viceversa

Ideally the wrappers for other languages would follow the same API. In some
cases, we could write small Appendixes with indications on how to wrap
the API - also here from an high-level perspective to remain as general
as possible.

Later,
Max

---

From: max pritikin <[email-masked]>
Date: Wed, 22 Sep 2010 08:42:06 -0500

I too like the idea.

And not only because Massimiliano and I both use the name 'max'.

- max

On Sep 22, 2010, at 7:41 AM, Miller, Timothy J. wrote:

> I'm only being partially snarky; there's quite a number of PKI  
> abstractions out there, mostly embedded in larger crypto or security  
> APIs, so there certainly plenty of ideas (some good, some bad) to  
> draw from.
>

---

From: Scott Rea <[email-masked]>
Date: Wed, 22 Sep 2010 10:27:14 -0400

+1

Oh, and with you two working on this, perhaps we can get MAXimum results 
using our MACs to do the work.... yeah its cheesy but I couldn't resist

-Scott

-- 
Scott Rea
Sr PKI Architect (Contractor)
Em: [email-masked]
Ph#(603) 252-7339

---

From: Alicia da Conceicao <[email-masked]>
Date: Thu, 23 Sep 2010 00:26:17 +0900 (JST)

This idea may be okay for desktop and server platforms, but...

as someone who wrote their own crypto library from scratch for embedded
systems and bootloaders, I think this is a very bad idea.

In order to avoid memory allocations & deallocations on embedded
platforms with minimal resources, especially those on MMU-less systems,
I had to optimize the use of temporary CONTEXT structures that are past
on between different API calls.

	ie: bignum_ctx, rsa_ctx, ssl_ctx, cms_ctx, ...

Thes temporary context structures are *TOO* specific to the source code
used in the implimentations.

For example, in my big number library, how I choose to impliment modulus
using bitshift subtraction or division remainder (both work) will dictate
part of my temporary context structures.  (BTW, typically the first is faster
but bigger and the second is slower but smaller, so I use a compile flag to
dictate which is used based on platform limitations.)

Other non-temporary crypto data structures also have fields/members tied
to their implimentations and the optimizations used.

The "high-level" PKIX API would not bother or care about these data and
context structures in the function API.  Likely at best the PKIX API would
use void pointers to point to these structures in the abstract, and then
expect the interop functions to use wrappers for the internal crypto
functions that allocate/deallocate at run-time as needed instead of compile-
time.

In practice having a "high-level" PKIX API would mean that you will likely
force crypto libraries on resource limited embedded and bootloader platforms
*NOT* to be compatible, and lead to tensions, since these platforms are
typically the ones with the highest security requirements.

Alicia.

---

From: Massimiliano Pala <[email-masked]>
Date: Wed, 22 Sep 2010 23:21:55 +0200

Hi Alicia,

thanks for the feedback. As you said, the high-level nature of the API
will try to provide an API that is as neutral as possible from the
implementation thus letting the specific crypto-library provider to
choose the best approach to the hardware.

This said, I am not sure I understand your point. The purpose of the
proposal is to provide an API that would allow to port applications
easily across different platforms/systems.

I initially thought this work to be targeted for platforms where we
don't have many constraints. Your point is interesting in that it
brings up a whole new class of applications/environments which I
had not considered initially.

I think there are two paths we can follow. The first one is to
try to target the API for commodity OSes and Apps and excluding the
scenarios you mentioned. The rationale for this choice would be tied
to the fact that those environments are strictly dependent on the
HW and are, usually, "closed" ones.

The second approach would be to provide a small subset of the API
that can potentially be implemented in such environments and having
the extended API still targeting more "open" (not as in open
source, just not embedded) systems.

I have to say that I am in favor of the first approach. In fact
the purpose of the API is to provide a common ground (I would say
that it could potentially become a further extension of the POSIX
specifications) available for applications to leverage. Moreover,
considering the fact that the specifications and capabilities of
the "typical" embedded system improve very fast, we might end up
with specifications that need to be updated often, in other words,
we might miss the target IMHO.

If we decide to go for the second approach, I would say that I would
need the help of someone (like you?) with more experience in embedded
systems design than I have so that the specifications might make
sense :D

Of course, there's always the possibility to work on two separate
documents...

Later,
Max

On 09/22/2010 05:26 PM, Alicia da Conceicao wrote:
> In order to avoid memory allocations&  deallocations on embedded

-- 

Best Regards,

	Massimiliano Pala

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 23 Sep 2010 11:03:11 +0200

Hi Max,

I'm still a bit of a loss when trying to understand what
you want to accomplish that NSS, KeyCzar, Gnome Keyring,CryptLib,
PKCS #11, CAPI, JCE etc (more or less) already do.

There seems to be some vital information missing.

Anders

Massimiliano Pala wrote:
> ------------------------------------------------------------------------
>

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 23 Sep 2010 07:51:52 -0400

What specs are you thinking about targeting?  The PKIX toolbox is pretty
big.  There may be value in an API document as an example of how to use
the specs together.

> Sent: Wednesday, September 22, 2010 5:22 PM
> To: [email-masked]
> brings up a whole new class of applications/environments which I had
> not considered initially.
> 
> I think there are two paths we can follow. The first one is to try to
> target the API for commodity OSes and Apps and excluding the scenarios
> you mentioned. The rationale for this choice would be tied to the fact
> that those environments are strictly dependent on the HW and are,
> usually, "closed" ones.
> 
> The second approach would be to provide a small subset of the API that
> can potentially be implemented in such environments and having the
> extended API still targeting more "open" (not as in open source, just
> not embedded) systems.
> 
> I have to say that I am in favor of the first approach. In fact the
> purpose of the API is to provide a common ground (I would say that it
> could potentially become a further extension of the POSIX
> considering the fact that the specifications and capabilities of the
> "typical" embedded system improve very fast, we might end up with
> specifications that need to be updated often, in other words, we might
> miss the target IMHO.
> 
> systems design than I have so that the specifications might make sense
> :D
> 
> > as someone who wrote their own crypto library from scratch for
> > embedded systems and bootloaders, I think this is a very bad idea.
> >
> > platforms with minimal resources, especially those on MMU-less
> > systems, I had to optimize the use of temporary CONTEXT structures
> > that are past on between different API calls.
> >
> > Thes temporary context structures are *TOO* specific to the source
> > code used in the implimentations.
> >
> > For example, in my big number library, how I choose to impliment
> > modulus using bitshift subtraction or division remainder (both work)
> > will dictate part of my temporary context structures.  (BTW,
> typically
> > the first is faster but bigger and the second is slower but smaller,
> > so I use a compile flag to dictate which is used based on platform
> > limitations.)
> >
> > Other non-temporary crypto data structures also have fields/members
> > tied to their implimentations and the optimizations used.
> >
> > The "high-level" PKIX API would not bother or care about these data
> > and context structures in the function API.  Likely at best the PKIX
> > API would use void pointers to point to these structures in the
> > abstract, and then expect the interop functions to use wrappers for
> > the internal crypto functions that allocate/deallocate at run-time
as
> > needed instead of compile- time.
> >
> > In practice having a "high-level" PKIX API would mean that you will
> > likely force crypto libraries on resource limited embedded and
> > bootloader platforms
> > *NOT* to be compatible, and lead to tensions, since these platforms
> > are typically the ones with the highest security requirements.
> >
> > Alicia.
> >
> >> I have been juggling with the idea of writing an high-level PKIX
API
> RFC.
> >> The purpose for this work is to enable a common interface reference
> >> that can be implemented across different systems and by using
> >> different crypto providers.
> >> would like to point out that the LDAP API specification is the best
> >> thing that happened. In fact, developing LDAP enabled applications
> >> does not require much efforts when porting.
> >> If you ever developed a real-world PKIX application you know that
> >> this API would improve the usability of PKIX certificates and
> >> simplify the developers' lives - thus resulting in lower costs in
> >> developing apps that support PKIX for companies.
> >> Does anybody is interested in participating to this initial
proposal
> ?
--o--------------------------------------------------------------------
> ----
> Dartmouth Computer Science Dept               Home Phone: +1 (603)
369-
> 9332
> PKI/Trust Laboratory                          Work Phone: +1 (603)
646-
> 8734
--o--------------------------------------------------------------------
> ----
> People who think they know everything are a great annoyance to those
of
> us who do.
> 							   -- Isaac
Asimov

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 23 Sep 2010 17:02:42 +0300

Hi Carl,

I think that part of the initial work is to define the scope of the document.
As you say, the PKIX toolbox is *VERY* *VERY* *VERY* big... I would start with
defining what are the basic operations related to data handling (creation
or generation, manipulation - e.g., fields parsing and extracting, format
conversion and basic I/O operations).

On top of this, there's the signature generation and verification (which
might imply context management, path building and validation), and revocation
information handling (e.g., CRLs or OCSP or.. ).

What do you think ? Too broad ? Too narrow ? On target ?

I am very skeptical about adding a certificate storage/querying API.. but
it could be an option if it does not overlap with other working items.

Later,
Max

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 23 Sep 2010 17:17:24 +0300

Hi Anders,

basically the idea is to provide a standardized high-level API (which
can be implemented by using any of the mentioned low-level crypto API).
Each of the different tools you mentioned have their own specific way
to implement PKIX operations. This makes it difficult to port applications
by using different crypto providers (here you are mixing standards like
PKCS#11 with crypto providers like NSS - I would say that this proposal
is for crypto layers what PKCS#11 (or CAPI) is for crypto hardware).

I think the target is to identify a "small" or "basic" set of calls that
would allow developers to deal with the details of PKIX from a high-level
point of view. Each crypto provider can implement the specs as they
like under the hood...

Is the purpose and scope of the proposal a little more clear now ?

Later,
Max

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 24 Sep 2010 12:20:27 +0200

Hi Max,

Now I understand what you are trying to accomplish.  Please don't take it
personally, but I don't really agree with your market analysis.  If you
(for example) are developing .NET applications most developers would just
get more troubles by yet another API.  The same goes for Java.  Platform
quirks will also show up through the wrapper layers making support awkward.

Microsoft's and Oracle/SUN's interest in such an API would likely be < 0.

So what you seem to be targeting is a very small elite (0.1%?) of highly skilled
developers of cross-platform applications written in C or C++.  But in this space
there's already a crowd of established alternatives like PKCS #11, NSS, and OpenSSL.

Although it may be viewed as a "plug", I have FWIW indeed defined a "PKI API".
This sounds a bit odd given what I just wrote, right?  The differencing factor
is that this API/scheme has two dimensions:

- A "User API" which can be mirrored through any of the established PKI APIs

- A "Provisioning API" which has no counterpart in current PKI APIs or RFCs

The "Provisioning API" addresses things which is a reality in contexts like
in Card Management Systems.  I won't go into the details here because
concepts like E2ES (End-to-end Security) in certificate provisioning has never
been a PKIX topic.  It is however a core theme in Trusted Computing Group
in which I'm an invited expert member.  Unfortunately TCG isn't publishing
work-in-progress or mailing list archives.  My take on this subject OTOH
is fully open, including running code.  Due to the complexity I don't think
that an RFC would do much good; this beast must be established (really big deal)
and tested in the market before any kind of standardization can be performed.

SDOs (Standard Defining Organizations) also tend to only focus on a tiny
piece of an ecosystem while my proposal goes from all the way from low-level
electronics to 10-pass XML protocols and associated browser GUIs.  This is
the "dark side" of consumer-oriented E2ES-based credential provisioning for
the Internet, but it is actually quite fun starting with a blank sheet of paper,
[almost] completely relieving yourself from dragging around legacy stuff that
were designed in an entirely different time and for quite different purposes :-) :-)

There are 4 BILLION+ mobile phone users out there waiting for a universal solution
(well, their providers do at least...), which is quite a challenge.

Anders

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 24 Sep 2010 17:52:57 +0300

Anders,

thanks for the feedback, although I don't share your view. The idea is
to provide *non-skilled developers* with an API which would enables them
to use PKIX in an easy (or easier than today) fashion.

I find interesting the fact that you mention .NET and JAVA that do *exactly*
what we want to do here - cross-platform re-usability of code (in this case
also binary, but let's not go there).

About Sun, they have been working on something similar (providing an high
level library to allow applications to use certificates easily) via their
KMF.

I also don't understand your skeptic behavior since you have wrote an API
which, I guess, have similar purpose (eg., the User API). Thus, I guess,
you recognize there's a problem there.

A final note is about the possible impact of this API. I said we can target
C/C++ languages because many OSes are actually written in C/C++ (not only
0.1%) and I would really be interested in seeing the API implemented at
OS level (although user-level is ok too). Anyhow, the basic idea is to
provide an API which is, as much as possible, language independent.

I hope this further clarifies the idea.

Thanks again for your comments that have been noted.

Best,
Max

-- 

Best Regards,

	Massimiliano Pala

---

From: Patrick Patterson <[email-masked]>
Date: Fri, 24 Sep 2010 12:18:23 -0400

Hi Max:

> to use PKIX in an easy (or easier than today) fashion.

I sort of have a problem with this - a week or two on the OpenSSL mailing list will demonstrate that "unskilled developers" don't need help with an API.  What they need help with are the basic concepts and practices around doing PKI [1]. Until we figure out a way to make THAT happen, developing a simplified, portable API isn't going to help - that will just let people develop PORTABLE applications that don't do PKI in even close to a sane or standards compliant way. 

[1] Probably one of the most common requests that I've seen lately is some variant on "how do I edit information inside of a {Certificate|PKCS10} without needing to have it re-generated/re-signed?".

Have fun.

---
Patrick Patterson

---
Patrick Patterson
President and Chief PKI Architect
Carillon Information Security Inc.
http://www.carillon.ca

tel: +1 514 485 0789
mobile: +1 514 994 8699
fax: +1 450 424 9559

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 24 Sep 2010 19:55:41 +0200

Hi Max,

This seems to be what you are looking for:

http://www.keyczar.org

The explicit PKI support is currently missing but could surely be added.
Personally I don't think neither C/C++ nor PKI is something non-skilled
developers should try which another poster also noted.

> I find interesting the fact that you mention .NET and JAVA that do 
> *exactly* what we want to do here - cross-platform re-usability of code
 > (in this case also binary, but let's not go there).

For the bulk of the market (I'm sorry using a word that isn't "kosher"
in the IETF), "cross-platform" usually means browser + web server.

The only PKI application I'm aware of that actually *is* [sort of] developed
by "Creti and Pleti" is TLS for securing server-to-server communication.
To simplify that there are platform libraries like Apache's HTTPClient:

http://hc.apache.org/httpclient-3.x

> level library to allow applications to use certificates easily) via their

BouncyCastle also provides a huge Java library of cryptographic functions and PKI
support that is used by thousands of other projects including Google's Android.
It is now available in .NET as well:

http://www.bouncycastle.org

Repeating this effort is close to undoable without bringing in lots of $$$.

> which, I guess, have similar purpose (eg., the User API).

 > Thus, I guess,> you recognize there's a problem there.

Well, the User API is intended for *mapping to existing* APIs* since
I have limited faith in the world switching from PKCS #11, CAPI, JCE, NSS etc.
The core User API is deliberately extremely simple making mapping close
to zero.

However, the User API also supports things that is not addressed by
PKI APIs such as Information Cards that is only available through
native calls.

> provide an API which is, as much as possible, language independent.

The 0.1% referred to the market in terms of *developers* who write cross-platform
PKI-using applications in C/C++.

> I hope this further clarifies the idea.

You don't describe how this API is supposed to be distributed and supported.
That's a really big deal, particularly with native code and mobile phones.

Naturally you are free creating "Yet Another Cryptic API", I just wanted
you to think twice about the chances of succeeding, not at all about
p*****g you off :-)

> Thanks again for your comments that have been noted.

U2!
Anders Rundgren

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 24 Sep 2010 23:59:08 +0300

Hi Patrick,

I agree with your point. I also think that many problem arise by the excess of
flexibility we have in crypto API. Many times, the functionality we need are
few, and we end up using the same list of calls to do the same tasks. Having
an high-level API would help the developer to do the right thing (e.g., right
initialization for key generation or path-building/path-validation).

This will not solve the problem related to the lack of any knowledge about
the technology, but would help the developers to deal with the details which,
in PKIs, are really important to get things right.

It is just one step.. but I think that we have to start somewhere.. :D

Cheers,
Max

On 09/24/2010 07:18 PM, Patrick Patterson wrote:
[...]
> I sort of have a problem with this - a week or two on the OpenSSL mailing list will
> demonstrate that "unskilled developers" don't need help with an API.  What they need
> help with are the basic concepts and practices around doing PKI [1]. Until we figure
> out a way to make THAT happen, developing a simplified, portable API isn't going to
> help - that will just let people develop PORTABLE applications that don't do PKI in
> even close to a sane or standards compliant way.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 24 Sep 2010 13:01:23 -0800

> It is just one step.. but I think that we have to start somewhere.. :D

I think so, too, and would like to voice support for this
work (and indicate an interest in working on it).  I think
X.509/pkix is basically impossible to deploy correctly but that
problem is (nearly) orthogonal to the one of a standard 
programmatic interface.

Melinda