Re: [wss] Minutes for F2F, Wed + Thu

[merlin <merlin@baltimore.ie>]

Attached are the minutes for Thursday. Issues/actions are
also broken out briefly at the top.



-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com

OASIS WSS Thursday 12th
-----------------------

Issues/actions:

MH: Issue: Remove the section on token reference lookup processing order?
MH: Issue: Should STR -> BST ValueType be a BST, not an X509v3.
MdB: Issue: Timestamps associated with individual tokens?
MH: Issue: Signature transform text.
AN: Action: Propose edits &| provide history on dcrpt transform
  and signature/encryption ordering.
Issue: Discuss deleting section 9.3.
ISsue: Change the text on reporting faults; may already be noted.

-----

EG: Presentation - Receipt Profile
CK: What do you mean by crypto proof of rcpt; versus ACKs.
EG: No proof that you got my msg unaltered in existing rcpt mechanisms.
AN: Reliable Messaging uses ACK/NACK; sign the ACK..
EG: If the signature was lifted from msg, how does sender know that
    signature was received and verified.. Tony gets in the middle,
    modifies msg & removes sig. You know that the recipient is making
    a statement that they received something.
CK: Don't you get into Gray's conundrum (Jim Gray) - only way I can
    get receipt is for you to reliably transmit it; for this we need
    an RM protocol so I need to ACK, & you need to ACK...
EG: Only works in success case when both msgs get thru. Could use with
    RM protocol. Without RM, not getting receipt means nothing.
CK: What guarantees do I get?
HL: When you get done you hav an audit trail.
CK: RM session with policy that we'll require and check signatures
    then a signed ACK is sufficient.
EG: If responding party is lazy & doesn't check sig, they can repudiate
    signature & you have no proof that msg was unaltered.
CK: Stay at technical vs legal level: What's the difference between
    this & BEA ACK. What are semantics of no RCPT?
SA: Without this I could get a response suggesting that something
    was done right when it wasn't. This gives a cryptographic audit
    trail.
CK: Isn't this RM?
EG: Crypto chain of evidence.
PHB: Useful and necessary to have in stack; had to invent it for XKMS,
     don't want to have to do this for everything else. Is this WSS
     or sec conversation or RM? 
SA: Almost in RM. Why not get them to fix it.
EG: This is useful in unreliable sense.
PHB: What does this committee do post WSS 1.0?
KL: Core + profiles; then we make that decision on what next. This
    might be appropriate for another TC.
PHB: RM not crypto secure; not necessarily a good match.
HL: We seem to be providing crypto building blocks; receipts
    not necessarily a bad match for us. Secure conv & policy
    don't seem a good match.
PHB: Motion to table & revisit after discussion of future.
     
Issue 84 from yesterday..

CK: Why is encrypting a signature with this spec difficult?
HL: Strike the sentence..
AN: Disagree with not allowing dcrpt transforms as part of the base
    spec.
MH: Disagree that recipient needs to look through all security
    headers; only intended recipient will be able to perform
    decryptions.
AN: Spec is not wrong; may need clarification. Need to revisit
    old notes on why dcrpt transform is needed.
HL: Attn my original msg on these issues; will repost.
CK: Issue open; action: Tony propose edits &| provide history.

Goals moving forward:


KL: What is essential for 1.0 and when.
PHB: Core spec & Username & X.509 & SAML & XRML; Kerb has less work.
HL: Obs. Interop only tested username & X.509 & core.
AN: If core spec fairly stable then do v1 core spec, evolve profiles.
PC: Wearing WS-I hat; basic security profile WG; we have normative
    ref to this group; we have 9 months from when WSS enters committee
    spec. Our profile will be against core, username, X.509 & Kerb.
    Just publishing core spec will not help us very much.
TJP: Try to get as many profiles out as possible; XRML & SAML are
    fairly mature..
RM: Are there plans for more interops.
GH? Need at least one more. Should we push some small list of
    specs out quickly? 
KL: Do we do another interop soon testing much of core spec & username/x509,
    deliver these as 1.0 & others as a rapid 1.1 or a larger 1.0?
CK: WSI needs username, x509 & kerb.
DF: No need for all profiles to be on same timeframe as core.
HL: General agreement for that.
GH? Can have all profiles on v1.0 just with different timeframes.
KL: What's minimal first deliverable:
SS & many others: Core, username, X.509.
FS: Integration with WS trust & secure conv!
AN: Would also like kerb, XRML.
JM: Would also like SAML.
PM: Should have one of the XML tokens SAML/XRML.
PHB: Kerberos could invoke beasts from swamp; would be good to look at it ASAP.
CK: Kerb good to look at after username/X.509.
RM: SAML very important.
DF: Incumbent on us to get min spec out quickly. Core, username, X.509.
    Others can be run on a parallel path.
PW: Core & X.509 cover a lot of the interesting use cases.
ER: SAML should not _too_ far behind.
KL: General consensus around core & u/n & x.509; SAML & kerb; XRML.
RM: Can we have non-first-track profiles in interop along with cores.
CK: Concerned about delaying core profiles.
MH: Virtual interops might work for us at this stage.
KL: How many thing core & 2 need more interop before v1.
TN: What are the uncomfortable issues on this spec.
KL: Just a finite number of issues untested.
phone: Could declare committee spec now & have interop as part of public
       review.
GH: At least one more full-fledged interop preferably with further
    profiles. More scenarios will provide greater assurance to OASIS
    to accept this.
CK: Don't believe we can pull together a short-order physical interop.
    People should agree to virtual interop. Should agree finite list
    of things to interop test.
HL will work on new interop scenarios based on list.

Key interop things:
MH: Signature transforms, X.509 multiple certs, embedded
??: Specific fault codes; negative testing.
??: Timestamps w/ signatures.
RM: Different orders of tokens.
CK: Lets avoid conformance testing.
PR: Support for multiple key tokens (sign vs encrypt).
PC: Underlying signature tests?
EG: Attachments.
??: Bare reference lists.
RM: Token processing order.

CK: PKIPath/PKCS7 is well known; why test.
PHB: We're not using it in classical sense.
RM: Aren't we recommending PKIPath.
RM: Some profiles don't reference core fault coeds
AN: We should fix that outside of interop testing
MH: Fault codes are conformance testing, not spec testing
@RSA: But maybe the spec isn't clear which faults to return when.
RM: KeyInfo content order
MH: Hard to test without contrived; what's the point of it.
    Issue: Remove the section on token reference lookup processing order?
    It buys nothing.
@RSA: At least one test with multiple sign/encryptions.
CK: Multiple SOAP headers just tests actor/role.
EG: 9.3 has a section on encrypting attachments; should be tested.
CK: What attachment spec? Maybe we should remove 9.3.
EG: Reasonable to remove it as long as we readdress it when SOAP 1.2
    finishes.
    Action: Discuss deleting section 9.3.
Standalone ReferenceList is a novel use so we should test it.
Encryption & signature in different order depends on a resolution
to the open decryption transform / etc. issue.
RM: ValueType tests?
CK: We only have b64.
RM: References with non-local URIs.;
CK: What would this be testing wrt WSS; it's an XMLDSIG issue.
MH: Issue for the list; should STR -> BST ValueType be a BST, not an X509v3.
RM: Fault codes need testing.
MH: This just needs spec auditing.
KL: We don't require you to return a fault so we can't test it.
RM: Text says 'report' fault.
CK: Decided on phone that this does not need to be returned.
    Action: Change the text on reporting faults; may already be noted.
MdB Need real-world scenario test cases when we test parts of spec.
   How to associate Timestamp with signature.
MH/CK: Timestamp associated with security header, not signature or
       individual token.
MdB: Action: Raise this issue.
@RSA: Expires needs more discussion on list, may need interop.
MH: Action: Post signature transform text.
KL: No violent objection to doing interop in parallel with ctte spec.
    Timeframe for next virtual interop?
MH: 3 weeks after resolve interop-related issues?
AN: Not rehash old interop tests; focus on new interop tests.
CK: Beware 4 July. Plan on a call on the 24th to accelerate issue
    resolution of issues? Est Jul 15th interop.
KL: Try to have vote for ctte spec before that.
    Aim for July 1st vote on ctte spec?
CK: All v1 issues need to be on the table by June 17th.
KL: Will revisit receipt proposal.