XKMS Workshop minutes (draft)

Included are draft minutes for the XKMS Workshop. Please let me know if you
have any suggested changes. Note that the links to presentations don't work
yet - if you presented a set of slides at the meeting, please do send a copy
to  <mailto:reagle@w3.org> Joseph Reagle@w3.org so that we can get them
posted (and get these links to work!)
 


Joe Pato 
Principal Scientist
Trusted E-Services Lab - HP Labs
Chief Technology Officer
Internet Security Solutions Division
< http://www.hp.com/security <http://www.hp.com/security> >
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

HP Labs Cambridge
1 Main Street, 10th Floor
Cambridge, MA   02142
Phone: (617) 679-9376
Fax 1: (617) 679-9330
Fax 2: (781) 674-0142

 

 


XKMS Workshop
July 19, 2001, Redwood City, CA


Draft Meeting Minutes

Scribes: 

Part 1: Shivaram Mysore [ shivaram.mysore@sun.com
<mailto:shivaram.mysore@sun.com> ], Sun Microsystems Inc 
Part 2: Frederick Hirsch [hirsch@zolera.com]
 
Minutes augmented with material from Jean Pawluk, Conclusive Logic


Part 1


  _____  

9.00 - 9.35 (35 minutes): Introduction 

1.	Danny Weitzner, The question on the table - shall we constitute a
W3C activity for XML Key Management Services? (10m) 

2.	Group, Introductions Around the Room (15m) 

3.	Joe Pato, Agenda (5m) 

4.	Group, Agenda Bashing (5m) 

  _____  

9.35 - 10.30 (55 minutes): Requirements I 

	Core Requirements: 
1.	Phillip Hallam-Baker, VeriSign - W3C XKMS workshop position paper. 


*	The Original presentation can be found
<http://www.w3c.org/2001/07/xkms-ws/presentations/phill.ppt> here. 

*	XKMS is proposed to reduce barriers in PKI deployement for both
Customers and Manufacturers. 

*	XKMS *must not* do X509 in XML syntax 

*	Traditional PKI was not designed to be complicated. It just became
so over a period of time. Now that we have a chance to design this from
ground up, we should also think of how this can best fit new devices and
applications. We should be able to sell security to Moms and Dads. 

*	XKMS will allow thin clients that are unaware of the PKI system
deployed. Complexity is migrated to middleware and away from application
(and away from clients entirely). 

*	Q: Joseph Reagle, W3C - Will there be a dependency on XML Query?
A: Phill - No Dependency is desired. XML Query is not fully baked with
request/response structures. It is based on SQL and exposes internal
structure of the infrastructure which is not desired. 

2.	Mark Curtis, Reuters - XKMS for B2B electronic services - A consumer
perspective 


*	The Original presentation can be found
<http://www.w3c.org/2001/07/xkms-ws/presentations/mark.ppt> here. 

*	The presentation gave an overview of what Reuters is all about and
their business objectives 

*	B2B Issues:

*	Operability across multiple domains 

*	Interoperability between domains

*	trust relationship

*	Business relevant trust attributes

*	context of business 

*	meta data for acceptance

*	Recommendations

*	Push ahead low tier service definitions 

*	Outline scope of high tier requirements, e.g., Who, what and context
with matching info to tell relying party that information is defined and is
associated with particular trust levels 

*	Map relationship with other standards

*	Q: Danny Weitzner, W3C - Higher level trust - What user level are
you talking about? 
A: Mark - At a higher lever - do we understand what attributes are what we
can do about it. 

*	Q: Danny Weitzner, W3C - Example?
A: Medical industry has a different privacy statement and kind of
information collected as compared to a Financial industry's privacy
statement and kind of info collected. 

*	Comment: Phill H. Baker, Verisign - Read purpose of XML Trust
Assertion Service Specification, XTASS [ research note ]. SAML is not a
competitor to XTASS. XTASS could be used in some parts of XKMS/X-KRSS 

*	Q: Mike Just - Can we use the key level for XYZ? 
A: Mark - This is too low level. We need a higher level of Security. 

  _____  

10.30 - 10.45 break 
  _____  


10.45 - 12.30 (105 minutes): Requirements II 

	Additional areas - bulk registration, 4-corners, inter-domain trust 
1.	Merlin Hughes, Baltimore (20m): Bulk operations to support smartcard
management (X-BULK) 


*	The Original presentation can be found
<http://www.w3c.org/2001/07/xkms-ws/presentations/merlin.ppt> here. 

*	Use Cases: Smart card factories, device factories (TPMs like TCPA
platform modules) 

*	Goal is to deliver a separate spec that defines batch registrations
using XKMS core definitions. 

*	Q: Joseph Reagle, W3C - Does this take parts of XKMS and stick it
into XBULK?
A: Merlin - Yes, here is an example. See slide on X-BULK Request 

*	Q: Mack, Bank Of America - Bulk process is highly tailored. I am
missing the value add here :-( 
A: Merlin - Things are not tied to a particular vendor 

*	Q: David - XBULK answers only one aspect of bulk key registration.
There are lots of other items that are required to be answered
A: Merlin - Agreed. 

2.	Mike Just, Entrust (20m): XKMS to satisfy card manufacturing systems



*	The Original presentation can be found
<http://www.w3c.org/2001/07/xkms-ws/presentations/entrust.ppt> here. 

*	Q: Barbra Fox, Microsoft - On Key Registration Service Requirements
slide - Any person can get any info on the key
A: Mike - Possible 

*	Entrust talked to card manufacturers like Gemplus, Schlumberger, etc
on requirements for cards to support XKMS (see slide 1 and 1 contd.). It was
suggested by the group that a sub team should work on the card manufacturer
requirements and then suggest it to the working group. 

*	Q: Mack, BOA - On KISR - my suspicion is that I haven't found an
application in the Bank that does some kind of policy, trust anchors, audit
trails. They never look into this.
A: Mike - Fair observation. May be in a later release. This does not have to
be done today. 

*	Q: Mack, BOA - Is the WAP device connecting to a service and then
determining if it is negotiating or doing a secure transaction?
A: Mike - No. It is the service which is providing the info and not the WAP
device trying to understand what is being done now. 

3.	Blair Dillaway, Microsoft (20m): Beyond XKMS - requirements for a
.NET world 


*	The Original presentation can be found
<http://www.w3c.org/2001/07/xkms-ws/presentations/ms_net.ppt> here. 

*	Scope of XKMS - Syntax of Context to be defined and not its
Semantics. See Slide on Contextual Trust Management. 

*	Q: Mack, BOA - Contrast simple XKMS with SAML
A: Blair - Rationalize this effort with SAML, XTASS, etc. 

*	Q: Jeff, Oblix - Envision Context as a collection of attributes?
A: Leave it to the application. For N-Party transactions, TLS, SMIME, etc
will not cut it, but, will require message-level security. 

*	Q: Danny, W3C - What are your requirements regarding the last one?
A: Blair -



*	Define standard for carrying authentication info and encrypted
message. 

*	How can we do this with Asynchronous messaging and N-way? It will
become complicated. 

*	Can XKMS wait for XMLP and come up with a generalized solution? 

*	Q: Ben - What Microsoft tools implement these?
A: Blair - Microsoft has XML DSig in .NET Beta 2. They also a prototype of
XML encryption internally 

4.	Daniel, Identrus - XKMS and the four-corners model 


*	The Original presentation can be found
<http://www.w3c.org/2001/07/xkms-ws/presentations/identrus.ppt> here. 

*	Identrus deals with Trust between Banks 

*	XKMS is good because it moves trust from customer to the Bank 

*	Higher level assertions are welcome and useful to us. 

*	Context is very important to us. Mack, BOA added - If too many
messages are going on between parties, it is difficult to track. But, with
XKMS and SAML we can pack lot more info into a message and hence it is more
useful and practical especially in the financial industry. 

*	How we rely trust information between customers and bank is very
important to us. 

*	Phill Baker said Decouple client with PKIX 

*	Joe Pato, HP - Trust Relationship between consumer, Trust provider
and Peer to Peer ones must be clearly defined. 

  _____  


XKMS Workshop Notes, Part 2


7-19-01, Frederick Hirsch

1.
<file:///C:/Documents%20and%20Settings/jnpato.PALO-ALTO/Local%20Settings/Tem
porary%20Internet%20Files/OLK9/XKMSnotes2.html#proposal> XMS version 1.1/1.2
proposal 

2.
<file:///C:/Documents%20and%20Settings/jnpato.PALO-ALTO/Local%20Settings/Tem
porary%20Internet%20Files/OLK9/XKMSnotes2.html#xbulk> XBulk 

3.
<file:///C:/Documents%20and%20Settings/jnpato.PALO-ALTO/Local%20Settings/Tem
porary%20Internet%20Files/OLK9/XKMSnotes2.html#scope> Scope 

4.
<file:///C:/Documents%20and%20Settings/jnpato.PALO-ALTO/Local%20Settings/Tem
porary%20Internet%20Files/OLK9/XKMSnotes2.html#W3C_activity_process> W3C
activity process 

5.
<file:///C:/Documents%20and%20Settings/jnpato.PALO-ALTO/Local%20Settings/Tem
porary%20Internet%20Files/OLK9/XKMSnotes2.html#next_steps> Next steps 


proposal1. XMS Version 1.1/1.2 Proposal 

Dr. Phillip Hallam-Baker, See the slides for details - these notes capture
discussion but do not reproduce the slides. 

The Trust assertion XML infrastructure research proposal (TAXI) was the
basis for XKMS and XTASS, XTASS was released to public to avoid boxing
patents for prior art. SAML is at v0.10 and supersedes the XTASS assertion
framework. Currently XTAML draft is under development to retire XTASS.


Architectural goals


Thin client, fat server. Avoid negotiation and questions of server
functionality: XKMS can be extended with additional interfaces, making it
clear via WSDL which services are provided, avoiding negotiation frameworks.
Client does not need to find out what server supports. Trust service
implements entire specification. 

[Shivaram Mysore] Does this assume you are always connected to the network?
[Jeremy Epstein] Is this appropriate for a mail based system? - The general
issue is online versus off-line operation.

Chaining support, not referrals. In chaining model, a directory finds what
it does not know by working with other directories. In the referral model
the directory tells the client potential alternative directories. To be
consistent with offloading functionality to the server XKMS supports
chaining and not referrals. This is similar to the operation of DNS.

ds:KeyInfo management: XKMS specifies protocol for managing ds:KeyInfo
elements. Locate returns correct information from trust service but client
can do trust chain validation for itself.

Key Usage identifier "closed", not extensible: three purposes are signing,
exchange, encryption . Key recovery is important for encryption, not
appropriate for signing, and exchange is the middle ground. To have
additional profile on use of key, define another element, do not use key
usage element. Avoid all the issues and discussion associated with
certificate key usage bits.


Protocol Key Location

In PKIX the name in a certificate (e.g. the DN) is different from the name
in protocol - the DN means nothing in VeriSign certificates. Rather use
alternative key name. 

*	who - DNS name will work for anything 

*	url = how://where/what 

*	need to clarify KeyID in draft - profile URIs for purposes, e.g.
S/MIME key. 

[Mike Just] What does it mean to obtain multiple responses? -- If you
associated multiple bindings with a key, as has happened in testing, then
you will get back multiple associations.

[Joseph Reagle] Concern with typing mechanism and namespaces for response
values, rather than just strings (in <String>). [Phillip Hallam-Baker] SAML
incorporates a proposal from Joseph Reagle. This response was created using
a SOAP generator.


[ Eric Prud'Hommeaux ] - is specification of type a goal? [Blair Dillaway]
typing is in the spec. [Don Eastlake] Values within the <String> element
should be valid element names, [Joseph Reagle] but need to consider
namespace qualification.



Validation Context


Trust service decides who the trust service trusts - trust roots chained up
to when hierarchical. Use different URIs to access different trust roots
from a single service. No language for describing trust service (e.g. client
can't say I trust A, B,C). If so, another interface, not an extension to one
interface. 


Registration


No support for suspension: easy to suspend, hard to reliably un-suspend.


SOAP


Potential issue of dependency on W3C protocol activity and SOAP -decouple by
breaking specification in two. [ Joseph Reagle ]- what is normative? Syntax?
Could specify using SOAP 1.2 as option? -- define bindings to SOAP, BEEP,
separately. How to sign SOAP/XP messages, raises canonicalization issues -
XML core specification should support moving XML fragments from one document
to another, but doesn't. XML Signature found this problem first. [Don
Eastlake] - XML Signature should be fixed soon, XML core might take a while.


Status 


Errata


a.	KeyUsage is not referenced where it should be, and some others.
Fixed in what has been built 

b.	Implementations of the specification have varied - need to tighten
language 


Timeline


1.2 draft out soon - vendors are doing implementation, interoperability (3-6
months). Core spec 12-18 months

Conclusion - XKMS should be W3C standard. Core XML infrastructure, built on
top of W3C XML standards, and will be built upon by other W3C standards.
Vendor and customer support. Will be open standard or defacto.


Questions


[ Joseph Reagle ] - Key Information Service (KISS): protocol; syntax and
semantics - issue for extensibility and namespace support. Would like
additional separation. Validity interval, Tier 0 and Tier 1 How to send
other information (XML) back in binding element? 

Will need to revisit XML schema. 

[ Joseph Reagle ] - key identifiers could be URIs - need versioning, hence
URI (e.g. change KeyInfo KeyData, changing string to empty element.) Phillip
Hallam-Baker is amenable to discussing this.

[Joe Pato ] Need to understand how this will work with connection limited
environments (software installation, mail S/MIME)


xbulk2. XBulk


This will be a separate specification from XKMS, since it will be more
stable and do not want to revise it with each XKMS revision, but work on
this will influence XKMS, such as being able to say what private key
encryption format is expected back by the client [Phillip Hallam-Baker]. 

See the slides on XBulk. Baltimore and Entrust will work together to create
one common standard, and reuse XKMS schemas and definitions as much as
possible.

XBulk will also affect WSDL - to avoid limits and issues of testing specify
the maximum number of requests supported in WSDL. Also need to define
appropriate SOAP errors.

XBulk supports Template mode - define template, number of key pairs and
starting serial number.


scope3. Scope


Joe Pato called for the sense of the room with regard to pursuing a W3C
activity for XKMS. No objections were raised and there was clear agreement
to proceed to propose a W3C activity.


Scope Discussion


*	Clarify initial scope is 1.1 cleanup [Joseph Reagle] 


*	Necessary for speed - customers are ready to field XKMS now, not put
in PKI and then have to replace it [Jeremy Epstein]. Could wait up to 9
months, longer. v1.0 finished in Nov, been 8 months with little progress.
[Phillip Hallam-Baker] 1.1 end of Jan. Implementation and interop has been
happening.[Jeremy ] Need use case workgroup to determine use cases and
validate time requirements [Joe Pato]

	

*	Would like additional Tier 1 and Tier 2 distinction [Joseph Reagle] 

*	X-Bulk requirements should start at the W3C at the same time but be
out of this scope [Joseph Reagle] 

*	Privacy requirements should be added to list [Barbara Fox, Daniel
Weitzner ] 


*	Registration and location: Include access and use of keys beyond
terms made available. P3P offers means to specify policies and mechanisms.
Issues include notice (say what service does), compliance (trust model,
relying on service to comply) [Daniel Weitzner ]. Advisory information
versus cryptographic enforcement [Phillip Hallam-Baker] 

*	Managing expectations and obligations goes beyond cryptography [Joe
Pato]. 

*	Privacy approach essential to become deployed standard - use P3P
material if you can. At least have hooks. [Barbara Fox]. what is scenario
for privacy? if you trust them enough for processing, can also trust privacy
[Joseph Reagle ] define interface to return P3P privacy statement vs deep
integration [Blair Dillaway ] Need hook for registration [Barbara Fox] will
write draft for notification [Phillip Hallam-Baker] 

	

*	Need to include long term in activity definition [Mike Just], but
aim for short horizons, 1 year [Joseph Reagle] 

*	Need to clarify client trust relationship with server, avoid browser
issue of building in trusted roots [Frederick Hirsch]. Difference since only
need to trust XKMS server. Establishing trust between client and trust
service important in XKMS, but can be built using SAML [Phillip
Hallam-Baker] Don't want to rebuild root structure of PKIX, hence should
allow another way, e.g. PGP peer mechanism etc. The slide showing the root
key in the vault does not make this clear [Barbara Fox] Need to understand
key renewal and private key issues [Joe Pato] Do not mandate trust model,
question must be addressed in a different draft - trust axiom optional, not
required, may be proposed in scope of group 

*	What is priority of extensions in presentation [Barbara Fox]. 

*	Determine what needs to be done for legacy integration,
non-normative white paper. 

*	Need for audit capability - audit guidelines, but make it deployable
unlike CAs,RAs[Mack Hicks], Declare what is out of scope, make it audit
neutral [Daniel Weitzner ], need implementation guidelines [Jeff Hodges] 

*	Need to decide goal, don't need requirements for 1.2 , but should
make a requirements document available clearly articulating goals. [ Joseph
Reagle ] Phillip Hallam-Baker should send the list of errata for 1.1 to the
list. 

*	4-corner model, including 4-corner "hat", out of scope. 


	

	

	

	

	

	


W3C_activity_process4. W3C Activity Process


Joseph Reagle, see slides and W3C process document)

Number of activities in different domains - groups within activities
(working groups, interest groups, coordination groups). Usually limited to
members, but some public (e.g. XML Protocol, XML Signature, XML Encryption).
People at the W3C are the glue between groups. The process is to create an
activity, establish a working group, establish resources, including chair,
editors, authors. Document stages include working draft, last call
(requirements have been addressed), candidate recommendation (implementation
and interop testing have been done), proposed recommendation (referred to
W3C advisor committee), and recommendation (recommended by the W3C
director). 


Scope 

XKMS 1.2 with cleanups and then 2.0
How many working groups, dependencies, deliverables. 

next_steps5. Next steps

1. Formulate consensus
2. Create and submit activity proposal - charter
This includes activity duration, milestones, patent policy (royalty free
license), liaisons to other activities, dependencies on other activities,
commitment by those dependent on this activity to review the work (e.g. XML
Protocol). 

3 Director approval
4. Advisory Committee approval

Typically it can take time for an official activity start - it took 4 months
for XML encryption, but work can start informally before [Joseph Reagle].

*	Agreement - the participants agreed that the activity should be
proposed. 

*	Agreement:: Royalty free licenses are a goal of the workgroup for
use in implementation of this recommendation. 

*	Agreement: Participants at this meeting agreed this should be an
open work group. 

*	Action item: go back to organization to determine if any
organization patents could impact activity.


Activity plan [Joe Pato]

*	Need to get charter committee to submit charter in the next 3 weeks.


*	Formal face to face by early October 

*	Those participating as substantive members need to commit for
charter today, others later 

*	Discussion will happen on the workshop list


Roles include chair (40% effort), editor (30% effort), authors, and
participant in work groups, including charter and use cases.


Charter


An activity charter will be submitted to the W3C by Aug 15. The draft
charter Phil has created will be a starting point and updated by the charter
work group. If you have concerns on the charter, voice them or on Aug 15th
the charter will be submitted. The working group positions do not need to be
identified for the charter, apart from the chair. If interested in the chair
position send a note to Joseph Reagle and Daniel Weitzner by Wed the 25th of
July.

If you are interested in being an author or editor, send a note to Joe Pato.
Phil can continue being an editor, but can have a coeditor. Individuals
interested in chairing the activity should send a note to Danny Weitzner and
Joseph Reagle.

Volunteers for Charter workgroup:

*	Daniel Ash 

*	Phillip Hallam-Baker 

*	Blair Dillaway 

*	Merlin Hughes (potentially for Steven Farrell) 

*	Mike Just 

*	Shivaram Mysore 

*	Joe Pato 

*	(Joseph Reagle) 


Liaisons


*	W3C, W3C director - Joseph Reagle 

*	Oasis - SAML - Phillip Hallam-Baker 

*	WAP- Mike Just 

*	ETF/Sacred- Stephen Farrell 

*	ETSI - W3C has liaison (Joseph Reagle ) 

*	W3C XML DigSig - Don Eastlake 

*	W3C XML Encryption - Joseph Reagle 

*	W3C XML Protocol - Joseph Reagle (will liaison with Hugo Haas) 

*	ebXML/Oasis portion - Joe Pato 


Use Cases Subgroup


Need to establish use cases subgroup to identify use cases and to capture
time frame requirements Volunteers included David Wen and Mack Hicks.


Participant Actions



*	Tell your company advisory committee member that a proposed XKMS
activity is coming. 

*	If you did not get zip file with position papers, send mail to
<mailto:reagle@w3.org> Joseph Reagle@w3.org to be added to the list.