XKMS F2F DC ----------- Stephen Farrell Shivaram Mysore Joseph Reagle Merlin Hughes Blair Dillaway Frederick Hirsch Phill Hallam-Baker Daniel Ash Dave Remy etc. Regrets: Mike Just --------------------------------- Introduction // Stephen Trying to progress base spec; ideally to leave here with all big issues thrashed out and hopefully decided. --------------------------------- Tutorial // Blair cf slides slide: Historical Perspective >1.5 yrs ago, Msft, Vrsn, WebMethods, Dave Solo got together to try and produce an easier way to use PKI slide: XKMS Overview slide: XKMS Approach slide: Trust Models (1 of 2) slide: Trust (2 of 2) High value bootstrapping will probably involve business contracts; key distribution can occur there. slide: Using XKMS (1 of 2) slide: Using XKMS (2 of 2) slide: Next Steps ---------------------------------- Requirements / Frederick cf slides slide: General Requirements slide: Security Requirements . include digest of request in response or simpler mechanism? -> Last Call Comments Require SOAP, suggest SOAP, v1.1, v1.2? #1 ? policy explicit in requests or implicit in URI ? (does this raise dependency on HTTP/WSDL) Phill: Solves downgrade attack Farrell: Denis wants to specify which policy to use for a single service URI. Only thing you can send is name of policy; can't send policy, but putting in name is a slippery slope. Joseph: Just want to put service URI in the request. Phill: The current case is that the URI of the "SOAP actor" goes into the message; that should be fine. Frederick: Not the HTTP URI? Phill: Usually is the same. SOAP thinks of multihop processing; the actor is the URI that you really meant, not that of a proxy. Blair: The service URL is the unique identifier. Policy associated with that URL is separate issue; not specified in the message. Joseph: What is policy? Stephen: What the validate will actually do, etc. Phill: All of that policy / SAML / WSDL stuff is out of scope. A policy is a set of criteria for evaluating the trust in a key. Blair: Simplest way to do this is that policy is bound to service URI. Joseph: Another option is that a URI identifies a policy defined by, for example, the bankers. Return that a response is valid accoreding to a given policy URI. Frederick: Maybe agree that it is okay for it to be implicit in the service URI. Yassir: Should we specify that one URI is associated with one fixed policy? Phill: No; the policy in that case is a changeable policy. If we have another layer that says this service implements that policy, that's a WSDL problem. Frederick: So we don't go into policy issues. Shivaram: Assume policy won't change but it is out of scope. Fred: The URI is how you get to the service and the policy associated with that service is out of band. It is an aspect of the service that is out of scope for XKMS. Dave Remy: So can the client still download the policy? Phill: Policy is selected when you pick the service URI and get its trust key; all out of scope. Stephen: UDDI WSDL. Blair: Will probably be like current practice; go to their website and read a text policy. #2 Frederick: Is a server required to implement SOAP? SOAP 1.2? Blair: 1.2 appears to be "very close" to last call. Will have 1.2 draft very shortly. Should we move to it? Not that different from 1.1; got rid of some of the more complex encoding stuff. No difficulties in us moving to 1.2. Yassir: I'm not sure what are the IPR issues with 1.1. Several of the submitters submitted under RAND. Joseph: 1.2 would be clearer. I expect that at our last call people will wonder why we don't use 1.2 if we don't. Shivaram: 1.2 is royalty free. Stephen: What if 1.2 gets screwed up IPR-wise or anything. What is the MUSt implement? Phill: What would we want to do interop testing on? I don't think people will interop 1.1 if they'll move to 1.2. Blair: There's 1.1 deployed. So easier to go with that. Stv: Not very tightly bound to SOAP. Blair: Using Envelope and Body. Yassir: Are we SOAP agnostic or can we make it so? Blair: We're not. If we don't use SOAP we have to define/pick a different XML message format. Way to specify what I'm targeting, how the parameters are encoded, etc. Will end up with SOAP. Probably not avoiding any IPR issues. Phill: RAND people on original submission couldn't check their patents in time. Jo: If SOAP dependency is normative we'll be expected to use 1.2. Stv: How about a 1.1 profile and then slide to 1.2 later? Blair: Or we could have 1.1 & 1.2 profile. Shivaram: We should define one more binding with HTTP BEEP to make sure that if there is going to be IPR-related problems or schedule problems with 1.2 then we'll have a fallback. Blair: Since 1.2 is basically built on 1.1 with almost no changes and nobody has posted IPR statements on 1.2, it would be strange that someone is concerned with 1.1. Stv: RAND statement on docs. Jo: XP expects to be RF. Blair: People could still make a statement. Stv: Happy to say we should use 1.2 for normative purposes; may do work on 1.1 for interop purposes. Shivaram: Action look at 1.2 IPR statements; RF. Blair: XP is clearly RF. Yassir: Happy with this. Are we reliant on SOAP? If our requirement for payload security is SOAP security then we're tied to it. Stv: We didn't. Yassir: If you have an XKMS service, is SOAP a requirement? Stv: Normative dependency on SOAP 1.2, then yes. Blair: I was happy with the statment that we are defining a binding on SOAP; someone else can do their own binding. Fred: XKMS service not required to implement SOAP? Phill: Not a Web service if not SOAP Jo: Must implement SOAP, need not use it, it need not be exclusive. If you don't use SOAP, maybe don't implement. Stv: We could do a BEEP binding; if someone is willing to do it. Yassir: We specify A binding; we must not rely on SOAP features. Stv: We've agreed that. Jo: Is it mandatory to implement? You don't want that. Yassir: I don't mind if it is. Blair: Problem; if we only define a 1.2 binding, if you claim to be an XKMS service on your own binding, how do you prove that you are a valid XKMS service? Stv: If there's a normative ref to SOAP, then it is a MUST. Enough SOAP processing to be conformant. Phill: If you don't specify a binding, SOAP is assumed. E.g., WAP phones highly compressed. Stv: That's another spec. Fred: Services MUST IMPLEMENT SOAP 1.2 at a minimum. (May have other bindings). Hoping to avoid requirements on clients. Phill: If a Foo binding of XKMS is defined, then you claim conformance with THAT, not this, so you don't need to do SOAP. Daniel Multiple documents; one with binding? Stv: No. That's a pain. Only reason to separate things out is if you expect different rates of change. #3 Hash of request in response? Stv: That's not a req, that's part of the spec. Very similar discusison on PKIX list. Not in the requirements. Phill: Specifying a hash is too mechanistic. Stv: Just need replay detection. #4 Removing req to support key usage; it can be a signature property rather than key binding. Stv: Not a req issue; will go in spec issues lists. Jo: We have to say yes or no to this issue. Blair: No we will not remove the requirement. Fred: Revise requirement to be more general; you can register what the key is to be used for. Jo: Must respond and say that we assume the issue is closed unless object. For going forward we have to keep track of issues being closed, etc. # Add OCSP to the MUST list. Blair: Why do we want to tunnel OCSP responses? That's really part of the service policy. Phill: On locate you might want to send it down. Blair: It's not a big deal (opaque data); it just seems strange. Phill: Denis want it MUST if you claim X.509; but it is not a MUST in X.509. Stv: Why CRL too then? Phill: It's MUST in PKIX. Stv: No. Fred: Add optional OCSP to the X509-interoperable list. Stv: Doesn't mean you have to support OCSP; you just need to interstand the tag "OCSP" and can return NO. Fred: Does MUST mean MUST support, in the sense, return that type, or just understand the tag? Stv: CAn only be the tag; there may be no CRL. Fred: People will expect more than that of an X.509 interoperable XKMS. Yassir: How do they claim X.509 interoperability? Fred: OOB. Joseph: I don't have what you're asking for versus I don't understand what you're talking about. Fred: I assumed supported meant that you'd return it if it existed. Phill: If a client really must have an OCSP response, that's specialist; don't need negotiation of whether something is supported. The client will go to a service that supports it. Daniel: Quite a few places where we're trying to address the problem of having products we can implement. Maybe we should start a conformance doc and push statments like these into conformance. Jo: Wouldn't advocate separate conformance doc unless we have to. Should get it straight and have it in the spec. Will be a MUST because it is necessary for interoperability. Daniel: Will be limiting if we decide that SOAP is MUST, etc. Yassir: We've clarified that. Other specs can define other bindings. Jo: Typically what I say is if I don't have two interoperable impls we'll drop the structures. Otherwise lets go for MUST. Stv: I don't think there's a requirement for a separate conformance req. Daniel: Most likely the products that are built will deal with X.509 and there'll be a lot of interoperability statements needed to be made; that may be too much for the spec. Blair: This all has to do with "if you support X.509, which is not required, then you must support blah". Can we cut this down to just MUST X509Cert, and MAY everything else. Stv: X509Chain MUST be defined? Is this a req or just part of the spec. # MUST PoP Stv: Okay that we MUST describe. Misinterpretation; spec must describe, not MUST implement. Phill: Does there exist an encryption-only algorithm? Stv: There existing decrypt-only private keys. # BULK Stv: Decided to do it. Easy. # QNames Jo: Could be reqs, but lets make it a spec discussion. # TLS Fred: Change 'no-security' to 'other mechanisms' e.g., IPSEC. -- ** Potentially resolved issues # give examples of other means of establishing trust relationships with server Daniel: (aside) Would like to see less X.509 bias. Stv: Provide text. Blair: In requirements or spec? # Specify need to publish revication Stv: He might need to know when a key was revoked. Blair: Locate a CRL or whatever. # Update? Fred: Atomic transaction. Phill: I don't want to revoke a key! Nothing bad has happened. # Interop with req of opaque data Fred: Apps can ingore opaque data. # Key usage => is non repudiation in scope? Fred: Non repudiation is more than just a key usage. Phill: Non repudiation is not a supported key usage. # DOM APIs. Fred: No requirement for DOM seems appropriate. Blair: No impact on us; we don't define API, just messages. # General XML parsing support? Yassir: Are constrained devices a goal of ours? If it is, we'd be doing things very differently. Wouldn't be using fancy schemas and long tag names. Blair: I don't think it is a goal to support devices that can't even process XML. Stv: WAP forum may start to adopt XKMS. Joseph: Specification is not tailored to, but does not preclude, constrained devices. # introspection Stv: WSDL should show what interfaces are exposed. Blair: If they are to return an XKMS response code they have to implement all the services which means the WSDL will say they do it. They should just SOAP fault / HTTP 404 if the service is not implemented. Jo: The specification will not specify anything about servicde introspection; will use WSDL. Stv: Implementer MUST implement ALL defined services, but valid to deploy a service that supports a subset; e.g., just Locate. Blair: SOAP 1.2: HTTP 405 # "excessuve overhead" of 4-corner Daniel: Four corner model is one XKMS responder calling on another. You only talk with your server with whom you have trust. Joseph: The client only needs to interact with one service. Stv: Requirement is just that we should not preclude this. Must not require one big database for the Internet. How this affects the protocol depends on the protocol. Stv: Ruling out redirect requests? HTTP-level redirect? Does this interact with SOAP routing? Blair: SOAP routing doesn't involve HTTP redirect. Joseph: I just talk with one guy; if there's a low-level redirect I'm still dealing with one guy. Stv: Key info the client sends up has hints; up to server to find what's authoritative. Daniel: Want to bind the URI of the third party's XKMS service in the KeyInfo. Blair: Spec says it is a simple request/response protocol. KeyInfo is extensible to accomodate transporting the XKMS service URI. Daniel: RetrievalMethod is fine. Blair: Give a paragraph on a RetrievalMethod that meets your needs. If you need a new Type, then we may need to choose to define that Type. Stv: That's not req, that's spec. # SHOULD in reqs? Yassir: SHOULD -> MUST Stv: Doesn't really matter. # ? explain relationship to traditional PKI Stv: Should we have some text saying when we think our spec is more appropriate to use than the PKIX protocols. Shivaram: I've heard this question asked. Joseph: Wouldn't mind it. Blair: Didn't we have motivational words. Stv: That's not applicability. Blair: How can we be more clear? We can't say PKIX isn't good for situation X, Y & Z. Fred: Simple clients, etc. Could be a simple statement. Yassir: No DVP protocol in PKIX yet. Shiv: Highlight what PKIX is and OCSP is, leave judgment call to user. Stv: Can't really summarize PKIX. Jo: Resolved issues should have link to email which describes our conclusion. Yassir: What is the next step? Jo: When eds done, published as a note. Next step is a note; no rush on it. ============================ Phill: [slides] cosmetic changes schema changes: no model groups / substitution groups Stv: Concerned with lack of clarity resulting from abstract types in document discussion. Editorial rather than schema changes. Phill: Represent prevents request replay attack, DoS. Two-phase request: First present prototype of request. Then you have to prove who you are by sending me the message again with a cookie in it. Used in IPSEC. Stv: IPR issue. Think owned by RSA. Patent may not be relevant, but is RAND. See IETF patent declarations IPSEC properties. Phill: Drop it if covered. Blair: There are other mechanisms we can use if it is covered. Yassir: Would prefer it in XML Protocol. Should be in there. Blair: XP hasn't dealt with this issue yet. Jo: To make it clean, use separate namespaces for different parts. Phill: Protect against response replay with hash (unauthenticated) or ID (authenticated). Phill: Could all become WS-Secure Conversation. Phill: Should we use URIs for UseKeyWith or Any? Need at least two URIs; original single URI was looking overloaded. Phill: Could use UseKeyWith IdentrusV4 perhaps; trust selector. Stv: Doesn't this contradict the slippery slope? Phill: Could be trust selector; we say it is a 'protocol' and what you do with it is up to you. Don't want to have to engineer it so it cannot be used for trust selector. Blair: If looking for six email keys, do I make six requests? If I need to find a set of keys, right now the only way is multiple round trips. The more I think about it, the more I think that people will want multiple locates in a single round trip. Easy to extend what we have to do this. Right now we say that we can't. Phill: Problem is that you have to match each subcomponent of the request to each subcomponent of the response. Blair: We already have that problem. If I can form a request with a partial key name then I get a bunch of responses anyway. Phill: Say you have Alice Bob and Carol, request is for those three keys; responder returns 6 keys for Alice, 3 for Bob, 4 for Carol, need to separate them. Jo: Multiple key infos. Blair: I have to be able to filter responses anyway; I can't use a random key blindly. Phill: Slightly different to Joseph's point of multiple key infos; different keys are in different key infos. Blair: XBulk not necessarily right; I just want it for locate. SOAP can't hold multiple bodies. Phill: Want to be able to return result out of order. Stv: Complex client. Blair: It is a common problem; email systems, broadcast messaging. Phill: There's a difference between 3 key bindings for Alice and a mix of them for different people. Blair: If it looks like multiple requests and multiple responses it doesn't solve the problem. Stv: How about group names? Blair: I don't expect XKMS servers to expand email distribution lists. Other ways to get the members; now I want their keys. Stv: Logic for separating XBULK is that most clients don't want it. Is it the same case hear? Blair: Large number of apps that would use this. Small tweak. Do others agree this is worth adding? Shivaram: I think we should. Stv: Yes as long as it doesn't add much complexity. If complex, then separate document. Blair: If it's not simple I'm against doing it. But we need to set limits in the protocol. Don't want to negotiate limits or have arbitrary impl-specific limits. Jo: Concern - why locate but not validate? Not keen to see the two diverge. Complexity problem. But I'll look at what you propose. Blair: Issues aren't really complexity, but how to limit its abuse. Will submit to list. Phill: URIs (incl fragments) or QNames? Jo: URIs are good but ugly, long. QNames are used by SOAP but I don't like their inconsistent use across specifications. Dangerous with dsig. Is the important but the string or the expanded string? Prefixes can be rewritten which break the expanded string. URIs are safer, but long. Phill: Can't trust input document; all you can trust is what went through the digest. Stv: What's the threat in XKMS? Blair: If the server and client don't agree, you just won't get a response. Yassir: Why QNames rather than strings? Phill: "Extensibility." Jo: Happy to stick with QNames until we hear otherwise. Phill: Table it until the architecture group respond. Phill: XBulk should be separate; it will be embedded in non-changeable systems. Jo: Versioning. Version numbers should be informative. If the schema is changed incompatibly then the namespace MUST change. Changes to syntax OR behaviour require a new namespace. New algorithms, for example, are okay with the old namespace. Phill: Can't have incremental backwards compatible changes with namespaces. Jo: Can if your new types/whatever are identified by URI/QName. Blair: XML protocol supports versioning based on namespaces. Stv: Religiously, major/minor might cause us problems on the standards process. Phill: Get rid of major/minor. Jo/Stv/Phill/Merlin/Blair: Locate doesn't support lookup of UseKeyWith. Should Locate and Validate have the same syntax? Jo: Should they be the same request, where 'TrustStatus' is another part of the query. Stv/Phill/Vlair: Validate is very different from locate. Jo: Is there anything in this document that makes Locate and Validate different? Stv: Could have a bit in the request that says locate or validate, or could locate them separately in WSDL. Jo: What does valid mean? Does each of PGP, SPKI have a different concept of valid? Daniel: What's the point of Locate returning invalid data? Stv: Do you blame a directory for returning an invalid cert? Jo: I'd like to know what valid means and I'd like it syntactically specified. I'd like to see a concrete definition of validate. Stv: Assume they are syntactically equivalent. Is it worth having two operations or just one? Jo: I want to ask some statements; e.g., KeyName and ValidityInterval and get just those answers. Fred: What's validated in this case? Jo: I don't know what you mean by valid? Fred: When can you use the information reliably? Jo: It should never return information that it doesn't think is true. Blair: Disagree. Directory doesn't validate information. Stv: Do we have two operations or a field? Phill: Advantage to separate operations is WSDL advertising. Blair: You are giving me status information, and what you know as of when you processed this request. Stv: Further semantic difference: If I break into a locate responder I don't damage system security; if I break into a validate responder I break the security of the system. Clients don't rely on locates. Joe: Why would I take keys that are not necessarily valid? TinPolk: Client-side validation. I want a service to give me the information from which I can make a decision. Daniel: It seems like just a clearer way of identifying the returned information. Phill: Locate must be in there; otherwise it won't help the end to end model (client-side validation). Jo: Want a clear definition of valid and invalid in the spec. See my Request/sql:Query request; equivalent to a Validate request. Blair: You can express locate and validate in that form. Then the service must parse these things and intuits whether it is answerable by the lightweight responder or the heavyweight PKI infrastructure. Harder to build and segregate. Stv: If I'm using LDAP to store keys it could be reasonable to do a fuzzy locate match that returns multiple keys. Not reasonable to validate this. This syntax could result in questions that cannot be answered. Daniel: XKMS service not required to implement validate? Stv: Must implement; need not deploy. Jo: I just want clear definitions in the spec. Stv: Upshot is that it looks like Locate and Validate make sense but need to be better defined. Blair: Do people think Locate should also optionally return some of the KeyBinding things. Stv: The more similar they are, the more I can share implementation. I'd like them to be as close as possible. Blair: Use KeyBinding but clarify field usage. Jo: Give me the answer according to policy foo. Stv: Cutting down developer choices a good thing. Blair: Services will have a policy and apps will use services that match that assurance levels; they won't request a policy. Daniel: SQL a good analogy, but not necessatily the way we want to go. Phill: Want to force the client to do validation with Locate. Stv: Repeat; Locate and Validate different. Syntactic similarities exist. We need better definitions. ACTION: Phill write the definitions. Jo: Valid/invalid used throughout the text. Jo: The KeyBinding is not extensible; what if I want to query or return different trust semantics than those provided by XKMS. Stv: XKMS is about managing keys. How much more do we want to stick in. New key info types can go into XKMS. Joe: Everything in KeyInfo is about a key. That may not be sufficient for everything. Anything in the KeyBinding is about a key. We should have an ANY in there. Stv: Highly logical. Blair: Would be nice to have a good model in there. Should ValidityInterval be in KeyInfo or KeyBinding? Stv: What's unique about a KeyBinding; we weren't sure. Yassir: KeyBinding has a Status. If we don't want to stuff the KeyInfo we should ANY on the KeyBinding. E.g., trust anchor. Fred: Might associate some contact information? Jo: Three levels of statements. The key, statements about the key, statements about the statements about the key. Stv: Broadly accept extensibility of KeyBinding. Jo: Valid/Invalid/Indeterminate extensibility? In order to keep same syntax. If it was a URI I could say valid under this trust policy. Stv: Resist tagging trust policies with every piece of info. Phill: XTAML. Yassir: Reundant; valid under policy of the service you're using. Stv: No 50% valid; no consensus for other. Joe: Request Status=Invalid Phill: Tenuous; query Status=Invalid => get information about why. Stv: May be easiest for consistency. Syntactic/style. Yassir: I think ValidateRequest should not be syntactically the same as ValidateRespones. Many things make no sense; Status, Valid, Passphrase. Stv: Just an artifact. Yassir: I'd like a more clear ValidateRequest, etc. Phill: Core KeyBinding, ResponseKeyBinding. Blair: Originally had few types, reused things. Those are now looking funky. Let us refactor it. Daniel: Joe's suggestion makes even more sense. Joe: Invalid with ValidityInterval means only known invalid during that period; check again after. Phill: Fully specified in new spec. Joe: In bit about ValidityInterval, replace unspecified with omitted. Blair: Can have multiple KeyBindings returned, one Valid the other Invalid, if request covers a validity change period. Stv: Change Request to have ValidityInstant, not Interval. Yassir: Reason-code Status is unclear. Blair: Are these codes generic enough; we should define these codes for non-X.509 systems, etc. Stv: These status codes will mean nothing to a user. Stv: The time when a key turned invalid is useful for the client. Fred: Issuer trust implicit in the policy. That reason doesn't need to be explicit; it should be implicit. Phill: Maybe they are only useful for Invalid, and maybe they aren't the right values. Blair: Let us come up with a better way to express this information. Yassir: Can we get rid of reason? Stv: InvalidSince might be useful. Blair: Let us think what we're trying to communicate. Stv: Take it up on list. Shivaram: We should remove affirmitavely on 'the trust service has affirmitively verified'. Yassir: [ Confusion over reason code Signature ] Yassir: Result code questions from the list. Phill: New result code framework. Yassir: Describe result codes for different operations; reintroduce some of the original text. Yassir: Why is non-extensible KeyUsage a QName. Jo: I like that. Stv: We really don't want people to add NonRepudiation. Offers to buy beer. Phill: Move to think Joseph suggested; choice enumeration or QName. Stv: Add text saying no other usages; be explicit. Yassir: KeyBindingType ?Key?Id Phill: Allows you to lookup and then revoke. Yassir: ProcessInfo; want example and text. Stv: Bilateral client/server extension. See also ClientInfo. The only reason it is not an XML any is that it is different from ClientInfo. Shivaram: Action Items on site. Yassir: Will take stab at refactoring KeyBindingType, etc. Conf call in June; try and have lots of maillist work ASAP.