RE: [wss] Comments on X.509 profile

[Tim Moses <tim.moses@entrust.com>]

Chris - It'll be easier to judge when I see the revised X.509 profile.  When
is this likely to become available? All the best.  Tim.

-----Original Message-----
From: Chris Kaler [mailto:ckaler@microsoft.com]
Sent: Tuesday, March 11, 2003 12:56 PM
To: Tim Moses; WS-Security
Subject: RE: [wss] Comments on X.509 profile


RE 1 and 2: We discussed this on one of the calls and edits were made to
the core specification to better explain the use of
SecurityTokenReference.  Can you take a look there and see if that
clears up either of the issues or if you still think we need additional
text in the token profile.

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com] 
Sent: Tuesday, March 11, 2003 9:17 AM
To: 'WS-Security'

Colleagues - The most recent update of the X.509 profile was posted on
30
Jan.  I made the following comments on 11 Feb.  All the best.  Tim.

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?

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?

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.

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?

All the best.  Tim.
-----------------------------------------------------------------
Tim Moses
613.270.3183

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>