|
Issue #
|
Question/Issue
|
|
1.1
|
ResultAbstractType
is missing a Not-Implemented error status.
|
|
1.2
|
ResultAbstractType is missing a place for a detailed
error message.
|
|
1.5
|
In case of XKMS implemented on top of X.509-based
PKI, what should Id attribute in a KeyBinding map to? Should specify if
it is to be certificate serial number. See also question 2.29 below
|
|
1.6
|
In UseKeyWith, SSL/SMTP is a dnsname and SSL/HTTP
is a URI. However only dnsname is looked at for SSL. In other words, only
one key and one certificate chain is being returned by a server for all
SSL connection made on the same port. Moreover, SSL handshake happens before
server even knows which URL is being requested. Therefore binding a key
to an HTTP URL more specific than host:port is not really useful. Also
the distinction between SSL for SMTP and SSL for HTTP seems excessive since
SSL is really bound to the underlying TCP endpoint
|
|
1.7
|
Section 2.8.9.1, ResultMinor codes table, for ResultMinor=Failure,
the possible ResultMajor codes should be Sender and Receiver instead
of Success and Receiver.
|
|
1.8
|
Section 2.8.9.1, ResultMinor codes table, for ResultMinor=Refused,
the possible ResultMajor codes should be Sender and Receiver, instead
of Success and Receiver.
|
|
1.9
|
When should a server returnResultMajor=Receiver,
ResultMinor=TooManyResponses
(server returned no responses) ? or ResultMajor=Success, ResultMinor=TooManyResponses (server returned some responses) ? |
|
1.10
|
What is the difference between ResultMajor=Success,
ResultMinor=TooManyResponses (server returned some responses) and ResultMajor=Success,
ResultMinor=Incomplete (only part of the information requested could be
provided) ?
|
|
1.13
|
When should service URI be used to specify a policy
versus policy identifier in a KeyBindingAbstractType? Spec should clarify
or remove one.
|
|
1.14
|
Is there a relation between Policy Identifiers and
Policy Object Identifiers in the policy constraints extension of X509 ?
If so, is there a standard format for encoding a list of policy OIDs as
anyURI ?
|
|
1.16
|
Section 2.8.4,
under PendingNotification, the last sentence should say “If the <PendingNotification>
element is present the value ‘Asnychrounous’ MUST be specified in the
ResponseMechanim.
(the value pending is removed from RespondWith items 10/23 spec) |
|
1.17
|
Section 3.3.1, [123] last sentence, “priori some
means” should be “prior means”.
|
|
1.18
|
Section 4.1, [130] “XKMS specifies three elements”
should be “four elements”
|
|
1.19
|
What should be done with a KeyBinding ID if it is
specified in a request ?See also
question 2.29 below
|
|
1.20
|
Section 4.1.6 [148]
<!--LocateKeyBinding--> should be <!--UnverifiedKeybinding--> |
|
1.23
|
[67]
Why have <OpaqueClientData> which is an unbounded sequence of <OpaqueData>
rather than just single <OpaqueData>. How is this having sequence of
opaque data blobs is better than a single opaque data blob?
|
|
1.24
|
Editorial:
[71] Table has <ds:Keyinfo>Element
column which is empty and not applicable
|
|
Issue #
|
Question/Issue
|
|
2.1
|
In a ValidateRequest more than one key can be specified
in KeyInfo but with the same KeyUsage, UseKeyWith and PolicyIdentifiers.
Does it make sense to allow more than one key in KeyInfo ? Should spec
specify that there should only be one ?
|
|
2.2
|
Provide guidelines for how to map KeyUsage, UseKeyWith
and PolicyIdentifier to extensions in x509 certs for Locate and Validate.
|
|
2.4
|
For implementations on top of x509, if server found
more than one cert that matched the KeyUsage, UseKeyWith and PolicyIdentifiers
in a ValidateRequest should multiple assertions be returned ? or should
this be an error ?
|
|
2.20
|
Consider <QueryKeyBinding> with multiple <UseKeyWith>
elements. What is the interpretation for matching:
Is this interpretation different for Locate and
Validate requests ?
|
|
2.21
|
Example 3.1.1 is of dubious value:
If Locate response is not trusted, why would one want to use it to encrypt one’s message. Using Validate for the example seems more logical. |
|
2.22
|
Example 3.1.2 is of dubious value:
If Locate service is not trusted, how does one know if the key value returned actually matches the certificate in the request. Using Validate for the example seems more logical |
|
2.23
|
Editorial: [116] “has a valid validity interval”
should be rephrased
|
|
2.24
|
[119] seems pretty vague and ambiguous.
|
|
2.25
|
[120] Locate service is only useful to collect the
information which then will have to be validated by other means:
In case 1 if app can deal with X.509 PKI directly
why mix XKMS and X.509 ?
In case 2 why not issue Validate directly instead of using Locate/Validate combination ? |
|
2.26
|
[124] Since DNS is not a trusted source, how does
one establish trust in Validate Service whose location is retrieved from
DNS? Two possible answers:
In case 1 one has local configuration entry for
the XKMS service which needs to be indexed on some service attribute. DNS
name seems like the right attribute for this and therefore external XKMS-specific
DNS lookup does not seem necessary.
In case 2 we would need to introduce XKMS as one of the protocols for <UseKeyWith> and use trusted Validate service to retrieve trusted binding between service info returned by DNS and its key. In this case one could have used the Validate service directly without intermediate DNS lookup |
|
2.27
|
Editorial: [117] Request asks for <KeyName>,
response contains just X509Data. This seems inconsistent and unintentional
|
|
2.28
|
[129] Requirement “Service
represents to the client accessing the service and to that client alone”
needs to be explained a little more and, perhaps, justified. Does it mean
that the response can not be transferred to another entity for later verification?
What is the rationale behind this ? Does it constraint our ability to create
verifiable audit trails of the XKMS interactions ?
|
|
2.29
|
[132] What is the scope/lifetime of KeyBinding ID
? Potential options:
Some other more specific questions related to this
are below
|
|
2.30
|
[132][136][137] What are the matching rules between
<QueryKeyBinding> and target <KeyBinding> when multiple <UseKeyWith>
or <PolicyIdentifier>or <KeyUsage>
are used ?“ANY”, “EXACT”, “SUPERSET”
? Explicit description for the general case is needed
|
|
2.31
|
[150] <Status> must not be Optional in <KeyBinding>
|
|
2.32
|
[162] StatusValue must not be optional
|
|
2.33
|
Editorial: 4.1.8 should be moved up to be before
4.1.7
|
|
2.34
|
Editorial: Should 4.1.13 be moved to XKRSS section
?
|
|
2.35
|
[129][205] What is <KeyID> or <ds:KeyID ?
I can not seem to find the definition anywhere
|
|
2.36
|
Editorial: [208] Reference to Locate operation should
be replaced with Validate operation
|
|
Issue #
|
Question/Issue
|
|
3.1
|
In section 6 on KRSS, more explanation should be
provided for each schema.
|
|
3.2
|
In section on KeyBindingAuthentication, provide
more explanation and an example of a shared secret used in keyBindingAuthentication.
|
|
3.3
|
In section on RegisterRequest, provide an example
that is does not assume underlying x509.
|
|
3.4
|
PassPhraseAuthentication is defined in the schema
in the appendix but not used/mentioned anywhere.
|
|
3.5
|
Why is the signature for KeyBindingAuthentication
applied over PrototypeKeyBinding versus the whole message or something
else ? See also question 3.35 below.
|
|
3.6
|
What should a privateKey be encrypted with in a
RegisterResult ?
|
|
3.9
|
In RegisterRequest, when
would there be signature over the whole message ? One possibility is that
the message is coming a Registration Authority. See also question 3.35
below.
|
|
3.11
|
Should PrototypeKeyBinding
have a place for x509 extensions ? If not is there a standard place and
format for x509 cert extensions in a RegisterRequest ?
|
|
3.12
|
Can the spec suggest
what to use for keyname for an underlying x509 implementation ?
|
|
3.13
|
RegisterResult is missing
a place for Rejection Reason.
|
|
3.14
|
Should keybinding ID
in a RegisterResult be the cert’s serial number for underlying x509 implementations.
See also 1.5 and 2.29
|
|
3.15
|
Spec should provide recommendations
on how KeyUsage, UseKeyWith, Policy Id, and other elements in PrototypeKeyBinding
should map to X509 certificate fields and extensions.
|
|
3.17
|
In RegisterRequest, if
RetrievalMethod is specified in RespondWith, should server return a URI
to pick up the certificate or get the request status ?
|
|
3.18
|
Should a RegisterRequest
have a validity period in PrototypeKeyBinding? Is this intentional or an
oversight ?
|
|
3.19
|
Shouldthere
be a message for checking (polling) on the status of a pending request
?
|
|
3.20
|
Section 2.0.4, [268],
under explanation of <ds:Signature>, “… over the <KeyBinding> element”
should be “over the <PrototypeKeyBinding> element”
|
|
3.30
|
[227] Status contains <ValidityInterval> reason
in Register response, but no <ValidityInterval> in either Request or
Response. What is the validity period in this example ?
|
|
3.31
|
[235] Is there any relationship between <KeyBinding>
ID attribute and other <KeyBinding> elements ? Must ID be the same one
as returned in previous Register (or earlier Reissue) response ?
Is ID alone sufficient to identify specific <KeyBinding> instance ? See alsoquestion 2.29 |
|
3.32
|
[235] Is key used for <KeyBindingAuthentication>
the same one used in <KeyBinding>. If yes, is it a requirement ? If
no, why there is no <ds:keyInfo> in the <Signature> ?
|
|
3.33
|
[240]Is KeyBinding
ID random or should match the one returned in Register or Reissue ? See
alsoquestion 2.29
|
|
3.34
|
Editorial: [245] The purpose of the sentence “In
this case the code is read over the telephone and so it would be inconvenient
to be required to specify spacing between the code blocks or capitalization”
is unclear.
|
|
3.35
|
[246] Why only KeyBinding is signed and not the
entire request ? Is it for the purpose of forwarding it from one service
to another? So one can then morph intercepted request to another request
type: e.g.,Recovery into Reissue
or Revocation etc. This is a potential security problem
|
|
3.36
|
Editorial: [247]
<Status
StatusValue="Invalid"> <Reason>Signature</Reason> <Reason>IssuerTrust</Reason>
<Reason>RevocationStatus</Reason>
<Reason>ValidityInterval</Reason> </Status> should be replaced with <Status
StatusValue="Invalid"> <ValidReason>Signature</
ValidReason > <ValidReason>IssuerTrust</ValidReason >
<InvalidReason>
RevocationStatus </InvalidReason> <ValidReason> ValidityInterval </ValidReason> </Status> |
|
3.37
|
[273] How does one specify which MAC algorithm is
used ? Is it an implicit agreement between XKMS service and its client
?
|
|
3.38
|
[282] What is the minimal requirements for “identifying”
a key binding in Reissue request:
|
|
3.39
|
[282] Should POP be “required” for Reissue request
? If yes, is authentication necessary ? See also question 3.35
|