Warwick Ford | 1 Apr 02:50 1997
Picon

Re: Distinguished names and X509v3 extension OIDs (fwd)

We certainly looked first at the more obvious options such as ANY DEFINED
BY and EXTERNAL but were forced to reject them.  I think what you are
saying you would prefer is essentially the ANY DEFINED BY option, i.e., (in
shorthand) SEQUENCE { oid, boolean, ANY DEFINED BY oid }.  (Actually this
would be done using table notation, but most readers probably are more
familiar with ANY DEFINED BY.)

>From recollection, the problem with the ANY DEFINED BY approach is as
follows.  Recall that a certificate is not necessarily transmitted
everywhere encoded in DER.  Some certificate-carrying protocols use
BER-encoding.  This is why a cert using system may need to regenerate the
DER encoding of the cert when verifying the signature.  Recall also that
intermediate systems through which a cert traverses may decode and recode
certs differently (e.g., if BER is in use, a system may re-encode a cert
with a different BER encoding than that in which it was received).  In the
case of an extension, such a change of encoding might occur in any system
that recognizes the extension OID and the corresponding ASN.1 type for the
extension value.

Now, when it comes to validating a cert, note that certs that contain
unrecognized extensions may still be perfectly valid and usable (provided
every unrecognized extension is flagged noncritical).  But, if it is
possible for the bit-representation of an unrecognized extension to have
changed in transit, how can the cert-using system generate the required
canonical encoding to verify the cert's signature?

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
(Continue reading)

Eric Young | 1 Apr 04:35 1997

Re: Distinguished names and X509v3 extension OIDs (fwd)


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

David P. Kemp | 1 Apr 16:12 1997

Re: Distinguished names and X509v3 extension OIDs (fwd)

> From wford <at> verisign.com Mon Mar 31 16:45:05 1997
>
> We certainly looked first at the more obvious options such as ANY DEFINED
> BY and EXTERNAL but were forced to reject them.  I think what you are
> saying you would prefer is essentially the ANY DEFINED BY option, i.e., (in
> shorthand) SEQUENCE { oid, boolean, ANY DEFINED BY oid }.

Yes.

> 
> >From recollection, the problem with the ANY DEFINED BY approach is as
> follows.  Recall that a certificate is not necessarily transmitted
> everywhere encoded in DER.  Some certificate-carrying protocols use
> BER-encoding.  This is why a cert using system may need to regenerate the
> DER encoding of the cert when verifying the signature.  Recall also that
> intermediate systems through which a cert traverses may decode and recode
> certs differently (e.g., if BER is in use, a system may re-encode a cert
> with a different BER encoding than that in which it was received).  In the
> case of an extension, such a change of encoding might occur in any system
> that recognizes the extension OID and the corresponding ASN.1 type for the
> extension value.
> 
> Now, when it comes to validating a cert, note that certs that contain
> unrecognized extensions may still be perfectly valid and usable (provided
> every unrecognized extension is flagged noncritical).  But, if it is
> possible for the bit-representation of an unrecognized extension to have
> changed in transit, how can the cert-using system generate the required
> canonical encoding to verify the cert's signature?
> 
> The level of indirection gained through the OCTET STRING overcomes this
(Continue reading)

Ben Laurie | 1 Apr 16:19 1997
Picon

Re: Distinguished names and X509v3 extension OIDs (fwd)

David P. Kemp wrote:
> If anyone has a counterexample - a BER transfer string that cannot
> be converted to DER without knowledge of the ASN.1 definition, I'd
> like to see it.

>From memory, if a field has its default value, in DER it must be omitted, but
in BER it is optional. I could be completely wrong, though.

Cheers,

Ben.

--

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben <at> algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

David P. Kemp | 1 Apr 17:32 1997

Re: Distinguished names and X509v3 extension OIDs (fwd)

> From: Ben Laurie <ben <at> gonzo.ben.algroup.co.uk>
> 
> David P. Kemp wrote:
> > If anyone has a counterexample - a BER transfer string that cannot
> > be converted to DER without knowledge of the ASN.1 definition, I'd
> > like to see it.
> 
> >From memory, if a field has its default value, in DER it must be omitted, but
> in BER it is optional. I could be completely wrong, though.

Touche'.   I was considering definite/indefinite length encoding, but
failed to consider DEFAULT.  There are probably other reasons to need
the ASN.1 as well.

(Reference for DEFAULT encoding: X.690 sections 8.11.3 and 11.5)

It's a shame that the entire signed portion of a certificate can't be
treated as an opaque blob in transit, instead of each individual extnValue.

Carlisle Adams | 1 Apr 19:33 1997

PKIX Part 3...

Hi,

Well it turns out that with IETF's new automated process, missing the
submission deadline by half an hour was significant.  Maybe next time I
won't lose half a day from computer troubles at a critical time...   Ha.

In any case, there is a revised version of PKIX-3 and I have posted it
on our website so that people have access to it prior to Memphis.  It
can be found at  http://www.entrust.com/library.htm  (just keep
scrolling down until you get to the PKIX section).

On the list, the main topics debated were:

   - PKCS #10 versus the original certification request message;
   - PKCS #7 (or any other external mechanism) versus the original
message protection scheme;
   - POP of private key being optional or mandatory.

Other issues that came up (either publicly or privately) included making
POP for decryption keys an extended exchange (i.e., longer than 3
messages) in order to accommodate the presence of an RA, and
generalizing the information request/response messages to accommodate
future needs/extensions.

I would strongly encourage all who were involved in those debates (and
all who were interested observers) to take a look (especially at pages
10-11, 17-18, 25-27, 31, 44, 46-47, 53-55) in preparation for Memphis.
Is the new draft something we can all live with?  My hope is that this
draft will satisfy enough people to generate the obligatory "rough
consensus" on these issues so that we can progress to other things
(Continue reading)

Holger Reif | 2 Apr 08:11 1997
Picon
Picon

ASN.1 types for Distinguished names (was: Re: Distinguished names and X509v3 extension OIDs (fwd))

Hi,

this seems to be a nice thread to jump in ;-)

I noticed that many of the X.520 Selected attributes are of type DirectoryString
which in turn is a choice of teletexString, printableString and universalString.
Does anybody know when which Form is to be used and wether a transformation 
between these types (if possible) is allowed and gives equal meaning. 

Of course, if it's within a SIGNED context then the answer is clear: 
one can't change the types. But in other cases?

read you later  -  Holger Reif
----------------------------------------  Signaturprojekt Deutsche Einheit
TU Ilmenau - Informatik - Telematik                      (Verdamp lang her)
Holger.Reif <at> PrakInf.TU-Ilmenau.DE         Alt wie ein Baum werden, um ueber
http://Remus.PrakInf.TU-Ilmenau.DE/Reif/  alle 7 Bruecken gehen zu koennen

Warwick Heath | 2 Apr 10:37 1997
Picon

Re: Distinguished names and X509v3 extension OIDs (fwd)

>
>I read that to mean that in the absense of a specific profile, *any*
>attribute (not just any under 2.5.4) is a legal component of a DN
>according to X.501.
>
>That said, it is good practice for a certificate to contain the
>absolute minimum of information required to accomplish it's purpose,
>which is to provide a secure binding between a public key and an
>entity.  If your definition of an "entity" does not include a street
>address as a fundamental, essential element of it's identity, then
>the street address should not be included in the DN in a certificate,
>or for that matter, in an extension.

OK, then street names etc. are out. I suppose I was looking at the
certificate containing all the info that I would like to have (seeing
as the directory itself is not available).

>> >One person mailed to me the location of a copy of X500v3 online. 
>> >Another emailed the location of a database of lots of OIDs.
>
>Could you forward me, or better, post the location of the OID database?

Andrew Probert <AndrewP <at> esd.nec.com.au> provided me with the following URL

http://domen.uninett.no/~hta/ietf/oid/top.html

Thanks to the people who have answered to this thread - the technical
questions are now clearer, now I just have to wrestle with the
social/privacy implications of sensitive data in high assurance 
certificates (i.e. a single cert containing a unique national identifier
(Continue reading)

Charles W. Gardiner | 2 Apr 17:18 1997
Picon

Re: Distinguished names and X509v3 extension OIDs (fwd)

    Since tagging is implicit in extensions, wouldn't it be possible to have a
BIT STRING with named bits that has a context-specific tag which hides the BIT
STRING tag?  If one didn't know the ASN.1, one wouldn't be able to tell which
bits were named.  This affects the encoding, I believe.  Or a context=specific-
tagged BOOLEAN would also be concealed.

Charlie Gardiner

Brian Korver | 2 Apr 19:32 1997

Re: ASN.1 types for Distinguished names (was: Re: Distinguished names and

Holger Reif writes:
> 
> Hi,
> 
> this seems to be a nice thread to jump in ;-)
> 
> I noticed that many of the X.520 Selected attributes are of type DirectoryString
> which in turn is a choice of teletexString, printableString and universalString.
> Does anybody know when which Form is to be used and wether a transformation 
> between these types (if possible) is allowed and gives equal meaning. 

BMPString has basically replaced UniversalString because, I have
been told, nobody used UniversalString.  I can be believe this.

Both TeletexString (T61String) and PrintableString have constraints as
to what can be placed in them.  So for instance if you need to use a
character such as ' <at> ', you cannot use PrintableString.

I'm unaware of any equality rules to use when comparing strings of 
unequal type.  I assume that most implementations assume that strings
of unequal type are by definition not equal.  IMHO this is the best
approach because of the lack of well-defined equality matching rules.

I'm also unaware of any rules for "which string do I use" when there
are multiple string types to choose from.

> Of course, if it's within a SIGNED context then the answer is clear: 
> one can't change the types. But in other cases?

brian
(Continue reading)


Gmane