Shibboleth Developers

["David L. Wasley" <>]

Bob is absolutely right (as usual).

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.

I do understand the "moral correctness" argument -- if you -do- 
understand it then you should respect it.  Then I have to wonder what 
the actual purpose of this silly restriction might be?

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).  So, if the Issuer asserts 
that the platform (Subject) has a DNS name of a.b.com, what does it 
matter if that platform is acting as the initiator or responder in a 
dialog?

If a Relying Party uses the cert for something that is not allowed by 
a usage field marked non-critical, it isn't at all clear that the 
Issuer is off the hook.  On the other hand, if the RP uses it when 
the usage field is marked critical, then I suppose there is -some- 
possible mitigation of liability.

        David

-----
At 10:01 AM -0700 on 7/26/02, RL 'Bob' Morgan wrote:

> On Fri, 26 Jul 2002, Scott Cantor wrote:
>
> >  I think that's the underspecified part.
>
> No, the underspecified part is the intent of:
>
>    id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
>    -- TLS WWW server authentication
>    -- Key usage bits that may be consistent: digitalSignature,
>    -- keyEncipherment or keyAgreement
>
> Is the "TLS WWW server authentication" prescriptive or only an example?
> If it's prescriptive then compliant implementations would have to reject
> use of such certs with SSL 3.0, with IMAP, etc, as I have suggested.  If
> it's not prescriptive, then what defines "serverAuth"?  If my "server" is
> using this cert to identify itself, is that OK, even if it happens to be
> acting as in the client role as defined by some particular protocol?  How
> about in a peer-to-peer protocol that doesn't distinguish client from
> server?
>
> The PKIX spec should leave the interpretation of purpose up to protocol
> specs, and up to profiles of those protocols for particular real-world
> purposes, like Shib.  It's completely stupid for this spec to try to
> specify this stuff.
>
>  - 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--