Proposal for a Desktop Neutral Crypto API

[Brad Hards]

On Sun, 3 Apr 2005 02:28 am, Nate Nielsen wrote:
> True, but it allows any toolkit that supports this standard to
> participate. Writing it as a shared library ties us to one
> implementation in one toolkit.
Not so - you can implement the shared library as a Bridge, allowing plug-able 
backends.

> Right, I should have outlined that more clearly. This is about public
> key encryption and making those comlpexities simpler for a user.
>
> We already have the other bases covered. If a browser needs to encrypt
> it's 'wallet' then we have that working pretty well.
We have GPG integration covered pretty well too - works for me anyway.

> > I can't really comment until we see how many apps implement it. Also,
> > because the focus is so narrow, I'm not sure that can work anyway.
>
> For starters seahorse will probably implement something like this.
> Seahorse has had a goal of being very deeply integrated into the desktop
> and simple to use. The latest code in CVS is starting to meet that
> criteria.
I meant the client side. A DBUS service doesn't do much for the user without a 
client calling it! How many apps have expressed some interest in converting 
to DBUS based public-key crypto?


> I had no idea that the general state of arbitrary and application
> specific encryption on the desktop was in such desperate need of
> replacement. Consistent use of incredibly fully featured libraries such
> as openssl could solve this problem, IMO.
I think there was perhaps a smilie missing here - I take it that you are being 
facetious. I was trying to point out that the restriction to SMIME and PGP 
might end up being a problem for apps that need just a little more crypto. As 
noted above, the crypto support we have is probably about equal across public 
key and symmetric algorithms - why deal with public key in a unique (and 
unproven) way?

> > If it is going to be interoperable, you need to say what formats must be
> > handled. Do we have to do PEM? Do we have to do binary DER?
>
> Any and all formats pertaining to a given public key encryption standard
> should be handled by the underlying implementation. In the case of
> S/MIME PEM, DER and PKS12 and probably others would be handled.
You are missing the point. If my implementation can only do PEM and raw DER, 
and not some wierd PKCS thing, but your implementation can only do PKCS#12 
and PEM, and not that non-standard DER rubbish, then the user experience is 
going to be unhappiness - that cert works great for some users, and not for 
others, and the user stuffs around trying to find a combination that they can 
export and their friend can import. Interoperable will require  that we work 
on a common set (at least a standard default).

> It's the user who is going to receive these keys via email or some other
> high level communication, and the client of the API calls into it, on
> the users request, to import the key into their local keyring /
> certificate store.
Exactly - see above.

> > OK, so if I want to do HMAC for an integrity check, I'm back to an
> > application specific mechanism to put the keys in? That isn't really
> > solving the stated goal of continuity in the user experience IMHO.
>
> But in this case the key would be application and protocol specific.
> There would be no need to share the keys between applications. Please
> see above.
OK, but this reasoning is a case against the sort of crypto server you are 
proposing for asymmetric crypto - if the keys are specific to GPG, why not 
just let the GPG infrastructure handle it?

Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050403/3e9f309b/attachment.pgp