Signed badges observations and questions

[Sam Kirchmeier]

Hello everyone,

I've been looking at the existing spec for signed badges and have a few questions. For reference, I'm using the Signed Badges section of the New Assertion Specification on the wiki (https://github.com/mozilla/openbadges/wiki/New-Assertion-Specification).

My understanding is that signed badges were introduced for two primary reasons:

1) To allow independent verification of a badge without requiring the issuer to host an assertion.

2) To add legitimacy to a badge since the signer's credentials can be verified.

A few observations / questions:

- The current proposal for signing does not seem to solve item #1 above, because the issuer would have to host two things: their public key and their revocation list. A verifier would need to download both from a trusted source each time they wanted to verify a badge.

- Related to item #2 above, why would a verifier trust a signature more than an assertion? The issuer's public key still needs to be downloaded from a trusted source, so why not just download the assertion itself?

- Any concerns about scalability of the revocation list? The entire list must be downloaded by a verifier every time they want to verify a badge. What if an issuer has revoked a significant number of badges?

- The current proposal does not provide a path for issuers to follow when a key pair is compromised. Should badges be revoked and reissued? Should badges issued before a certain date still be considered valid?

It seems like the current proposal for signing adds significant complexity without many benefits over hosting assertions. If an issuer hosts an assertion, there's no key management, no revocation list, and no risk of compromised key pairs.

I realize signing is just an option, but as an alternative, why not just include the plain old assertion in the PNG metadata? Verification is simple: download the assertion from the issuer and make sure it matches the assertion in the PNG metadata.

Sam

[Dave Lester]

Hi Sam,

Thanks for contributing your ideas about signed badges. I've cc'd Brian Brennan who should be able to respond most-directly to your points.

And in case you haven't already haven't seen, here's an earlier thread where Brian introduced the new badge spec including some discussion of signed badges: https://groups.google.com/forum/#!searchin/openbadges-dev/signed$20badges/openbadges-dev/srpN4CQKDM0/Auq57PCcUqYJ

Best,
Dave

--
You received this message because you are subscribed to the Google Groups "Mozilla Open Badges Dev Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openbadges-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out .

[ke...@gocodery.com]

Hello,

Thought I'd ping this thread even though it's been awhile. I have some of the same questions as Sam as I delve further into signed assertions.

Thanks,

k

[Sunny Lee]

Also Sam if you're able to join an upcoming community call, we can add this to the agenda for you to ask some questions on signed assertions. Our developer teammates, Brian Brennan, Mike Larsson and Chris McAvoy typically join the conversation. 

Community calls take place on Wednesdays at 12 pm EDT. 

[Louis St-Amour]

I can't remember the format off the top of my head, so my apologies if I've misunderstood how things work. I'm going more generally off public-private key crypto as I understand it for signature validation.

Let's consider a common example. You've 5 badges displayed that you need to verify. In the old model you would make:

• 5 requests for PNG files
• 5 requests for assertions (hopefully over HTTPS)
• and ask for an email address to validate against the assertion (since it can be hashed)

For a total of 10 requests.

In the new signed model, you make:

• 5 requests for PNG files
• (optionally) 1 request for a public key (this can be cached since it won't change often for the issuer, likely trusted in advance)
• 1 request for a revocation list
• and again ask for an email address if it's hashed as an identity (this quickly becomes a roadblock, it'd be nice to present a username of any kind...)

For a total of 6-7 requests.

I'll admit, for a 1-badge scenario, there's few savings. It's basically the same once you cache the public key. For more than one badge, there's plenty of time savings, however. If you had to verify 100 badges, it'd be much easier to do so using the signed approach than the hosted model.

If you'd like to avoid the cost of making a revocation call, we could look at doing stapling -- somehow piggybacking or embedding a signed revocation list with a time it was created and an expiry date, e.g. http://en.wikipedia.org/wiki/OCSP_stapling and http://tools.ietf.org/html/rfc5019 but I think that would be overkill.

It would be nice to have a central trusted repo of issuer public keys that we could maintain for offline validity checking, similarly a service could be built that goes through known revocation lists for changes and summarizes them -- I'm assuming few such revocation lists will have any badges on it, so centralizing that process would make it easier to support checking signed badges at scale in the wild. (E.g. via extension)

Speaking of hashed email addresses. Since you're given the salt, and you know standard email address formats, as well as some idea (usually) of the users' name, wouldn't it be trivial to brute force variations on the user name with common public email or corporate email address endings? In addition, I've seen quite a few hosted assertions that leak the email address as username through the assertion URL. I suggest all this because it might be nice to support an identityType other than email where privacy is concerned, and encourage *not* hashing emails if using them as identifiers -- the hash doesn't add much value for anyone determined. It's true that email is a fantastic way of verifying identity, but perhaps we could also support some variant of OpenID or OpenID Connect? (E.g. URL?) Or just plain-text and leave it to the viewer to confirm its accuracy, as they would the domain of the issuer and the PNG itself. This will need more thought in the Q4 context of federation, I suspect.

Louis.

On Wednesday, March 27, 2013 5:05:23 PM UTC-4, Sam Kirchmeier wrote:

[Brian Brennan]

Hey everyone!

Louis did a great job of summarizing some of the benefits of signed assertions vs hosted assertions. Also, thanks for the links on stapling – it's something we will keep in mind should the need arise.

As to the points about brute forcing email addresses out of the hashes, I don't think that's a substantial worry. The payoff is extremely small (gain knowledge of the identity of one person in relation to a badge) for the work, especially since salts are going to be (or at least should be) unique per-assertion. The hash+salt doesn't add significant value for anyone truly determined to ascertain the owner of a single badge, that is correct, however it does add value when considering the entire badge ecosystem – it makes a big list of badges less desirable for spammers, for example, if they have to do significant work to get the identity out of each and every badge.

This isn't to say we don't plan on supporting different identityTypes down the line, though! We have been sticking with email address for now because it's an easy to understand, inherently federated identity descriptor but as we standardize what it means to be a compliant backpack we plan to revisit identities and figure out the best way to support new descriptors & multiple identities.

Brian

--

[Nate Otto]

Howdy!

I've been trying to dig through the Assertion spec to figure out exactly how the public/private keying works. As a public-key crypto newbie, I couldn't figure out from the documentation where the private key was used. What was puzzling me, I think, was that I wasn't familiar with RSA-SHA256, and the JWS documentation allows use of other algorithms that aren't public key crypto-based. 

After some exploring, am I correct in my summary of how this signing process works?

• Using the RSA-SHA256 algorithm, the RSA private-key encryption is performed on a hash of the payload, and the RSA public-key decryption is performed on the same SHA256 payload hash. Thus, the issuer needs only to publish a public key in order to generate signed badges.
  - http://ottonomy.net/2013/07/18/open-badges-technical-exploration-signed-assertions/

Sam does raise some interesting complications, particularly on what to do if an issuer's private key is compromised.

On scalability of the revocation list, should there be a standard way to request a true/false on the revoked? status from a server by badge id with the request for the full revocation list only as a fallback? 

Nate

[Louis St-Amour]

Hi Nate,

My apologies in advance: I'm typing this on an android with very little sleep.

HMAC based algorithms are commonly used for passwords because MAC stands for Message Authentication Code -- meaning both parties need to have the same code, or password, to then prove the source of the message without leaking the key to eavesdroppers. It's a "shared secret".

Public-private key signing, as opposed to general hashing and encryption, unlike HMAC, is about saying "I did this" without sharing the secret.

An algorithm, possibly the correct one, is: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-13#section-3.3

Here are some examples of the signing, though light on verification detail: http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-06#appendix-A.2

In contrast to RSA algorithms, there are shorter signature length ECDSA versions. In SSL, these can be used to provide what's advertised as "perfect" forward secrecy. (Meaning even if the private key is broken, they provide a way of randomizing the encryption in use at that moment such that recorded data can't be easily captured and decrypted later.) You can see an example of this mentioned in that text, as it notes you cannot exactly duplicate a signature by running the algorithm again. You'll instead have a different, yet still valid, signature. This extra instability is what lets you get away with smaller key sizes-- the built-in unpredictable nature of the output helps keep things random even with fewer encoded characters, or bytes.

http://rsapss.hboeck.de/rsapss.pdf
Anyway, to wrap up, the previous link appears to be an excellent introductory resource, though note the date and the emphasis on the distinction of a secure algorithm vs a secure implementation. Algorithms can be secure but then their implementations can be vulnerable. There's plenty more online, including the GRC/Twit production of Security Now and the Security StackExchange site. I'm sure Googling the different terms will reveal even more resources.

As to revocations, as I hinted at earlier, I think it might be an interesting idea for a verification tool or service to have a bundle of verified providers, of known trusted keys like SSL relies on today. And like SSL, this works best as Chrome has shown, if such revocation and key checking is performed locally at the browser to ensure verification sites aren't spoofed. That said, while useful for SSL, it might be overkill or itself attackable with fewer benefits for low-volume verifications. And if we run over SSL, such certificate integrity checking is less necessary. Properly secured SSL could help validate the source of a public key and revocation list.

Louis.

--

[Nate Otto]

You do very well on mobile with little sleep then! Thanks for the helpful link. Whether or not you want to write a book on it, we could probably stand to beef up the Open Badges wiki documentation on how this process works, maybe with a couple examples worked out or links to how people describe how their eventual implementations for various platforms are built.

Nate