RE: [wss] X509 nprofile issues

Title: Message

ooops, 
did not mean to send the word document to the list, had forgotten it was 
attached, sorry.

 

        
Phill

  
-----Original Message-----
From: Hallam-Baker, Phillip 
  [mailto:]
Sent: Tuesday, April 29, 2003 4:26 
  PM
To: 
Subject: [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