Re: PKIX WG Last Call: 3770bis

[Russ Housley <housley@xxxxxxxxxxxx>]

Peter:

Given the minor change that was made, I am surprised to see substantive 
comments.  However, I agree with your comments.  I propose replacement text 
below.

> The text at the end of chapter two seems to allow two
> different treatments for an entity that KNOWS the
> extension depending on the criticality bit.

How about this instead:

   If a certificate contains both a key usage extension and an extended
   key usage extension, then both extensions MUST be processed
   independently and the certificate MUST only be used for a purpose
   consistent with both extensions.  If there is no purpose consistent
   with both extensions, then the certificate MUST NOT be used for any
   purpose.

> if I compere the last two paragraphs with similar ones
> in rfc 2459 or 3280, it seems that the text is at least
> confusing.

How about this instead:

   The extended key usage extension MAY, at the option of the certificate
   issuer, be either critical or non-critical.

   If the extended key usage extension is present, then the certificate
   MUST only be used for one of the purposes indicated.  If multiple
   purposes are indicated the application need not recognize all
   purposes indicated, as long as the intended purpose is present.
   Certificate using applications MAY require that a particular purpose
   (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in
   order for the certificate to be acceptable to that application.

> I think the best is, not to remove them here, and not try for
> 'convenience' to give a definition at all.
>
> Or, define a keyPurpose, say whether it is critical or
> not, or don't say anything, and specify the treatment when
> it is recognized.

I think the above proposed changes address these points.

> The text also references keyUsage, but does not say which
> keyUsage bits are compatible with the defined KeyPurposes.

This depends on the EAP method that is employed.  I propose the following:

   If a certificate contains a key usage extension, the KeyUsage bits
   that are needed depends on the EAP method that is employed; however,
   the keyCertSign bit and the cRLSign MUST NOT be associated with
   EAP method end entity certificates.

> X.208 and X.209 are a bit outdated. is 1.3 necessary?
> It is not in rfc 3280, as far as I see.

The section is necessary to make ASN.1 a normative reference.

These are the same ASN.1 references used by RFC 3280.  I would rather 
maintain the same dependencies.

Russ