[foaf-protocols] FOAF+SSL and root certificates

[Peter Williams]

The declared semantics and intent of FOAF+SSL are identical to a well known
security pattern (delivered years ago in the SSL world). 

A. A self-signed cert with naming URI in the subject can be found as far
back as the root cert list in Windows, from circa 2001. 

B. A third-party issued cert with a non-naming URI in the subject field (it
locates the CA's legal repository rather than naming a subject) can be found
as far back as 1996.


1. User mints self-signed cert with URL name form for subject, using any
tool - or by hand. 

2. User publishes cert on the web at the URL (using the IETF mime type for
cert resources).

3. Relying party class user confirms that the SSL client cert asserted by a
user can also be retrieved from the URL, in realtime. This demonstrate a
user has an appropriate amount of control over both a name (URI) tied to a
website, and the website (tied to a URI nameform).

---------

4. A CA may be authorized by the user to resign the cert and publish it to
the user (and to the world in the CA's legal repository). The cert will
typically bear legal notices representative of the legal controls in force
in the legal repository, including a URL to the status webservice that
Relying Parties are often obligated to consult in realtime, while preparing
to perform an act of reliance. A user generally consents to change legal
status, becoming a subscriber now controlled by governance policies of
(trusted) third parties (versus public law). Governance polices enacted by
corporations are generally subject to public law. In some cases (financial
and telco corporations), administrative law imposes obligations on
corporations to report on cert usage, report on who relies on which cert.
Such corporations are generally fined for non-compliance.

5. The subscriber may be authorized to republish the CA's property at the
URL in the subject name (or not). The user may be authorized to publish the
cert by a variety of other means, including S/MIME. The publication rights
grant is usually non-permanent. The CA can generally order the user to cease
further acts of publication.

6. Failure by the user or relying party to observe any governance rules can
and usually will result in the CA delivering legal notice via its repository
that the CA-signed cert is no longer authorized for use (or reliance).

7. In becoming a subscriber, the user typically cedes rights over the
original self-signed cert and any its public key value, and subjects their
private key to control by the TTP/CA that outlives the termination of any
user/subscriber/CA contracts.

Now -  FOAF+SSL does the same thing as 1-3 above (no one has ever claimed
its processes involve more than the above); though it swaps some
representations and signal formats. Rather than treating a cert (chain) at
that resource referenced by a URI as metadata to describe subjects, keys and
relationships between subjects, issuers and authorization groups (in X.509
AA certs), FOAF+SSL community uses the RDF and the FOAF vocabulary.
Basically, RDF plays the role played traditionally played by the X.500
constructed type language (based on ISO's ASN.1),  and FOAF and linked data
plays the role traditionally performed by X.500/ldap entries and inter-entry
relationships expressed in X.500/ldap schemas (ontologies).

In patent terms, FOAF-SSL is a (mere) embodiment of prior art. I'd be happy
for folks to claim otherwise, so I can go and find previous invention
disclosures. It's important to do this now, so folks making patent
applications can be held accountable for application fraud (should they fail
to disclose known art, including emails, to the examiner). Application fraud
is rarely designated an illegal act (but it helps convince the examiner that
the application has failed to meet the standards of the examination). The
more adversarial records in the patent portfolio, the lower the economical
value of an issued patent (yet tested for invalidity), and the less value it
has a patent has as a control instrument in the world of crypto-politics.

In the commodity art, cert resources (at ldaps or http URIs) are typically
(but not exclusively) represented in the PKCS7 compound document file
format. This allows the resource to be a cert chain, generally allowing for
a "CA" to be introduced into the model (as discussed in points 4 and later,
above). In adding CAs into the FOAF+SSL mix (whether it's a single CA
controlled by W3C/IAB or the world of SSL that facilitates multiple,
self-governing CA communities) the relying party not only confirms that the
user has the wherewithal to control a URL, but also one or more TTPs (aka
CAs) use signing to assert and project control.

When one adds trusted third parties to the control system (CAs are just a
type of TTP), depending on the copyright signals in the certs affixed by the
TTP, a relying party can determine who (legally) owns or licenses the
publication rights on the certs. Typically, the copyright license then
governs the relying party and/or the user of the cert. Lots of lawyers these
days are trained to advise on these topics (to legal standards, vs Peter's
bullshit).


-----Original Message-----
From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Story
Henry
Sent: Saturday, February 13, 2010 10:55 AM
To: Stephen Dawkins
Cc: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] FOAF+SSL and root certificates


On 12 Feb 2010, at 14:50, Stephen Dawkins wrote:

> Hi All
> 
> I've been following FOAF+SSL for a while now, and I have a question.
> 
> Was there any consensus on the creation of a root certificate/CA for
> FOAF+SSL certificates?

It was considered as a way of resolving the issue between two incompatible
SSL specs TLS1.0 and TLS1.1, the later one no longer requiring this.
 
http://lists.foaf-project.org/pipermail/foaf-protocols/2009-February/000264.
html

As we could not find any information about which browsers worked in what
way, we have not pursued this. It could well be that TLS1.0 was not
correctly describing browser behaviour.

> I ask because the current state of allowing any installed certificate to
> be sent could be confusing to users. As it is, my myopenid.com certificate
> shows up when using a FOAF+SSL site. This certificate clearly won't work,
> so it shouldn't be shown.

Do they send a Certificate Request List to your browser? If they did, then
the browser should be offering you to choose only between certificates they
accept.

> Creating a root certificate would make things much clearer, and allow
> browsers to provide a better interface when dealing with these
> certificates (ala Microsoft's CardSpace GUI), and also provide better
> security by offering to password protect the certificate when storing it.

Are you sure it would?

This is worth testing very carefully beforehand on all browsers, so that we
could get an idea of how much something like this could improve things. I
have noticed some browsers giving me options to send certificates that had
clearly expired. [I think this was Firefox - if so we should report this as
a bug]

But also I think foaf+ssl is generic enough and simple enough that anyone
should be able to apply it easily, even Verisign. As such any certificate
should in the end be sendable. And we don't want to limit the possibility of
Certificate Authorities not adding their URL to their issuer alternative
name too.

The solution one is looking for is one where the server could say something
like: send me any certificate that has a URL in the subject alternative
name.

> I would create a root certificate (valid for a very long time as it isn't
> really being used for security) and a website to sign any CSRs (I wouldn't
> go as far as to publish the private key, that just doesn't seem right to
> me).

That would be fine. But I don't think we should have that as part of the
standard then, because that would force everyone to pass through your
service to create certificates.

> 
> Does anyone have any thoughts on this?
> 
> Regards
> Stephen
> 
> (ps. please CC me in on responses, as I'm not subscribed)
> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

_______________________________________________
foaf-protocols mailing list
foaf-protocols at lists.foaf-project.org
http://lists.foaf-project.org/mailman/listinfo/foaf-protocols