IETF Logo Mail Archive

Re: Distinguished names and X509v3 extension OIDs (fwd)

Eric Young <eay@cryptsoft.com> Tue, 01 April 1997 02:36 UTC

Received: by suntan.tandem.com (8.6.12/suntan5.970212) for ietf-pkix-relay id SAA15652; Mon, 31 Mar 1997 18:36:48 -0800
Received: from cryptsoft.com by suntan.tandem.com (8.6.12/suntan5.970212) for <ietf-pkix@tandem.com> id SAA15555; Mon, 31 Mar 1997 18:36:04 -0800
Received: from localhost (eay@localhost) by cryptsoft.com (8.8.3/8.7.3) with SMTP id MAA14862; Tue, 1 Apr 1997 12:35:12 +1000 (EST)
Date: Tue, 01 Apr 1997 12:35:11 +1000
From: Eric Young <eay@cryptsoft.com>
To: Warwick Ford <wford@verisign.com>
cc: "David P. Kemp" <dpkemp@missi.ncsc.mil>, warwick@rcc-irc.si, ietf-pkix@tandem.com, ssl-users@mincom.oz.au
Subject: Re: Distinguished names and X509v3 extension OIDs (fwd)
In-Reply-To: <3.0.32.19970331164633.0074767c@pop.a001.sprintmail.com>
Message-ID: <Pine.SOL.3.95.970401122937.14715D-100000@pandora.cryptsoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"

On Mon, 31 Mar 1997, Warwick Ford wrote:
> The level of indirection gained through the OCTET STRING overcomes this
> problem.  Intermediate systems are not permitted to change the encoding of
> an extension at the inner level, since it is mandated to always be DER.
> And changing the encoding of the octet string itself is not a problem as
> you can always regenerate the DER encoding of an OCTET STRING.

I would definitly agree that the abstraction supplied by the OCTET STRING
is required.  In much the same way a BIT-STRING is used to contain the
'blob' that is a public key, the OCTET STRING holds those objects that
the particular software does not understand.
The X509v3 extensions even go so far as to let you know if it matters that
you can not decode the OCTET-STRING (manditory flag).

eric

v2.23.0 | Report a Bug | By Email