Re: AD Review for draft-ietf-pkix-rfc3770bis

[Russ Housley <housley@xxxxxxxxxxxx>]

Sam:

Thanks for the AD review.  It has improved the document.

Here is how I addressed each of your comments.  I have CCed the PKIX mail 
list to stan any WG member can raise the alarm if they do not like the way 
that any comment was resolved.

> The document sites RFC 2284, not RFC 3748 which supersedes 2284.  In
> addition the document's terminology is inconsistent with RFC 3748.
> EAP defines an exchange between a peer and an EAP server.  The term
> client is not typically used.  My preference is that you fix the
> terminology but this is not a requirement.    The reference does need to 
> be updated.  Also, I wonder whether it should be normative.

[EAP] changed to normative, and it references RFC 3748.

The terminology was updated to use "supplicant" when talking about 802.1X 
and "peer" when talking about EAP.  The term "EAP server" is also used.

> section 1:
> There are two places in an EAP protocol where it seems obvious you
> might want to use a certificate: the peer might want a certificate to
> prove its identity to the EAP server and a EAP server might want a
> certificate to prove its identity to the peer.  This document deals
> with the first case but does not make that clear.
> The following change helps.
>
> s/for/by/
> old:
>    Automated selection of certificates for PPP and IEEE 802.1X clients
>       is highly desirable.  By using certificate extensions to identify the
> new:
>    Automated selection of certificates by  PPP and IEEE 802.1X clients
>       is highly desirable.  By using certificate extensions to identify the

The "client" in this sentence causes problems with your earlier comment.
How about: "Automated selection of client certificates for use with PPP
and IEEE 802.1X is highly desirable."

> I'd like to see  text like the following worked into section 1
> though to make things completely clear.
>
>  This document defines key usage values and certificate extensions to
>  be used in certificates issued to clients of PPP and wireless
>  networks.

How about a new paragraph at the end of section 1:
"This document defines extended key usage values and a WLAN-specific
certificate extension for use in certificates issued to clients of
PPP and WLANs."

> section 2:
>
> Do these key purpose IDs apply to EAP server certificates or to client
> certificates or to both?

The intent was peer certificates.  I do not recall any discussion of EAP 
server certificates using them.

Proposed revision:
"Inclusion of the EAP over PPP value indicates that the certified public
key is appropriate for use by a peer with EAP in the PPP environment.  The
inclusion of the EAPOL value indicates that the certified public key is
appropriate for use by a peer with the EAP in the LAN environment.
Inclusion of both values indicates that the certified public key is
appropriate for use by a peer in either of the environments."

> The text quotes the description of extend key usages from RFC 3280 and
> points out that an application can require extended key usage and a
> particular KeyPurposeId.  Is the intent for this to be defined by the
> EAP method, the EAP method implementation, site policy, or something
> else?  How should implementers handle the situation where the EAP
> implementation does not know what environment it is being used in?
> (I'm not sure whether this situation is actually common.)

I do not think there is a problem here.  EAP methods that use certificates 
can require the presence of a particular KeyPurposeId, but I do not think 
that any have done so.

> The extended key usage should presumably be checked both by the EAP peer 
> and the EAP server.  The text should probably make this more clear.

I see it more as a selection criteria when more than one certificate is 
available.

> Section 3:
>
> The following text seems to be trying to imply that the ssid extension
> can only be used with the extended key usage extension.  If that's
> true the requirement needs to be stated more clearly.  However I don't
> understand why you would want that requirement--it seems reasonable to
> use the ssid extension with an application (EAP method) that does not
> require extended key usage.
>
>  When more than one certificate includes an extended key usage
>     extension indicating that the certified public key is appropriate for
>        use with the EAP in the LAN environment, then the list of SSIDs MAY
>           be used to select the correct certificate for authentication in a
>              particular WLAN.

It is not a requirement.  It is trying to say that the KeyPurposeId could 
narrow the certificate selection, and then this extension could provide 
further assistance.  It is perfectly fine for only one of the extensions to 
be used.

I suggest replacing the first paragraph of setcion 3 with:

The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key
certificate extension is always non-critical.  It contains a list of
SSIDs.  The list of SSIDs MAY be used to select the correct certificate
for authentication in a particular WLAN.

If the extended key usage extension appears in the same certificate as
the SSID extension, then the extended key usage extension MUST
indicate that the certified public key is appropriate for use with the EAP
in the LAN environment by including the id-kp-eapOverLAN KeyPurposeId value.

-- Russ