[wsf-c-dev] WSF4PHP API addtions

[Kaushalye Kapuruge]

James Clark wrote:
>> There are other options that you have to specify
>>     
>
> We're making a long-term commitment to the WSF/PHP API, so we need to be
> very careful and consider whether a proposed API corresponds to
> something that we can support over a long-period of time.
>
>   
>>       "encryptionKeyIdentifier" => Embedded |IssuerSerial 
>> |DirectReference |KeyIdentifier
>>     
>
> I think this corresponds to the following Security Policy assertions:
>
>   
Yes. But we do not support ThumbprintReference.
>> /sp:X509Token/wsp:Policy/sp:RequireKeyIdentifierReference
>>    This optional element indicates that a key identifier reference is required when
>>    referencing this token.
>> /sp:X509Token/wsp:Policy/sp:RequireIssuerSerialReference
>>    This optional element indicates that an issuer serial reference is required when
>>    referencing this token.
>> /sp:X509Token/wsp:Policy/sp:RequireEmbeddedTokenReference
>>    This optional element indicates that an embedded token reference is required when
>>    referencing this token.
>> /sp:X509Token/wsp:Policy/sp:RequireThumbprintReference
>>    This optional element indicates that a thumbprint reference is required when
>>    referencing this token.
>>     
>
> If so, I think we should use compatible terminology, maybe:
>
> securityTokenReference => "KeyIdentifer" | "IssuerSerial" |
> "EmbeddedToken" | "Thumbprint"
>
>   
+1.
securityTokenReference => "KeyIdentifer" | "IssuerSerial" |
"EmbeddedToken" | "DirectReference"

DirectReference :-  Section 7.2 of WS-Security 2004


>> e.g. "keyFileLocation" => /path/to/file,
>>       "encryptionUser"   => value
>>       "keyStorePassword" =>value
>>     
>
> -1. These look ad-hoc and non-general to me.
> How do these deal with different kinds of key store?  Even if our
> implementation is currently limited, we need an API that scales up to a
> full implementation.
>   
Agreed. But as in Java counterpart rampart/C uses "encryptionPropFile" 
to specify either the certificate or the keystore.
Since that encryptionPropFile  doesn't make much sense I "just 
suggested" that in PHP, it might be better to use "keyFileLocation". But 
it's up to the PHP developer to use what ever the name.
> In general, it's bad to pass filenames around.  Unless the contents of
> the file is large (which it is not in this case), pass the contents as a
> PHP string.
>
>   
-1. The keystore can be large and its binary(e.g.PKCS12/PFX format). 
Better to leave it for rampart to load the file from the given filename. 
> Is keyStorePassword for when the private key is protected by a
> passphrase?
>   
KeyStorePassword is the password used to import key/cert pair to the 
keystore. Even though the recommended approach is to use a password 
callback module, I give this feature to specify password "directly" for 
PHP applications.
> What's the semantics of encryptionUser?
>   
EncryptionUser is to callback the password from a password callback 
module, if the KeyStorePassword is not specified.
> James
>
>
>
>
>   
Thanks for suggestions.  I think most of these configuration problems 
will be wiped out once the WS Security Policy is implemented.
-Kaushalye