Subject: PKIX WG Last Call: 3770bis

From: Tim Polk <[email-masked]>
Date: Thu, 07 Apr 2005 14:19:09 -0400

This message initiates a *one week* working group last call 
for  "Certificate Extensions and Attributes Supporting Authentication in 
Point-to-Point Protocol (PPP) and Wireless Local Area Networks 
(WLAN)".  The current draft is available at

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3770bis-00.txt

A one week last call has been selected due to the limited changes with 
respect to RFC 3770. 3770bis and RFC 3770 are identical , with one 
exception. RFC 3770 contained a typographical error in the object 
identifier for the Wireless LAN SSID Attribute Certificate Attribute. 
3770bis corrects the typographical error.

Thanks,

Tim Polk

---

From: Russ Housley <[email-masked]>
Date: Fri, 08 Apr 2005 11:53:34 -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.

 >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

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 11 Apr 2005 17:42:34 +0200 (MEST)

> 
> The previous text was intended to help the reader, avoiding the need to 
> reread RFC 3280 to get the concepts.  I think this text meets this same goal.

Getting the concept may be in a non-normative section.
and, as the current text shows, it can get wrong. 

I don't think that this text should be a tutorial for 3280. 

> >                        !
> >                        !BY WHOM?
> >This sentence is nothing special for this text.
> 
> By any certificate user.  I'll edit the sentence.

What is a certificate user? You mean the private key owner? 

> >This sentence sounds ok.

I add: this is nothing special with this text.  

> >This one is a good one.

The application is a certificate user? There are two ends? 

> 
> That would be listing all of the other bits.  For example, EAP-TLS has the 
> same rules as TLS, which depends on the cipher suite that is 
> negotiated.  Other EAP methods could be defined in the future that make use 
> of the other ones.

But what is written is that it is not possible to have no keyUsage, 
since this would imply *ALL* usages, thus also keyCertSign. 

    If a certificate contains a key usage extension, the KeyUsage bits
    that are needed depend on the EAP method that is employed. 

Peter