Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3770bis-01.txt

From: Peter Sylvester <[email-masked]>
Date: Wed, 13 Apr 2005 13:41:15 +0200 (MEST)

Some more remaks:

1 ***

text says:

1.3. Abstract Syntax Notation

   All X.509 certificate [X.509] extensions are defined using ASN.1
   [X.660].

and:

   [X.660]     ITU-T Recommendation X.660 Information Technology - ASN.1
               encoding rules: Specification of Basic Encoding Rules
               (BER), Canonical Encoding Rules (CER) and Distinguished
               Encoding Rules (DER), 1997.

this looks strange to me. The encoding rules are not the asn1 syntax.

Suggestion: 

remove 1.3 and the reference. 

2 ***

   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.

This means that you cannot have a certificat WITHOUT keyUsage?
Or, in case of a certificate without keyUsage, you could use it
for CrlSigning? 

This restriction is new, and I don't see why this is necessary.
I am not sure, but I don't know of any other purpose that has
a restriction like this, and current scvp specs don't allow to
check for this (you cannot specify MUST NOT). 

suggestion, remove the second half sentence. 

3 *** chapter two should read IMO:

2. EAP Extended Key Usage Values

   RFC 3280 [PROFILE] specifies the extended key usage X.509 certificate
   extension.  The extension indicates one or more purposes for which
   the certified public key may be used.  

   This specification defines two KeyPurposeId values: one for EAP over
   PPP, and one for EAP over LAN (EAPOL).  Inclusion of the EAP over PPP
   value indicates that the certified public key is appropriate for use
   with EAP in the PPP environment, and the inclusion of the EAPOL value
   indicates that the certified public key is appropriate for use with
   the EAP in the LAN environment.  Inclusion of both values indicates
   that the certified public key is appropriate for use in either of the
   environments.

      id-kp-eapOverPPP  OBJECT IDENTIFIER  ::=  { id-kp 13 }

      id-kp-eapOverLAN  OBJECT IDENTIFIER  ::=  { id-kp 14 }

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

   If the extended key usage is present in a certificate,
   Certificate using applications MAY require that a particular purpose
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   (such as id-kp-eapOverPPP or id-kp-eapOverLAN) be indicated in order
   for the certificate to be acceptable to that application.

   If a certificate contains a key usage extension, the KeyUsage bits
   that are needed depends on the EAP method that is employed.
   There is currently no method that require the usage of the keyCertSign
   or the cRLSign bit to be set.  

with the XXXX a little bit more specific. 

4 *** The OID arcs should be imported from 

IMPORTS

   id-pe, id-kp 
   FROM PKIX1Explicit88 { iso(1) identified-organization(3)
            dod(6) internet(1) security(5) mechanisms(5) pkix(7)
            id-mod(0) id-pkix1-explicit(18) }

   id-aca FROM
   PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6)
                internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
                id-mod-attribute-cert(12)}

peter

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 13 Apr 2005 10:18:33 -0400

It also looks strange because ASN.1 is defined in X.680 :-).    X.660 is 
"Procedures
for the operation of OSI registration authorities: General procedures 
and top arcs of
the ASN.1 object identifier tree".

The titles of X.680 and X.690 are:
X.680: Information Technology - Abstract Syntax Notation One (ASN.1):
  Specification of basic notation
X.690: Information Technology - ASN.1 encoding rules: Specification of
  Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
  Distinguished Encoding Rules (DER)

Agree with the suggestion to remove section 1.3 and the reference.   If 
they are
retained, the reference should be changed to X.680 and its correct title.

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Apr 2005 16:22:49 -0400

Peter:

>remove 1.3 and the reference.

I have heard from Peter Sylvester and Peter Gutmann on this point.  Anyone 
else have an opinion?

>Or, in case of a certificate without keyUsage, you could use it

No.  The paragraph only talks about the key usage extension in support of 
EAP methods.  The question you are asking is beyond the scope of the 
paragraph and the whole document.

>check for this (you cannot specify MUST NOT).

The IETF (or anyone else for that matter) should not specify EAP methods 
that expect either of these key usage bits to be set.

>with the XXXX a little bit more specific.

You are primarily asking for sentence to be deleted. The sentences that you 
would like to see go away are in RFC 3770, so I think that the removal 
needs to be justified.

>                 id-mod-attribute-cert(12)}

This is a matter of taste.  Neither approach leads to implementation issues.

Russ

---

From: Steven Legg <[email-masked]>
Date: Thu, 14 Apr 2005 09:22:48 +1000

Russ,

Russ Housley wrote:
> I have heard from Peter Sylvester and Peter Gutmann on this point.  
> Anyone else have an opinion?

Firstly, the reference is incorrect. BER/CER/DER are defined in X.690,
not X.660. X.660 is about registration procedures for OIDs.

Secondly, the reference is inappropriate. ASN.1's basic notation is
defined in X.680.

     ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
     Information technology - Abstract Syntax Notation One
     (ASN.1): Specification of basic notation

Since knowledge of ASN.1 is required to interpret the specification,
a normative reference to X.680 is obligatory.

Regards,
Steven