Re: PKIX WG Last Call: 3770bis

[Russ Housley <housley@xxxxxxxxxxxx>]

Peter:

> > >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.
>
> isn't this just a copy of rfc 3280 or its *bis, there is no value
> added information concerning 3770bis, if is nothing in the treatment
> that differs from the standard one. If so, it seems to be superfluous. to me.

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.

> > >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.
> Ok.
>
> >
> >     If the extended key usage extension is present, then the certificate
> >     MUST only be used for one of the purposes indicated.  If multiple
>                        !
>                        !BY WHOM?
> This sentence is nothing special for this text.

By any certificate user.  I'll edit the sentence.

> >     purposes are indicated the application need not recognize all
> >     purposes indicated, as long as the intended purpose is present.
> This sentence sounds ok.
>
> >     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.
> This one is a good one.
>
> >
> > >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.
>
> This text sounds like a new feature not present before.
> I suggest to list the keyUasge that influence the EAP method,
> and not the other way around.

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.

> > >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.
> see response from Peter Gutmann.
> >
> > These are the same ASN.1 references used by RFC 3280.  I would rather
> > maintain the same dependencies.
>
> 3280 has no reference to X.208 or else, at least not in the
> reference section. The syntax that you use is conformant to ASN.1,
> to any of the versions as far as I see. you don't use macros, or
> obsolete features, so referencing X.208 etc can be seen as if you
> require that a compiler or else is restricted to support this old
> version.

My mistake.  I'll fix it to use the same references as RFC 3280.

Russ