JR: Noted that there is an overlap between requirements and design; some
requirements are design.
JR: MUST there be support for SOAP 1.1 & XMLP?
FH: Only SOAP initially, XMLP will not be in timeframe.
SF: Add XMLP when it is ready; only SOAP for now.
SF: Should signing be transport agnostic or use SOAP signature?
FH: SOAP signature won't be in timeframe, don't want to second-guess it,
so we must be transport agnostic.
SM: Is PKI agnosticism for the client or the server?
FH: For the client; the server can do what it wants, may rely on PK.
Don't frame the spec in X.509 but be able to support it.
PHB: The only interesting infrastructures are X.509 and forwarding XKMS
but we must support PGP and others to be friendly to such folks.
SF: Don't leak X.509 into XKMS.
SF: Current reqs mention symmetric key support; is that necessary in first
draft; e.g., kerberos, etc? Do we support now or think about later?
BD: Defer. Whole set of issues WRT kerberos.
SF: We don't want to specify in detail how to send kerberos ticket up?
PHB: Don't want to preclude it.
SF: So we'll defer it.
PHB: Put in words that we will not consider risk model or security
implications of symmetric keys.
BD: Agrees.
PHB: [Something about tennis balls and chainsaws.] Not _not_ a useful
thing, but for TNG.
SF: Make requirements clear that we are managing public keys.
[ General agreement ]
JR: In current requirements [which transpired to be an ambiguous
specification] we should strike latter part of section 2.1.4.
[ Other comments were inaccessible, would be made on-list to
updated requirements doc. ]
SM: It is not clear whether client-specific or server-specific
requirements are separated in the current design document.
MJ: For example, some respond values don't apply to the client
or the server. So we need the distinction in the spec.
BD: Need to state that we keep interactions simple for clients;
i.e., all interactions are client-inititiated; one request, one
response; no session management.
SF: Do we have a consensus on confidentiality requirements? We may require
that the protocol run over SSL/TLS, but what XKMS fields d we want
confidential?
BD: The entire payload.
MJ: Or private keys.
PHB: Private keys must be encrypted, even if SSL is in use.
SDF: That aside?
BD: If the user has any confidentiality concerns, everything should be
secured.
SF: Aside from private keys, there is no requirement for selective
field confidentiality.
[ General agreement ]
SF: If someone sends an encrypted request, do we mandate an encrypted
response?
BD: Keep it simple. It is a server-speccified option, related to the
server's policy; out of scope for XKMS.
FH: Two trust issues; one is policy: what server does; two is how to trust
server.
SF: No negotiations; see list.
BD: XKMS should not define how to decide initial trust. Low value systems
will use SSL. Service builders will define the trust model of high value
systems.
SF: Client implementations will each define how this is set up; we could
say that all clients must accept the certificate r key of the service in a
KeyInfo?
BD: Yes.
PHB: See XTAML. A complex issue; let us defer until there is a full
solution, not come up with a half-baked solution.
SF: Does this contradict that all clients must accept certain format keys?
FH: Does this add complexity to clients?
BD: All clients must be able to handle KeyInfo.
FH: Client may not understand KeyInfo.
SF: Must have _an_ out of band way to accept key to trust service.
PHB: Not a MUST requirement to plug in an external root; some clients will
have no reason to isntall a different root.
SF: Do we require that either you bake in a root or can accept a trusted key in
some standard format?
PHB: If you are an XKMS responder then you MUST publish your key in some
format; KeyValue. A Server specific requirement; no onus on client.
SF: Just KeyValue?
BD: That's the minimum.
SF: Do we require that clients support responder key-changes?
BD: Hard question; maybe just insert text in the document warning that
this happens.
[ General agreement ]
PHB: See XTAML.
SF: There's the general issue of maintaining KeyInfo and extending it; for
example, P10 is required.
PHB: Joseph, how do we do this?
JR: In the working group.
SF: Maintain a central registry?
JR: KeyInfo was supposed to be simple and was forced into xmldsig; in
time maybe we'll refactor it all. Until then, leave it open; let different
specs define their own extensions as needed. Namespaces will prevent
conflicts.
misc: [ General problem of multiple definitions of new key info elements;
discussion petered out. ]
JR: Aside: XKMS is like a database lookup.
PHB: Not a database lookup, just a directory lookup.
BD: [something on slide, TBD] is out of scope. We are not
reexpressing/resyntaxing other standards - e.g., PKIX - in XML.
SF: What is an assertion? What requirements of atomicity do we have? [
Decided this is for spec, not req ].
SF: Are we sticking with numbered "tiers"?
[ General agreement to drop them and just use names ]
SF: Are chaining and referals a requirement for this revision?
BD: Let us stick with what we have; thgey can be hidden by the server. The
client just sees one server.
PHB: this will be covered later.
PHB: WRT roaming, we don't want to clash with SACRED & IP issues.
FH: The slide just says tghat there is more than one reason to get the
private key from the serve.r
PHB: We may address roaming but may not.
MJ: Aside: Are the requirements just for XKMS 2.0 or are they also for
future revisions of XKMS?
BD: We must amend the charter later for > 2.0 and then updated
requirements; i.e., requirements are just for 2.0
SF: Do we have a concrete requirement for proof of possession of
encryption keys?
PHB: RSA & DSA are the majority of keys we will be working with; there is
nothing _wrong_ with using RSA encryption keys for a digital signature
in POP.
SF: If others; e.g., DH, need support in XKMS they can write their own
document that extends POP for their needs.
SF: Does this mean an IPSEC client couldn't use XKMS?
[ No? ]
SF: Baseline 2.0 clients don't need to support fancy proof of possession
mechanisms for encryption keys; we will just use signing, even for RSA
encryption keys.
PHB: Element maxOccurs is unbounded in the schema, but a certain server may only support, e.g., 10000 responses; not possible to QA a server for infinite responses. SF: How does a client specify multiple responses wanted, but no more than 60? PHB: We should add an attribute stating max responses. SF: We need a requirement that the spec needs to tie down schema cardinalities whenever they are non-one. BD: NO paged made of respones (e.g., ask for 1-10, then 11-20...) SF: WRT template mode, we don't want any complex parameters? PHB: A template may be unnecessary; the service will know. SF: Some vendors have expressed a desire for it. [ Discussion of retrieving just CRLs; agreemenet that this is not supported without locating a certificate. ] SF: WRT separating services: Locate service sometimes needed for encryption (e.g., retrieving SMIME encryption key); validate service not required in this context. BD: Locate is similar to a directory lookup. Do we need a KeyName[Guess|Part] KeyInfo element? SF: May be useful for laxly locating by name; e.g., sfarrell vs [email protected]. PHB: We could describe in detail how SMIME uses XKMS. SF: Put this in a separate application node. PHB: Want to be able to use XKMS for SMIME key retrieval. SF: Locate can be lax; validate must be strict (e.g., check email address is in certificate). SF: Must straighten up KeyName and KeyID. Will come back to this. PHB: KeyName =~ subject; KeyID =~ URI. SF: What is ValidityPeriod: When the key expires or the response expires? BD: Look at the server policy. Validity is server-dependent. SF: At minimum, outside this period "come back to me". PHB: SMIME requires historical validity. SF: Some sense in having duration associated with validate response but do we _need_ this? Can you just make this out of band in server policy. 90% of clients don't check old signatures. FH: As signatures gain acceptance, historical checking will become more important. SF: Rat hole. Could be an extension to ask for historical checks and drop ValidityInterval from base XKMS. [ No objections ] PHB: All register components are advisory; the server can override any of them. BD: We need words about certificate validity periods, bindings, etc. in the spec.
PHB: Reasonable to say a service MUST support TLS, but not a client.
FH: Nontransient signing will be useful for archiving.
PHB: Don't require non-repudiation.
SF: Move on.
SF: Handling of pending in X BULK is easy; there are different reasons
than XKMS. In XBULK it is the time to process; in XKMS, it may be related
to administrative approval. If a register receives a pending response, how
long before recheck? What about locates during this pending period?
PHB: If the register is not processed, locate doesn't see it. If the
register is processed but the client has not got it, it _is_ registered.
The client may not need to know that it has been processed before other
clients can see it. So locates and validates work as soon as it is
processed.
MH: What if I request an update, this goes pending, the update is
done and others start to use it; I don't yet have the decryption key?
BD: You must get it.
PHB: A pending response needs an indication of the order of magnitude of
when to recheck.
SF: Client behaviour must be specified. If a client gets a pending, how
does he later complete the operation? Validate or register? How to abort?
PHB: Transaction ID. Should we support asynchronous response on all
operations? Validate won't work to download the private key of pended
server-generated key registration. We could look in the request structure
for a flag to say this is a repeasted request by matching transaction ID;
or, better, use a server-generated ticket.
BD: All operations must be client initiated.
SF: If I register a key name and get a binding with a new key name, does
the client forget its proposed name?
PHB: All is advisory.
SF: Does the server support the original proposed key name? E.g., for
locate?
PHB: No.
SF: The problem being SMIME needing to know your _real_ name.
BD: Gets back to a fuzzy match.
SF: Could register many aliases for use in locate; the response is only
canonical for validate.
BD: Slippery slope. Don't solve the universal naming problem. If you don't
register a unique name it won't work.
SF: Clients must expect key name changes. Want to avoid SMIME problem of
needing a signed message before being able to encrypt.
[ General murmurs to move on ]
MJ: Pending not needed for locate/validate; synchronous only.
PHB: Many schema changes; some people say we are confused; not using some
schema features. Two approaches; backwards compatible with old version or
reorganize. We changed register, so lets change everything we need
changed.
SF: Not compatible with XKMS 1.1 but not egregiously incompatible.
PHB: No SAML compatibility nor dependency; different schemas.
SF: May adopt some similar style.
MJ: Should the client pass a requested role to the service or does the
client choose a URL to choose a service.
SF: Client picks URL.
PHB: Extension. Client is not micromanaging service, it is offloading "do
the right thing" to the service.
MJ: All optional items need a good case for them.
PHB: Optionality in what service can deliver is _not_ up to client.
SF: This is clear on the list.
FH: Use of SOAP faults is unnecessary linkage. Use of SOAP integrity is
unnecessary linkage.
SF: Some discussion on SAML list.
BD: SOAP fault when can't generate XKMS response. Distinct from XKMS error
conditions (successful response).
FH: Not clear in draft; should clear up.
BD: Agree; we are specifying messages as SOAP payloads. Should REQUIRE
SOAP usage in 2.0, but be transport independent.
SF: For XKMS 2.0 all messages are SOAP envelope/body/payload.
MN: SOAP security or our signatures?
BD: No referencable SOAP signature.
SF: Want to do something "like" final SOAP signature.
BD: Multiple encoding options in SOAP under body. Do we do an RPC SOAP
encoding of XKMS or require document literal. Probable security problems
with RPC; dsig is not compatible.
MJ: Must address replay, etc. SF: Is there a requirement for XKMS clients to support roaming; client pulling down private key regularly, as SACRED. PHB: Have to support ability to register a key that will be roamed; maybe as extension of register; e.g., FordKaliskyRSAKeyType. SF: Server generated keys is not roaming; it is one-time download. Is it a requirement to support repeated download of private key? MJ: Neither doing our own nor referencing others are possible within our timeframe. PHB: We generate keypair at server-generated register time; this is not roaming. SF: Strong password protocol required for frequent key downloads. FH: Doing it insecurely not worthwhile. [ General consensus: not to do roaming (unfortunately) ] MN: Current charter mentions SACRED. Should not be incompatible. SF: Is chaining in scope for 2.0. The client will be unaware, but will a standard XKMS client implementation work in a responder. PHB: Need protection against livelock and deadlock. Do we make this a SOAP routing issue or XMLP? BD: Let us not think about it. SF: Would like four corner model to work; do we need to think about it; are there any issues? BD: Let us not look at liability and forwarding policy issues of four corner model. SF: Agreed; we just want the scenario to work. [ General consensus ] BD: Think it should work; there is no client identifier in the request so chaining should work without problem. SF: Maybe a response flag if authoritative or not. BD: > 2.0; maybe an extension. See service policy. SF: KeyId and KeyName meaning in protocol; why the two? JR: Does RetrievalMethod work? It is slightly different. PHB: KeyID is how I can use the key. Need to bind a key to a protocol identifier and port; not just a person. SF: Then why do we need a person? JR: Can we look in the KeyInfo structure for PGP or X.509 data to determine whether PGP or SMIME for mailto? SF: No; X.509 can be used in PGP. BD: this is not like KeyID or KeyName. SF: Which is the database primary key? JR: Do we need a protocol binding? PHB: yes. BD: Originally expected a usage context list; e.g., UseKeyFor or UseKeyWith (SMIME vX & [email protected]); not the confusing KeyID/KeyName that we wound up with. PHB: It originally was as above, but this was taken out. SF: Will key name be primary key? PHB: Yes. SF: What flavour of key name; what messages does it appear in and where? [ Consensus to defer ] SF: If I register for foo, can it be used for bar? Exclusive or inclusive? BD: Can't stop clients from doing what they want. MJ: UseKeyWith allows you to pick among credentials. PHB: Don't be overly restrictive; just an advisory hint. SF: So KeyName is it; KeyID will go, and UseKeyWith will be added in an advisory role. PHB: When you register a key for [email protected] it has meaning. SF: Is KeyName opaque or not? PHB: No this is the UseKeyWith. BD: Why can't the server just copy UseKeyWith around unchanged, without comprehension? SF: How does the client ask for a key for an email address? PHB: Define URI formats so we can have meaning. SF: Isn't this aliasing in a protocol-specific way? So, KeyName is unstructure, UseKeyWith is structured. MH: Then UseKeyWith is a structured alias for an unstructured unique KeyName? PHB: Yesish. UseKeyWith must be authenticated by the server for meaningful validation purposes. JR: Are queries conjunctive or disjunctive? BD: Conjunctive; AND. SF: Are multiple contents of KeyInfo AND or OR? BD: Unsure. SF: Not trying to solve general secure database lookup. JR: It is critical to define the meaning of queries. SF: These aren't mutually exclusive. JR: Look at secure database queries. FH: Are strings okay [ for Respond, etc. ] or do we want namespace-qualified names (or URIs)? PHB: Strings now for legibility of a closed set. Let us specify that relative URIs are in a standard namespace. [ Consensus to work on requirement doc updates now and then request comments on it. ]
PHB: XKMS 1.2 or 2.0?
[ Consensus 2.0 ]
PHB: Client can never be required to ask a question; no negotiation.
SF: Criticality problem? If client asks for A, B, C what does server do if
it does not know C?
PHB: It does A, B. Service ignores unknowns.
SF: Do we need to distinguish between I don't do SPKI and there is no SPKI
information?
PHB: Don't think so. Client just gets nothing.
PHB: WSDL is at the method leverl; e.g., I do register and revoke but not
recover.
SF: So WSDL doesn't advertise that I do X.509 but not PGP; see policy
instead.
BD: RPC or document literal encoidng in SOAP?
SF: Blair, can you mail a bit of info on the RPC encoding to the list?
PHB: Reference to dsig may preclude RPC.
PHB: Do we separate user register message from server register message?
SF: May be a reason; issue came up before.
PHB: Plus it would clear up AuthServerInfo vs AuthUserInfo.
SF: Will average client want both?
BD: Yes; sign and encrypt.
SF: Suggests that we don't split register user from register server.
SF: What is a unique key binding? How do I revoke?
MJ: If I reissue a binding, what do I sign with?
SF: If I revoke a key, do all bindings with that key get revoked?
[ Consensus to punt to list. ]
PHB: Be clear about revoke: assertion or key? Revoke as much as is
specified? E.g., revoke just a key revokes all instances? Revoke key plus
name revokes just that bindingg?
PHB: Must include service URL (trust model) in response.
SF: We have SSL and payload security; what about none?
BD: Yes; trusted intranet.
PHB: Service MUST support SSL. Service MUST support no security. Service
SHOULD support payload security. Client MUST support SSL or no security.
Client SHOULD support payload security.
SF: There are arguments for not doing our own SOAP header for payload
security; overlaps with WS-security. So do we do payload security in our
own body element?
[ General agreement. ]
MJ: Digest of request always needed in response for security; not only if
the response is authenticated.
PHB: Responder may not know on what URI the client request came in on?
SF: Every response MUST include service URI and request digest.
[ General agreement. ]
SF: Does anyone think we need more than namespace for versioning?
[ No. ]
JR: So lose the version in the Respond element.
PHB: What about a schema update that just adds to the schema; this can be
done without a namespace change?
JR: Namespaces are sufficient.
[ General agreement for use of namespace for versioning. ]
SF: Phill, what about timing?
PHB: New version of document mid to late January.