With AsymmetricKey? cryptography, you have one PublicKey and one PrivateKey (often called SecretKey so the process can be described more clearly in functions; P(x) and S(x), rather than Pu(x) and Pr(x).) The thing about this is that P(S(x)) = x = S(P(x)). It doesn't matter what order the keys come off. This is not true of many SymmetricKey crypto methods, and it makes DiffieHellmanKeyExchange? possible.
So, if Alice is talking to Bob (Alice is always talking to Bob. If Alice talked to Betty, it wouldn't be crypto.), Alice creates a SymmetricKey for the message, and encrypts the key with her SecretKey [ SA(K) ]. She sends this to Bob, who encrypts it with his Secret [ SB( SA(K) ) ]. He sends this back to Alice, who decrypts it with her PublicKey [ PA( SB( SA(K) ) ), which is equal to SB(K) ] and sends it to Bob, who decrypts it with hsi PublicKey [ PB( SB(K) ) ] and gets the SymmetricKey.
Of course, you could reverse it somewhat. If Alice sends Bob a message encrypted with her SecretKey, anyone who can access the PublicKey can decrypt it. This serves as a DigitalSignature, which provides UserAuthentication? and NonRepudiation?.
But this, and much, much more, is actually the domain of PublicKeyInfrastructure.