Tumbled Logic

Provisioning keys and provenance

This one’s been bugging me for a while.

One of the issues which has caused issues for the adoption of standardised PKI in serious applications (such as banking) has been that of provisioning: you don’t want your customers storing the keys to your particular castle in a software keystore because the risk of compromise is too great.

The traditional approaches to this have either been to provision the keys on behalf of the customer and then send them out, or to use non-standard PKI setups which talk specifically to certain types of hardware token.

I’m wondering if there’s merit to another approach, permitting remote provisioning in an open fashion.

The issue with remote provisioning is knowing where the key is being stored, so why not just have the hardware token capable of signing a blob with its own key? That is:

• Provisioning causes a new key to be generated and stored by the token
• The token then signs the newly-generated public key with its own key, which is itself part of a normal certificate chain rooted at a CA managed by the token manufacturer.
• Thus, you have a “certificate of provenance” attesting to the fact that the new key was provisioned on the token and the private portion cannot be extracted, with a chain leading back to the manufacturer (possibly through an intermediate “device class” CA to allow differentiation between different types of token from the same manufacturer).

Given this, and the modest protocol changes required to support it, you would be able to provision keys remotely, having a whitelist of acceptable token models which you have tested. Indeed, this list could conceivably be maintained by some industry sector body to ensure some consistency.

As an — entirely hypothetical example — example, you could end up with a chain which looked like:

[new key] → [per-card certificate] → Gemalto .NET Card → Gemalto Smartcards → Gemalto NV

As an institution, you have a list which either includes one of the entries in the chain (Gemalto .NET Card, all Gemalto Smartcards, or everything from Gemalto NV), or it doesn’t. Straightforward.

Now, what are the great big gotchas that I’ve missed here (besides the difficulty in bringing about change to TLS, and bits of the PKCS family…)?

Capped

A small note regarding the “£26k benefits cap”:—

Lots of people seem to be talking as though the benefits being paid are exclusively (or, at the very least, predominantly) to those seeking work. In other words, if they found work then these benefits would go away. This is the justification for capping to an “average” salary — pay too much in benefits to the unemployed, then you’re providing a disincentive to finding work.

First of all, it’s worth noting the fact that the number unemployed massively outstrips the number of vacancies. Even if everybody were trying their absolute damnedest to get “back into work”, the majority of those unemployed wouldn’t be able to.

Second, for those over 25, the amount paid as Jobseeker’s Allowance is £67.50 per week, and if you’re a couple over 18 both claiming, you’ll get £105.95 a week.

These two pieces of information alone are enough to tell you that the premise of the cap is flawed. The most you can claim as an able-bodied individual in unemployment benefits is £3,510 a year, or £5,509.40 as a couple.

This, by my reckoning, still leaves in excess of £21,000 which is being paid to some of these layabouts.

Let’s deal with the easy stuff: premiums. These boost Jobseeker’s Allowance payments if you suffer from a disability (premiums range from £14.05 to £55.30 for an individual, or £20.25 to £110.60 for a couple, depending upon the severity of the condition) or if you’re a carer. Even with this, we’re still some way off our target.

Other benefits — and this includes council tax relief — aren’t paid on the basis of being out of work, but on the basis of suffering from a debilitating medical condition, or having some specific status (i.e., being a carer, being a student), having children who suffer from a debilitating medical condition, or having a low income. There are caveats, deductions and caps in various places depending upon how much you (and your partner) earns, and whether you have any savings. Finally, Child Benefit is a (relatively modest) fixed amount.

The thrust here is that with the bulk of these “benefits” (which really shouldn’t be called that, as most of them are compensatory in nature) aren’t dependent upon unemployment at all, but on either disability or low income.

This shifts the goalposts somewhat. It’s not about “getting back into work” at all; instead it’s “don’t be disabled”, “don’t have disabled kids” — or kids at all! — or “get a better job”.

Is that really what you want? Really?

What is WebID?

WebID is a W3C Incubator Group (soon to be, and possibly by the time you read this already, a W3C Community Group) specifying a mechanism for using X.509 End Entity (or “client”) certificates to identify yourself to online services, and for performing attribute exchange through Linked Data.

WebID works like this:

• You generate, or obtain, an X.509 certificate for yourself. It doesn’t really matter to WebID-consuming services whether this is self-signed, self-issued, or issued to you by a third party.

• Your certificate includes a subjectAltName extension containing a URI which can be dereferenced (i.e., you plug it into some software and get some data back) in order to obtain some machine-readable data about you — that is, a profile document.

• That structured data includes a copy of the public key from your certificate.

Assuming the data could be retrieved and the keys match, this tells the consuming service three things:

• You have access to the corresponding private key (the TLS protocol exchange would have failed if not).

• Because the public keys in the certificate and profile document matched, any assertions made within the profile can be treated as being equivalent to if you made them as part of the certificate itself (and nobody else can make those assertions to you, because their public key wouldn’t appear in the profile).

• Because the keys match, you have confirmed that you are able to publish information at the URI in your subjectAltName (you can’t pick somebody else’s URI, because you don’t have the private key corresponding to the public key in their profile).

Almost all identity systems designed to operate across multiple sites involve some kind of attribute exchange — that is, passing information between the identity provider and consumer. In WebID, the part of the “provider” is played by the profile document that you publish yourself. If you want to add new “attributes” for exchange (i.e., publish additional information about yourself), you just make sure that it appears in the profile.

The profile itself can take any of a number of forms. At the time of writing, you can publish it as RDF/XML or XHTML+RDFa, but there are moves to expand this list to include Turtle and HTML5 Microdata.

You might wonder, reading this, how you can trust the information in the profile if the individual has published it themselves — but in actual fact this isn’t really any different to what happens elsewhere: you don’t trust that a person’s date of birth really is their date of birth because it says as much in their Facebook profile; the only thing which Facebook Connect can definitively tell you is data exclusively managed by the service itself: principally, that the person is logged in with a particular Facebook account, but also their “friendships” with other people (and the same applies to OAuth with Twitter, and other services similarly).

WebID doesn’t solve the world’s identity problems (there remains unspecified plenty of stuff around long-term key management, selective access-control to the profile, and trusted attribute exchange — that is, relaying claims made by other people about you), but nonetheless I think WebID is going to form an important piece in the puzzle.

Now, for some Q&A:

Do I need to use a “hash URI” or 303 for WebID subjects?

If you’re using http: or https: URIs, then in principle, yes (but see the next question, too). The URI carried by the subjectAltName extension is meant to be the URI for you, not the profile document. The theoretical constraint is therefore that the URI you pick for yourself and the URL for your profile document should be different, but by dereferencing the former you end up with the profile document (i.e., the latter) but that it describes you using the URI you started with. Using fragment identifiers is a way to do this which requires the least moving parts, because it means using something which is automatically stripped out (according to HTTP) when you dereference a URI — but it is by no means the only way.

However, it should be noted that a WebID verifier can be completely conforming and not care, and nor should it: as a piece of software which simply needs to deference a URI and check that in the document it gets back there is the public key correctly associated with URI it started with.

However, in the world of RDF, a given URI isn’t supposed to refer to two different kinds of resource (i.e., an information resource — or document — and non-information resource — something which isn’t the document) simultaneously, and so although it’s a valid as far as WebID is concerned to use the same URI to refer to both you and your profile document at once, you may find that the applications which employ WebID aren’t so forgiving, depending upon what it is that you’re doing.

In any case, what’s to say that you haven’t devised a (semi-)autonomous kind of document which can both present its own public key in a certificate and describe itself?

Can I use an acct: URI as my WebID URI, for example?

It’s not yet been specified, but there’s no reason why you couldn’t in principle: an acct: URI which can be resolved to the URL of a profile document containing a description of the acct: URI that you started with certainly satisfies the constraint of “the URI you pick for yourself and the URL for your profile document should be different, but by dereferencing the former you end up with the profile document but that it describes you using the URI you started with”. At the moment nobody has written the specification detailing how WebID consumers should process acct: URIs in order to obtain a profile document.

Why is the public key material copied into the profile document? Why not anything else?

Copying the public key material into the profile is a close parallel to the “verify your e-mail address” e-mail messages which services send you when you sign up to them: it confirms that you really do have the ability to publish information at the WebID URI.

The public key is used for this because of the nature of asymmetric cryptography: if only you have the corresponding private key, then there’s no benefit or incentive for anybody else to publish your public key in their profile, and similarly because you don’t have the private key belonging to anybody else, there’s no benefit or incentive for you to put their WebID URI in your certificate.

In fact, the public key is the only piece of information which needs to match: WebID doesn’t really care about all of the other stuff in your certificate: consumers know that if there’s any information that you really want to publish, you’ll put it in your profile.

Why use subjectAltName and not the Subject Distinguished Name?

The subject DN is intended to be a composite key allowing location of information in the X.500 DIT, and designed to be plugged straight into DAP queries. Even the emailAddress attribute is a bit of an aberration in this respect.

More importantly, a subjectAltName extension is (on balance), more likely to be user-specifiable than the content of the subject DN, and the retrieval semantics of URI alternative names are relatively well-defined (although WebID does extend them by adding processing rules). Finally, it’s not at all uncommon for certificate issuers to put all manner of cruft in the subject DN.

A polite request

Dear The Newspaper Industry,

I pay for your content—in electronic form, no less. I’ve tried a few different ways of doing this, but my present favourite is a Kindle subscription. I receive The News when I wake up in the morning and read it on my commute. Splendid.

What I’m unable to fathom is why the content which is delivered to my device and I have paid actual money for is a subset of the content available for free on your website.

Might I respectfully suggest that your value proposition might be described as “arse about tit”, as they say?

Love and hugs,

Mo

xx

Mac OS X: Adding a new Windows printer

Say you have a printer shared via Windows — and you want to add it as a new printing device in Mac OS X. You head to System Preferences, then either Print & Scan or Print & Fax depending upon your version, press the + button… and fail to find it in any of the sections. The Windows section doesn’t seem to provide anything useful.

There are two ways to do achieve what you want.

One is to use the CUPS interface, which you’ll find here, if you’re browsing on your Mac. From there you can pick the Administration tab, then Add Printer, and jump through the hoops.

The other is to control-click on the toolbar of the Add Printer dialog and choose Customize Toolbar…, then drag the Advanced icon onto the toolbar.

Once you’ve got an Advanced option there, the process is nearly identical to adding through the CUPS web interface.

For smb:// printers, the Type you want is Windows printer via spools.

The iMessage/stolen phone thing

What Apple needs to do is (conceptually) really bloody simple: when a remote wipe occurs, or a device is activated without having iMessage/FaceTime credentials to hand (i.e., because it’s a factory reset rather than a restore-from-backup), remove the device’s UDID from iMessage’s and FaceTime’s respective databases.

And, er, that’s about it.

A short Linked Data URI design Q&A

URI design for Linked Data is pretty straightforward, but there are a few common practices out there in the real world which I find jarring as somebody who is mainly a data consumer. This is my attempt to briefly talk about why you shouldn’t do those things. I’ll probably update this post over time.

Why should I avoid routinely redirecting [usually a 303] from a published thing URI to a specific representation of a document describing it? (e.g., a web page, or some RDF/XML, etc.)

Redirecting, rather than just sending back the document and a Content-Location header will work, but it does make life slightly trickier for developers debugging their consuming applications, and also makes it harder for people to share links to your data: the URIs that people see are always the specific document URIs, not your content-negotiating endpoint.

Why do I want to differentiate between my thing URIs and my document URIs?

Because many vocabularies include properties which could be used to describe either (for example, much of the Dublin Core Metadata Terms) — and very often it’s useful to provide information about both the document and the thing primarily described by that document.

Why should I avoid publishing my data on a separate subdomain to my normal web pages?

This is much the same as why you shouldn’t routinely redirect to representations: you’re making discoverability and link-sharing harder.

Why should I avoid deriving my identifiers from names and titles?

URIs shouldn’t change, but names of things do: even if just to correct a mistake. When this happens, it means you either have to break links by changing the identifier, or accept that it won’t match the actual title (in which case, why make it match in the first place?). Sometimes, even correctly-named derived identifiers can have unintended results. For example, a recipe on the BBC Food site named “Carrots glazed with cumin and orange” had a derived identifier which truncated the title portion in a rather unfortunate place. UUIDs can be good, because they don’t require a centralised identifier-issuing service (or person!).

Why should I avoid including things like “.rdf” or “.action” in my data URIs?

URIs shouldn’t change. The web server technology, data formats, and virtually everything else in the technical stack used to publish your data should be outlived by the identifier: don’t tie the two together.

Why should I opt for minting http: and https: URIs?

Every linked data consumer understands HTTP (and HTTPS). Other schemes require either additional protocol support, or require specialist knowledge about how to resolve URIs to resources. By all means, reference other URIs, including those using schemes other than http: and https:, but do this as well.

What should I do about things appearing in multiple collections?

Make the items accessible within each collection (using the same local identifier in each case), but choose one location which will be the canonical home for the item and redirect to it (see the 3xx items here for a short guide to which you should use).

Kultivate

I’m presenting today at the Kultivate Linked Data workshop in London.

Should anybody be interested, my slides, notes and example data can all be found here.

Cameron versus the EU

I don’t find David Cameron particularly trustworthy at the best of times, and he’s shown little credible evidence that he really understands what “Britain’s interests” actually are as far as most people are concerned.

So without being in a position to determine the detail of what’s been rejected, and given that this now appears to be David Cameron’s cabinet in firm disagreement with all of the rest of the EU, my gut feeling is that it’s quite likely that he’s both dead wrong, and that he’s just screwed Britain over royally.

Obviously, if when I’m in full possession of the facts this proves to be twaddle, I’ll eat my words.

Translation from PR puff piece into English

UltraViolet service offering digital locker of films and TV planned for UK:

A consortium including Warner Bros, Sony Pictures and Fox are backing the UK launch of a new service that aims to revolutionise home entertainment, and cut piracy, by offering consumers a digital locker of films and TV shows they can watch on any device.

“We’ve finally managed to cut through the tangled rights agreements which we invented. As you’ll probably have noticed, even DVD rental services suffer from having the rug pulled from under them by studios — and let’s not get started on the ever-fluctuating catalogues of LOVEFiLM and the iTunes Store… what can we say? We saw what the music industry was doing and thought ‘hey, that’s a great idea’.”

The UK is the second market to launch the UltraViolet service, a digital library for films and TV shows, which gives consumers the rights to “buy once, play anywhere” on as many as 12 devices.

“This is nothing like PlaysForSure™.”

UltraViolet’s backers – 75 companies as varied as Tesco, Samsung, Nokia, Sky and LoveFilm – claim their open system has the edge over more restricted services offered by Apple and Disney.

“No, really, it’s nothing like PlaysForSure™.”

Completely coincidentally: conspicuously missing from the list of “backers” are… Apple and Disney.

No word on how it compares to other “restricted” services such as ordering a DVD from Amazon (also missing from the list, I believe) and ripping it.

When a consumer buys a DVD or Blu-ray disc of the title they will get a code they can use to download or stream a digital version of the film or TV show and build up a virtual locker.

“Not only is it nothing like PlaysForSure™, but it’s also nothing like Disney DVD Digital Copies, either.”

The content can be viewed on practically any device from any manufacturer and up to five family members can be added to an account.

“practically any device from any manufacturer [citation needed]”

“If consumers buy a movie or TV show they should be able to use it in any way they want,” said Mark Teitell, general manager of DECE, the body representing the consortium backing UltraViolet.

“Any approved way that they want, on any approved device.”

“This allows consumers to buy enduring rights to a piece of content, like an internet-based version of a proof of purchase, that they can then watch pretty much anywhere they want.”

“pretty much”

Warner Bros is the first content owner to unveil its plans for UltaViolet (UV), with the launch of Final Destination 5 on 26 December being the first UV-enabled title to be made available to consumers in the UK.

Be still my beating heart.

Chris Law, managing director of Warner Bros Television and Digital Distribution UK, said the concept could be summed up as a “buy once, play anywhere” service.

“We are offering consumers a simple and more compelling way to purchase, manage, access and share their movie collections digitally,” Law added.

More compelling than…?

Ultaviolet is intended to be a complimentary digital service to existing video-on-demand offerings. Last week Tesco announced it is to start offering digital copies of movies for free when customers buy a DVD through its Blinkbox service. However, the company, a partner in DECE, said it is completely “complimentary” with UV which it intends to launch next year.

“Tesco’s service, available right now, does pretty much exactly the same thing.”

“We are introducing people to the concept to get them used to it before UltraViolet arrives,” said Michael Comish, chief executive of Blinkbox.

“The legal team drawing up the agreements to permit customers of Blinkbox to migrate their purchases into an UltraViolet-friendly “digital locker” are crying themselves to sleep on their pillows and blankets woven out of bank notes.”

Robert Price, UK managing director for 20th Century Fox Home Entertainment, said he believed the service would develop to enable consumers to “browse digital versions of movies from multiple studios just as easily as we currently browse our Blu-ray and DVD libraries on our shelves at home”.

“Wouldn’t it be great if people if people could browse for things they wanted to buy, then buy them, then have them, and not have to worry about things like DRM servers being switched off or well-known brands going out of business? Yeah, we’re not doing that.”