Subject: Re: CA vs. EE cert processing

From: "David P. Kemp" <[email-masked]>
Date: Wed, 7 Apr 1999 10:48:49 -0400 (EDT)

> From: [email-masked]
> 
> The PKIX working group doesn't have the ability to change X.509; we
> only have control of the PKIX specs.  A change to RFC 2459 would allow
> us to avoid stumbling into into this ambiguity in X.509, with the result
> that:
> 
> i)  PKIX certificates would not be ambiguous to an X.509 verifier,
> 
> and ii) PKIX verifiers would be able to distinguish ambiguous non-PKIX
> certs
> from unambiguous certs, without having to know whether the certificate
> issuer was PKIX-compliant.

The ITU has the ability to change X.509; this ambiguity should qualify
for treatment as a defect, if someone takes it upon themselves to generate
a DR.

You are correct that requiring the extension in EE certs would eliminate
the ambiguity.  But so would any one of:

 * correcting the incompletely-specified X.509 / ISO 9594-8
 * providing for manual intervention in user agents
 * including the Key Usage extension in EE certs
 * choosing to include the Basic Constraints extension in EE certs - PKIX
    does not prohibit that practice, just discourages it.

Changing PKIX from SHOULD NOT to SHOULD would not help - the ambiguity
would remain.  And changing it to MUST would suddenly bring all previously
conforming EE certs into non-conformance, as well as forcing the inclusion
of redundant information in newly-issued certs.

The right answer is to fix X.509 to require the basic constraints
extension in CA certs.  It already requires the version number to be
present in v3 certs; certs with the version number omitted
unambiguously default to v1.

---

From: Alan Lloyd <[email-masked]>
Date: Sat, 17 Apr 1999 15:30:17 +1000

Russ.

I aboslutely agree that the Profile should say that if the Ext BC is not
there OR it is there with a NULL then its an EE cert - but this does not
text define usage - which is the critical part.

And the SHALL NOT bit and the fuzzy words of 2119 just leave curiosity.

It would be nice if the para with SHALL NOT in is replaced with words
like.
"If the BC extension is not present or set to a NULL then the
certificate belongs to an EE and MUST NOT be used by the certificate
using system to verify the signature of a certificate." 

All done, precise, no indirection to other text which is fuzzy.

regards alan

----------
From: Russ Housley
To: [email-masked]
Sent: 4/16/99 4:32:32 AM
Subject: RE: CA vs. EE cert processing

I have kept quiet on this thread.  I cannot hold it in any longer.

RFC 2459 has no ambiguity in this area.  If basicConstraints is present,
then the cA boolean tells whether the certificate belongs to a CA or an
EE.
 If basicConstraints is absent, then the certificate belongs to an EE.
Period.

If an implementor wishes to support other profiles in addition to RFC
2459,
then the logic may be more complex.  Fine.  This was a market choice
made
by the implementor.

I do not think that RFC 2459 should be altered to make support for
multiple
profiles easier.

Russ

---

From: Alan Lloyd <[email-masked]>
Date: Wed, 21 Apr 1999 10:07:39 +1000

No problems with 2459 - time will tell - 
any chance of getting OCSP key identification compatable with it?
2459 requires Issuer Name, Auth Key Id and cert SN for identification -
magic... OCSP wants cert Ids hashed according to some chosen algorithm
the cert SN and optionally Issuer name (service locator extension) and
no Auth Key Id...
ie does OCSP validate according to 2459 MUSTS?

regards alan.

> -----Original Message-----
> From:	Russ Housley 
> Sent:	Tuesday, April 20, 1999 2:21 AM
> To:	Moshe Litvin
> Cc:	[email-masked]
> Subject:	Re: CA vs. EE cert processing
> 
> Moshe:
> 
> I will say is again.  There is not a problem with RFC 2459.  If an
> implementor wishes to support more than one profile, then that
> implementor
> must resolve any ambiguities that result.
> 
> As far as I am concerned, this issue has been thrashed to death, and
> we
> should bring this thread to an end.
> 
> Russ
> 
> 
> At 12:17 PM 4/18/99 +0300, Moshe Litvin wrote:
> >Russ,
> >
> >Russ Housley wrote:
> >
> >> then the cA boolean tells whether the certificate belongs to a CA
> or an EE.
> >The term "ambiguity" is not the exact term. The problem is not
> ambiguity but
> >relying on out of band data. RFC 2459 is very clear as long as you
> know by 
> >out of
> >band data that the certificate was issued by RFC 2459 compliant CA.
> >
> >>
> >>
> >> If an implementor wishes to support other profiles in addition to
> RFC 2459,
> >> then the logic may be more complex.  Fine.  This was a market
> choice made
> >> by the implementor.
> >>
> >Why? do you think that whole world would choose adopt RFC 2459 and
> all the 
> >other
> >profiles (including the base X.509) will become obsolete?
> >
> >Why would you force software designers to choose between two
> contradicting 
> >profiles
> >of the same standard when you can easily allow them to support both?
> >
> >What is the compelling reason to prevent interpretability in that
> way?
> >
> >Moshe
> >