Subject: [jose] Appendix D in draft -20

From: "Jim Schaad" <[email-masked]>
Date: Thu, 23 Jan 2014 12:40:57 -0800

I am only marginally happier with this draft of the document.

I do not see how one can possibly state that steps 1, 3 and 4 are in any way
optional in this algorithm.  The concept of not gathering keys, filtering
out keys that cannot possibly be correct and not checking the signature of
keys makes absolutely no sense to me.  If these steps are to be considered
optional then the reason for them being option must be clearly documented.

My understanding of x5u says that only a single key referenced by the chain
would be eligible for inclusion in the key set.  If this is not true then it
needs to clarified in the description of x5u.  If it is true then
s/keys/key/ in that description.

I need to have a much better understanding of the statement that you can
order based on the value of the kty value.  As it stands I have no idea what
this means and why one would do such an ordering.

I would probably swap steps 2 and 3 so that one can order with respect to
those keys which are reasonable to look at rather than looking at the entire
building of keys.  As part of this I would move the number of keys from
current step 3 to step 4.

If you are going to make the statement "Keys with inappropriate "alg"
(algorithm), "use" (public key       use), or "key_ops" (key operations)
values would likewise       typically be excluded." Then you need to provide
text to tell me under what circumstances I would not be excluding them.  My
understanding is that they would always be excluded and thus this text makes
no sense to me.
 
I would move the kty filter into the previous sentence.  It them make sense
to talk about applications filtering based on other values that might be
more application specific.
 
I would like to see the trust statement moved to a separate item in the list
of steps.  Again this is something that needs to be done, but it can be done
after step 4 rather than in the filter process.  The trust statement can be
made to be more general that what is current stated.  That is the trust
decision may be made based on internal application information, generic
information or an external certificate validation process.  In some cases
the trust decision may be determined to be implicit based on the source of
the key.    I would make this general rather than specific.  That is to say
I would say that a binding of trust needs to be made, and the following
items should be considered in the list of things to be included.  This
should not and would not be presented as an exhaustive list but should be
somewhat complete.  That is getting this from a jku has a degree of trust
that a jkw does not have.
 
Jim