RE: [wss] X509 nprofile issues

Tim's issues

1. Is it desirable to use the same element as a reference and a referent? I am referring t= o the use of wsu:id in SecurityTokenReference and in the BinarySecurityToken. It wou= ld preclude one from making a reference from a reference, at the very least.

2. In Section 3.4, the proposal should be more fully described. I think it says that a ds= :signature should contain the optional ds:keyInfo, which (in turn) should contain a S= ecurityTokenReference, whose wsu:id attribute matches the wsu:id of the BinarySecu= rityToken. Why would one not just put the wsu:id in the ds:keyName element of the ds:ke= yInfo?

1&2 During the call it was decided to add wsse:KeyIdentifier in the same manner as for the saml spec. See bellow.

3. Under what circumstances would one need to reference an X.509 certificate containi= ng an =22encryption=22 key? Perhaps, to provide the encryption key of the message ori= ginator? Personally, I prefer to use a policy mechanism for this purpose. Should not= this profile describe how to convey a SKId or IssuerSerial?

3 Only reason for giving an encryption cert is to tell the other party which encryption key to use. If a party is using a single cert for encryption and signature there is a possibility that the cert is already present as a signing cert in another part of the message but only if the message is going arround in circles.

There is an opportunity for doing this in XML Encryption, one just uses the X509Data with the cert serial number identifier. Given that this is only going to bind to one decryption token possibly of many I think it is simpler to attach the key info in the xml encryption blob direct.

4. It may be necessary to convey more than one certificate. It should be explained whic= h elements have to be duplicated in order to convey multiple certificates. If there ar= e multiple certificates and CRLs, then they are not all referenced directly by a Securi= tyTokenReference. Rather, they may be referenced by conventional X.509 techniques= from another certificate. This should be described.

4 OK wil put in language to state that we are identifying a Certificate here, and that may be by reference to the cert itself and all supporting data (CRLs) written out eriatim or may be references to such, either as a full cert or as merely a cert identifier.

5. In Section 3.6, it isn't clear to me why are we stating such a soft requirement for erro= r codes? I suppose it is only necessary that both parties agree how to indicate that the= re IS an error. However, is there a good reason for not requiring that implementations= support some common codes?

5 I guess this is an interop issue, I think that we should make the requirement a MUST use the error codes stated in the core but MAY specify modifiers.

1.1 Identifying and Referencing Certificates

An attached X.509 certificate is referenced by means of the wsse:SecurityTokenReference element that contains a wsse:KeyIdentifier element. The wsu:Id attribute of the wsse:KeyIdentifier element references the value of the wsu:Id attribute specified in the wsse:BinarySecurityToken.

Example TBS[PHB1]

[PHB1] Need an example here

wss message