X509 nprofile issues

Title: Message

 

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-X509.doc