Apple

0. Prior to app distribution, it sounds like I will be creating a self-signed root certificate for use in my web service and embedding in my app. I plan to do something like what's described here: http://www.eclectica.ca/howto/ssl-cert-howto.php#rootc. Per the instructions, this will leave me with a .pem file for the cert, and another .pem file for the private key. I'm confident enough in my Google and OpenSSL skills however to get it packaged however will work best.

Q: What do I embed in the app, and how do I package it? Do I put both the cert and the private key in a .p12 file and keep it in the app bundle?

1. user starts your app

Thank you for your confidence that people will actually purchase the app :-)

At this point, I will read the root certificate out of the app bundle and add it to my trusted roots - correct?

2. your prompt them for their email address

3. you send an identity request to your web service

4. your web service sends the user an email

5. user clicks a link in the email to verify their email address

6. the web service issues the user a certificate, signed by the web service's custom root certificate

Q: a common use case for this app is that it is used to shuttle instances of its documents between devices owned by a single individual. If he installs the same certificate on each device, does this present any issues? (the sending and receiving peers will have identical certs).

7. the web service sends the user the certificate and its associated private key, wrapped up in PKCS#12 blob attachment; this attachment does not have with the standard extension/MIME type, but a custom extension/MIME type that's claimed by your app

8. the web service optionally forgets the user's private key (things are more secure if you forget it, but it's not as easy for the user to refetch their identity if they lose it)

9. user opens that attachment in Mail

10. your app gets the PKCS#12 and installs it in the keychain ready for future use

Here's some more...

Q: install in keychain = SecItemAdd() correct? With a class of kSecClassIdentity? And I'd send in a persistent reference, write to disk, and pull it back up to refer to this identity in the future?

Q: Now on to usage... imagine the following scenario: peer A initiates a connection to peer B, both peers have already added the embedded root certificate to their trusted roots.

When A initiates and opens streams to B, I would do something like this at A:

[inStream setProperty:NSStreamSocketSecurityLevelNegotiatedSSL forKey:NSStreamSocketSecurityLevelKey];

[outStream setProperty:NSStreamSocketSecurityLevelNegotiatedSSL forKey:NSStreamSocketSecurityLevelKey];

            NSDictionary *settings = [[NSDictionary alloc] initWithObjectsAndKeys:

                                      [NSNumber numberWithBool:NO], kCFStreamSSLAllowsExpiredCertificates,

                                      [NSNumber numberWithBool:NO], kCFStreamSSLAllowsAnyRoot,

                                      [NSNumber numberWithBool:YES], kCFStreamSSLValidatesCertificateChain,

                                      kCFNull,kCFStreamSSLPeerName,

                                      nil];

CFReadStreamSetProperty((CFReadStreamRef)inStream, kCFStreamPropertySSLSettings, (CFTypeRef)settings);

CFWriteStreamSetProperty((CFWriteStreamRef)outStream, kCFStreamPropertySSLSettings, (CFTypeRef)settings);

Not sure about kCFStreamSSLPeerName above... I'm ignoring it because there are no valid domains in this case, and my trust is boiling down to the custom root already installed and trusted. A now waits to hear back from B.

Over at B, I'm doing this when the listener gets streams to the requesting end at A:

[inStream setProperty:NSStreamSocketSecurityLevelNegotiatedSSL forKey:NSStreamSocketSecurityLevelKey];

[outStream setProperty:NSStreamSocketSecurityLevelNegotiatedSSL forKey:NSStreamSocketSecurityLevelKey];

        NSDictionary *settings = [[NSDictionary alloc] initWithObjectsAndKeys:

                                  [NSNumber numberWithBool:NO], kCFStreamSSLAllowsExpiredCertificates,

                                  [NSNumber numberWithBool:NO], kCFStreamSSLAllowsAnyRoot,

                                  [NSNumber numberWithBool:YES], kCFStreamSSLValidatesCertificateChain,

                                  kCFNull,kCFStreamSSLPeerName,

                                  [self.session sslIdentityAndCertificates], kCFStreamSSLCertificates,

                                  [NSNumber numberWithBool:YES], kCFStreamSSLIsServer,

                                  nil];

CFReadStreamSetProperty((CFReadStreamRef)inStream, kCFStreamPropertySSLSettings, (CFTypeRef)settings);

CFWriteStreamSetProperty((CFWriteStreamRef)outStream, kCFStreamPropertySSLSettings, (CFTypeRef)settings);

The sslIdentityAndCertificates method fetches the identity from the keychain and packages the needed components up in the required array for setting the property on the stream. In the process of negotiating the secure connection, the identity data makes its way over to A...

At A the peer evaluates trust by comparing down to the root certificate, which is trusted internally by the app.

Q: I do *not* override the TLS chain validation, correct? It should all work, if configured as above...

Please let me know if I'm headed off track in any regard, and thanks again for your help!

John

References:
	>Peer-to-peer SSL/TLS best practices/strategy (From: John Pannell <email@hidden>)
	>Re: Peer-to-peer SSL/TLS best practices/strategy (From: "Quinn \"The Eskimo!\"" <email@hidden>)