Subject: Re: [jose] Text for Issue #77

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 Nov 2013 16:31:05 -0800

Mike pointed out that the premise of the first sentence on my new paragraph
is not true.

Thus I suggest the text read

While there is no requirement that fields other than the public key be
populated when n "x5c" member is present, doing so will improve
interoperability for those applications which do not deal with PKIX
certificates.  If the fields are populated, then the contents of the fields
MUST be consistent with the same field in the certificate.  If the use
member is present, then it needs to allow for only a subset of the usages
that are permitted by the certificate.  Similarly if the 'alg' field is
populated, it should be an element of the set of possible algorithms that
the certificate allows.  All of these fields MUST be populated with data
from the first certificate in the chain.

Sections 3.6 and 3.5 should have the following paragraph added:

Fields other than the public key can also be populated from the certificate,
see the last paragraph in section 3.7 for guidance on this.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim
Schaad
Sent: Thursday, September 26, 2013 10:46 AM
To: Mike Jones
Cc: [email-masked]
Subject: [jose] Text for Issue #77

Mike,

I am not happy with the following sentence in section 3.7 of web-key because
I don't believe that it correct covers the set of issues that need to be
deal with.  I suggest the following change:

Delete the sentence "The key in the first certificate MUST match the bare

   public key represented by other members of the JWK." From the current
paragraph.  This sentence could be replaced with the sentence "The first
certificate MUST be the end user certificate." If you want to keep that
information.  You don't really have that at present, but you do say that it
must be the one that contains the key value.  It is not clear to me that
there would be problem by simply deleting the sentence. 

Add the following as a new paragraph

While there is no requirement that the other fields in a JWK be populated
when an "x5c" member is present, doing so will improve interoperability for
those applications which do not deal with PKIX certificates.  If the fields
are populated, then the contents of the fields MUST be consistent with the
same field in the certificate.   Thus the public keys are required to match,
if the use member is present then it needs to allow for only a subset of the
usages that are permitted by the certificate.  If the fields are populated,
the fields MUST be populated with data from the end user certificate.

Jim