Subject: RE: Bug in RFC 2459

From: Alex Deacon <[email-masked]>
Date: Wed, 24 Feb 1999 08:55:35 -0800

Looks like draft-ietf-pkix-ipki-part1-11.txt specifies DisplayText for the
organization, so it must have been changed sometime before that.  

In anycase, we will update the extension to conform with the RFC.

Alex

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Wednesday, February 24, 1999 6:47 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Bug in RFC 2459
> 
> 
> Peter,
> 
> Not to be too picky, but what you described is not a bug just 
> becuase a
> spec changed from draft to RFC. Only if the change was 
> inadvertant would it
> qualify as a bug.  Perhaps the editors of Part 1 can comment on the
> motivation for the change.
> 
> Steve
>

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 24 Feb 1999 12:54:28 -0500 (EST)

> From: [email-masked] (Peter Gutmann)
> 
> (ObGrumble: You have to wonder why anyone even bothers adding half the 
>  extensions in a cert for all the attention that gets paid to them - the 
>  policy extension could probably have just about anything in there and noone 
>  would even notice).

That would be an implementation bug.

If an implementation follows the path validation procedure of section
6, it pays attention to the certificatePolicies extension.  If an
implementation can't be bothered with path validation, you could make
the same statement about anything:  "the { signatureValue | validity |
issuerDN | CRL | ... } could probably have just about anything in there
and noone would even notice."

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 25 Feb 1999 17:13:31 (NZDT)

>organization, so it must have been changed sometime before that.
 
It looks like it appeared in draft 08, June 1998.
 
>In anycase, we will update the extension to conform with the RFC.
 
This may not help much, since it'll just break any existing implementation 
which expects an IA5String (in practice I suspect it won't make any 
difference, because almost everything seems to ignore the policy stuff, but 
it's still a bit risky).  The problem lies with the RFC and not with existing 
implementations, what you'd need to do is allow a changeover period as with 
dates and UTF8String's where you can use IA5String until (say) 2005, but after 
that should use DisplayString.
 
Currently I'm using a CHOICE { DisplayString, IA5String } with DisplayString 
first in the encoding table which means it'll be generated in preference to 
IA5String, but IA5String will still be accepted when decoding certs.
 
Peter.