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

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

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