Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Fri, 26 Jul 2002, David L. Wasley wrote:

> Not to prolong this thread but my earlier comment was to suggest that
> the designation "non-critical" would imply that the usage bits have
> little practical meaning.  Nothing in the certificate is legally
> binding.  In particular, the notion that "if you don't understand this
> field, just ignore it" would seem to make it advisory, not "critical" to
> the use of the cert.

It did mean that in 2459.  In 3280 they changed it.  And we're not talking
"legal", we're talking "compliant with the published standard".

Section 4.2, on extensions, says:

   At a minimum, applications conforming to this profile MUST recognize
   the following extensions: key usage (section 4.2.1.3), certificate
   policies (section 4.2.1.5), the subject alternative name (section
   4.2.1.7), basic constraints (section 4.2.1.10), name constraints
   (section 4.2.1.11), policy constraints (section 4.2.1.12), extended
   key usage (section 4.2.1.13), and inhibit any-policy (section
   4.2.1.15).

This makes the "critical" bit moot for this extension, it seems to me,
since its only effect is if the extension isn't recognized, but this
extension has to be recognized.  So if ExtKeyUsage is present, a compliant
implementation has to recognize it and obey it, meaning reject the cert if
the use doesn't match the stated KeyPurpose; the question is how it does
that matching.

> I assume that typically these advisory restrictions are put in the
> cert because the Issuer doesn't want to accept liability for use of
> the cert for certain things (or more correctly, only accepts
> liability for its use for certain things).

I'm fairly certain that in this case it's not a liability thing, it's a
crypto thing.  Cryptographers will tell you that the same key should not
be used in different contexts, because sometimes, even though each of two
contexts might be secure in themselves, using the same key in both can
make it trivially discoverable; it's the sort of puzzle cryptographers
love.  So setting and checking (ext)key usage makes sure this doesn't
happen.

The fact that, if you're selling certs, this would oblige your customers
to buy more from you, well, that can't be helped, can it?  In a rational
world a CA might provide you with both client and server certs for the
same host for one low low price.  Let's demand that of Thawte, shall we?

 - RL "Bob"


------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--