Subject: Re: PKIX WG Last Call: 3770bis

From: Peter Sylvester <[email-masked]>
Date: Fri, 8 Apr 2005 12:49:42 +0200 (MEST)

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. 

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

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.

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

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

have fun.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 08 Apr 2005 23:16:14 +1200

>X.208 and X.209 are a bit outdated. is 1.3 necessary?

They're not just outdated, they've been withdrawn, which means that for
standardisation purposes they don't exist any more.  You can't refer to them
in a standard, at least not in any normative sense.

Peter.

---

From: Russ Housley <[email-masked]>
Date: Fri, 08 Apr 2005 10:53:48 -0400

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.

>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.

>in rfc 2459 or 3280, it seems that the text is at least

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.

>not, or don't say anything, and specify the treatment when

I think the above proposed changes address these points.

>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.

>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