Messages - 4.2 Key usage should refrence RFC2459

[hideki nara]

keyEncipherment must be X.509 key usage bit.
I think that it should be described with more word and referred to RFC.

[John Bradley]

X.509 processing is a optional deployment choice.

X509 key usage extensions for signing and encryption are almost never used. Usage is almost always described at a higher level like SAML meta-data.

In our case the usage is specified by providing specific raw keys or certificates for each use.

My recommendation is to not recomend certificate validation processing as that would preclude self signed certificates and cause more interoperability problems with expiration dates.

For Connect certificates are just containers for keys, unless a deployment creates it's own profile for some different trust model.

I don't quite know what we would change.

John

[Michael Jones]

For #502-504, we need more details on the change(s) that Hideki is proposing

[Nat Sakimura]

I think what Hideki is proposing is to add some text to reference rfc 2459.

So, currently, it is:

The key usage of the respective keys MUST include encryption. In particular, if the key found through x5u is used, the key usage MUST include keyEncipherment.

Instead, he probably is proposing something like:

The key usage of the respective keys MUST include encryption. In particular, if the key found through x5u is used, the key usage MUST include keyEncipherment as defined in section 4.2.1.3 of RFC2459. 

[hideki nara]

Sorry for making you worry things because of my short words. I'm not quite sure if we should describe X.509 detail things in Messages or JW*. If we want to describe in Messages, I think we should refer terms to proper specification as Nat wrote.

[John Bradley]

I am unconvinced that we should be mentioning X.509 extension processing at all.

If we adhere strictly to RFC2459 processing PKI bridges are precluded as it only supports a strict hierarchy.

If a deployment is strictly processing x.509 and the certificate doesn't contain keyEncipherment as a keyUsage then it won't encrypt to it.

This is really a recommendation to the Authorization server about publishing certificates.

I could go with something like.

The Certificate SHOULD be valid for its intended use as defined by RFC2459.

John

[John Bradley]

Fixes #502 #503 #504 Fixed Sec 4.2, 4.3, 4.4 to replace requirement for using x.509 keyuse extension Added reference to RFC2459

→ 011d86d07e8f