[foaf-protocols] Fwd: gnome-keyring Storage of trust assertions
home_pw at msn.com
Wed Dec 8 03:55:23 CET 2010
I didn't do that very well. The file format is PKCS#12, of course,
previously known as .pfx.
From: peter williams [mailto:home_pw at msn.com]
Sent: Tuesday, December 07, 2010 6:27 PM
To: 'Melvin Carvalho'; 'foaf-protocols at lists.foaf-project.org'
Subject: RE: [foaf-protocols] Fwd: gnome-keyring Storage of trust assertions
Hmm. The reference on using PKCS#11 attributes to qualify a cert seems a
lacking substance. It seems to make only a very basic use of PKCS#11 as a
storage container, creating its own model.
Consider Windows, instead (at least to understand).
There is wintrust (developed by the original Windows NT team) into which one
plugs cert chain providers - one for IE, one for PE files, others for other
protocol families. Then there are several providers for SSL for the various
generations of windows crypto support, some of which consume wintrust.
Then, there are certs, in cert stores. There are various types of cert
stores, including the registry, protocol messages, and PKCS#11 stores (such
as smartcards). To each cert represented in the classical Win32 API , one
can (being windows) attach properties. The DER encoding should be thought
of, as in the SUN world, as a blueprint given to a factory object, which
(with the help of properties) can now create the machine that verily
constructs object according to that blueprint.
Depending on the cert chain provider in the wintrust model, the properties
on the cert "object" qualify the key usages and purposes (and application
purposes) in the signed (DER) cert that is one element of the object. The
cert and the object are not the same thing! Cert chain providers focus on
(a) discovery (a search process), and (b) validation (a closure process).
Now, in a windows PKCS#11 file, the persisted cert object AND its all its
elements (the DER, and the properties, and other gunk) can be stored as a
transferable object - and then duly transferred to other machines whereup
the properties/DER/... of the object are re-created. On that new machine,
different trust parameters apply to that OS instance, which influences what
relevancy those properties have in the win trust providers and the factory
objects. On one machine, you can use object properties to override the DER
key purpose attributes; on another machine you cannot.
I recommend folks study windows APIs on PKCS#11 and NSS more carefully,
noting how PKCS#11 is used. A good place to start is the openssl code on
PKCS#11 - since it's had a lot of work done reverse engineering what
Microsoft and Netscape/NSS agreed to do together. One might also look up the
history of Microsoft's storage formats, pre PKCS#11 adoption.
From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Melvin
Sent: Tuesday, December 07, 2010 5:48 PM
To: foaf-protocols at lists.foaf-project.org
Subject: [foaf-protocols] Fwd: gnome-keyring Storage of trust assertions
---------- Forwarded message ----------
From: Stef Walter <stefw at collabora.co.uk>
Date: 7 December 2010 21:46
Subject: gnome-keyring Storage of trust assertions
To: "gnome-keyring-list at gnome.org" <gnome-keyring-list at gnome.org>
I've been doing some work on the storage of trust assertions in
gnome-keyring. These are used to store things like certificate exceptions
(per host), trust anchors, and certificate revocation lists.
I've been implementing the trust assertions rough draft spec  with
compatibility for netscape trust objects  as well.
libgcr has new functions  for looking up whether a certificate exception
exists for a given certificate, and looking up trust anchors (among other
things). These functions use PKCS#11 internally to access the modules where
this data is stored.
The storage takes place in the pkcs11/xdg-store PKCS#11 module.
BTW, I was thinking about signing the files containing the trust assertions,
with a key for each user. But it turns out this has no value at all if
malicious code can just replace the signing key. :S
All the above code in in the trust-store branch of gnome-keyring.
 rough draft: http://people.collabora.co.uk/~stefw/trust-assertions.html
gnome-keyring-list mailing list
gnome-keyring-list at gnome.org
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
More information about the foaf-protocols