Subject: Re: Is possible indefinite form of length encoding in DER?

From: "Rich Ankney" <[email-masked]>
Date: Mon, 18 Sep 2000 23:01:36 -0400

I think all of the RFC 2630 stuff needs to be DER.  It's not clear at all
what you can do about some ASN.1 wrapped in the eContent OCTET
STRING though.  If that were ASN.1 (wrapped in an OS) there's no
way to signal how it's encoded (although this sort of thing is a topic
in the new version of ASN.1).  Theoretically it could be anything but it
has to be signalled by the content type (IMHO).

Regards,
Rich

-----Original Message-----
From: ChungKil Kim <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Monday, September 18, 2000 10:41 PM
Subject: Q: Is possible indefinite form of length encoding in DER?

>In some S/MIME messages, there are indefinite form of length encoding.
>Is it possible?
>
>In PKCS specs, only use DER?
>

---

From: Aram Perez <[email-masked]>
Date: Mon, 18 Sep 2000 20:17:18 -0700

Hi Rich and ChungKil,

It's my understanding that for OCTET STRING you can use a constructed OCTET
STRING, which when you decode appears as one OCTET STRING. I used to have an
example file but I don't know where it is.

Regards,
Aram Perez

> From: Rich Ankney <[email-masked]>
> Date: Mon, 18 Sep 2000 23:01:36 -0400
> To: ChungKil Kim <[email-masked]>, [email-masked]
> Subject: Re: Is possible indefinite form of length encoding in DER?
>

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Tue, 19 Sep 2000 11:07:48 -0400

Hi Rich,

> I think all of the RFC 2630 stuff needs to be DER.  It's not clear at all

RFC 2630 says this:

   The Cryptographic Message Syntax values are generated using ASN.1
   [X.208-88], using BER-encoding [X.209-88].  Values are typically
   represented as octet strings.  

I could go on and on about this one. First of course is that
DER is a subset of BER, so DER is allowed anywhere that some
protocol specifies BER. And of course you're right that almost
all specifications (except for this one) based on derivatives 
of RSA's PKCS #7 rely on DER. Since BER is used the encoding
details are at the option of the sender and the restrictions
of DER do not hold here. Note that X.209 predates DER and does
not define any distinguished encoding rules. DER is defined in
X.690 and a Directory-only DER variant is defined in X.509. 

And the current RSA PKCS specifications all rely on well
constructed ASN.1 notation based on the current ASN.1 
standards (as is the case for all ISO, ITU-T, and X9
specifications) rather than on the deprecated X.208/209
versions of the ASN.1 standards, which are in maintenance
and scheduled for withdrawal. No one is working on these
versions to amend them to add new types (UTF8String,
BMPString, RELATIVE-OID) and notation (ENCODED BY, 
CONTAINING) or to correct their many known defects. 

> in the new version of ASN.1).  Theoretically it could be anything but it

Yes, we use this new constraint notation in two of our
recent specifications, X9.68 compressed domain certificates
and X9.84 biometric management which are both in/near some
stage of balloting. The new constraint notation allows tools
to identify the format of the value portion of an octet or
bit string with an object identifier.

For example, X9.68 contains revised versions of familiar 
cryptographic types:

   MessageDigest ::= CHOICE {
      digest        OCTET STRING (SIZE(20)) (ENCODED BY sha-1),
      digestedData  DigestedData
   }

   RSA-PublicKey ::= 
      BIT STRING (CONTAINING RSAPublicKey ENCODED BY rsaEncryption)

as well as

   DNSName ::= 
        VisibleString (SIZE(1..MAX)) (PATTERN "[A-Za-z0-9 .-]*")

And X9.84 uses short (one byte) relative object identifiers to 
indicate well known biometric technologies:

body-Odor           RELATIVE-OID ::= { bodyOdor(1) }
dna                 RELATIVE-OID ::= { dna(2) }
ear-Shape           RELATIVE-OID ::= { earShape(3) }
facial-Features     RELATIVE-OID ::= { facialFeatures(4) }
finger-Image        RELATIVE-OID ::= { fingerImage(5) }
finger-Geometry     RELATIVE-OID ::= { fingerGeometry(6) }
hand-Geometry       RELATIVE-OID ::= { handGeometry(7) }
iris-Features       RELATIVE-OID ::= { irisFeatures(8) }
keystroke-Dynamics  RELATIVE-OID ::= { keystrokeDynamics(9) }
palm                RELATIVE-OID ::= { palm(10) }
retina              RELATIVE-OID ::= { retina(11) }
signature           RELATIVE-OID ::= { signature(12) }
speech-Pattern      RELATIVE-OID ::= { speechPattern(13) }
thermal-Image       RELATIVE-OID ::= { thermalImage(14) }
vein-Pattern        RELATIVE-OID ::= { veinPattern(15) }

So, for example, I can specify that a component of some type
contains a Java applet and my decoder tools can take some
action when the applet is received:

  Applet ::= OCTET STRING (ENCODED BY java-applet)

Or perhaps I can identify the my favorite word processor
or compression format and have my application spawn some 
process to display or archive the data:

  Tar ::= OCTET STRING (ENCODED BY id-tar)

  Zip ::= OCTET STRING (ENCODED BY gZIP)

  Word95 ::= OCTET STRING (ENCODED BY id-word)

Or perhaps I need to sign some XML without regard to 
whether it is well formed or not, relies on relative
URIs, or has white space issues, relies on RELAX or
some yet undefined schema:

  XML-Document ::= 
    OCTET STRING (CONTAINING UTF8String ENCODED BY xml)

Here, the 'value' portion (ala TLV) of the OCTET STRING
contains the complete encoding of a value of type
UTF8String, which itself is identified as an XML
document. This can be easily signed using CMS just
like any other piece of "data"content. But it can 
also be picked out of an ASN.1 message by clever tools
and processed by a receiving application.

Identification of these types of document entities is 
currently underway in a revised version of X9.45 that
should be ready for review and discussion at next 
months X9F1 meeting.

-- 
Phil
----
Phillip H. Griffin      Griffin Consulting
http://asn-1.com        Secure ASN.1 Design & Implementation
+1-919-832-7008         1625 Glenwood Avenue, Five Points
+1-919-832-7390 [fax]   Raleigh, North Carolina  27608  USA
------------------------------------------------------------