1
votes

I'm building an Oauth library for CodeIgniter, short question regarding signature signing using RSA-SHA1 in Oauth. The Oauth documentation ( http://oauth.net/core/1.0/ ) states:

9.3.1. Generating Signature

The Signature Base String is signed using the Consumer’s RSA private key per [RFC3447] (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography; Specifications Version 2.1,” .) section 8.2.1, where K is the Consumer’s RSA private key, M the Signature Base String, and S is the result signature octet string:

            S = RSASSA-PKCS1-V1_5-SIGN (K, M)

oauth_signature is set to S, first base64-encoded per [RFC2045] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” .) section 6.8, then URL-encoded per Parameter Encoding (Parameter Encoding).

So should I presume that the user already knows his/her private key? Or do I need to pull it from their private certificate?

Thanks for your time.

1

1 Answers

3
votes

There is no such thing as a "private certificate". A certificate is always, by definition, public.

A certificate specifically contains an identity (basically, the name of something or somebody) and a public key. The public key can be used to verify signatures which have been generated using the corresponding private key. The private key is not in the certificate.

Unfortunately, some widely spread "documentations" call "certificate" (or "digital identity" or even "private certificate") the combination, into a single archive, of a certificate and the corresponding private key. Such archives often follow the PKCS#12 file format (often called "P12"), known in the Microsoft world as "PFX". (Most of the complexity of using cryptography in practice is about wading through multiple layers of sloppily used terminology; similarly, OAuth itself calls HMAC/SHA-1 a "signature", which is not proper.)

The OAuth documentation says, in section 9.3:

The RSA-SHA1 signature method uses the RSASSA-PKCS1-v1_5 signature algorithm as defined in [RFC3447] section 8.2 (more simply known as PKCS#1), using SHA-1 as the hash function for EMSA-PKCS1-v1_5. It is assumed that the Consumer has provided its RSA public key in a verified way to the Service Provider, in a manner which is beyond the scope of this specification.

which means that:

  • the Consumer has access to a RSA private key
  • the Service Provider knows the corresponding public key "in a verified way"

and how these things are done is out of scope of the OAuth specification. Presumably, at some point, the Consumer showed his public key to the Service Provider, possibly as part of a certificate (which the Service Provider duly validated as per X.509 rules), or through some other mean which ensures "verification". The point is that the signature, being computed with the private key, is a convincing proof that it was computed over the same signed data by whoever controls the private key corresponding to the public key that the Service Provider knows; the Service Provider must still make sure that the public key indeed belongs to whom it believes that it belongs. Certificates are a generic and complex way to do that.