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

From: Peter Sylvester <[email-masked]>
Date: Thu, 14 Apr 2005 10:49:44 +0200 (MEST)

> >1 ***
I think there were two other answers.

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

oops, I made a mistake. i wanted to ask "could you use a certificate
that has no keyUsage for EAP methods?'

> >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).
> 
> The IETF (or anyone else for that matter) should not specify EAP methods 
> that expect either of these key usage bits to be set.
> 
> 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.

The initial text was an inconsistent adoption from something of 2459 and 3280.
This demonstrates the problematics of copying text portions "for convenience."
Correcting the text as is still does not give a complete picture since it
is only a subset of rfc 3280. This kind of 'layman guide to 3280' doesn't
seem appropriate to me here.

Also, 3280 is under revision, if it happens that the corresponding text
gets clarified in some way, one would have something considered
unprecise elsewhere.

> >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)}
> 
> This is a matter of taste.  Neither approach leads to implementation issues.

Since, as you say, there are no implmentation issues. but this is not
a matter of taste. Importing the correct definition is something else
that making the 'hopefully' identical one.

There is ONE authoritive place to have 'this' id-aca defined. 
(and another id-aca elsewhere)

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Apr 2005 10:01:08 -0400

Note:  I am starting a separate thread for each of the unresolved 
issues.  I hope this draws more people into the discussion.

>that has no keyUsage for EAP methods?'

Yes.  In this case, the certificate is not providing any constraints on the 
key usage.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Apr 2005 10:47:49 -0400

>gets clarified in some way, one would have something considered

I do not understand the harm that you believe is being caused.

Russ

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 Apr 2005 11:00:39 -0400

>(and another id-aca elsewhere)

I do not know about other people, but would rather avoid IMPORT statements 
for simple things.  IMPORT is a great tool for complex structures, but for 
a simple constant, it is not worth the effort.

I have had to make edits to old ASN.1 modules to avoid errors that are 
introduced when one modules imports stuff from another that imports stuff 
from another that imports stuff from another.  The changes are almost 
always in parts that are not needed for the part that is needed.  I'll give 
a recent example.

RFC 2634 imports from CMS.  The ASN.1 module says:

-- RFC 2630: Cryptographic Message Syntax (CMS)
     ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
     FROM CryptographicMessageSyntax
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-9(9) smime(16) modules(0) cms(1) }

I needed to change this to:

-- RFC 3852: Cryptographic Message Syntax (CMS)
     ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
     FROM CryptographicMessageSyntax2004
        { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-9(9) smime(16) modules(0) cms-2004(24) }

Why?  It did not have anything to do with ContentType, 
IssuerAndSerialNumber, or SubjectKeyIdentifier.  It had to do with 
something else in the RFC 2630 module.

I would rather not have to make these kinds of edits, so I prefer to 
duplicate simple constants like OID arcs.

Russ