Subject: Re: "Alternatively-encoded" extensions

From: "David P. Kemp" <[email-masked]>
Date: Fri, 26 Mar 1999 13:31:14 -0500 (EST)

> From: Stephen Kent <[email-masked]>
> 
>    [snip]
>
> VeriSign and other vendors, in bid to get to market first, have sometimes
> introduced their own conventions into certificates, prior to the adoption
> of standards.  That's why we have such "features" as e-mail addresses
> encoded as common names, DNS names of servers encoded as common names, and,
> my favorite, the short form CPS encoded as a text string extension in a
> certificate.  So, I place little weight on conventions adopted in this
> fashion, just as RFC 2459 and the S-MIME RFCs have found it appropriate to
> denigrate what we now consider inappropriate name form conventions of the
> sort cited above.
> 
>    [Peter Williams wrote...]
> 
> >(The VeriSIgn CPS extension is/was not a name-form, for the record, and
> >is useful in a very particular application context, and for specific (legal)
> >purpose.)
> 
> See my comments on that extension above.

The following name-form was included in a VeriSign certificate which I
happened to have laying around.  Of particular interest is the URL
contained in an OrganizationalUnit RDN.  I agree with Steve that such
exhibits of expediency should not guide the development of PKIX
standards / best operating practices.

CompanyX's binary-encoded multimedia extension, patented or not, should
not be standardized by PKIX.  If CompanyX insists on placing this
information in a certificate instead of using a more conventional
CMS (PKCS-7) object, they are free to do so.  And if they wish to
standardize their cert extension, they should take their proposal to
an industry Multimedia-Intellectual-Property-Cryptographic-Protection
forum, not the PKIX working group.

-----------------------------------------------------------------------

SEQUENCE length = 282 {
    SET length = 17 {
        SEQUENCE length = 15 {
            OID 2.5.4.localityName(7)
            PrintableString "Internet"
        }
    }
    SET length = 23 {
        SEQUENCE length = 21 {
            OID 2.5.4.organizationName(10)
            PrintableString "VeriSign, Inc."
        }
    }
    SET length = 52 {
        SEQUENCE length = 50 {
            OID 2.5.4.organizationalUnitName(11)
            PrintableString "VeriSign Class 1 CA - Individual Subscriber"
        }
    }
    SET length = 70 {
        SEQUENCE length = 68 {
            OID 2.5.4.organizationalUnitName(11)
            PrintableString "www.verisign.com/repository/CPS Incorp. by 
Ref.,LIAB.LTD(c)96"
        }
    }
    SET length = 39 {
        SEQUENCE length = 37 {
            OID 2.5.4.organizationalUnitName(11)
            PrintableString "Digital ID Class 1 - Microsoft"
        }
    }
    SET length = 21 {
        SEQUENCE length = 19 {
            OID 2.5.4.commonName(3)
            PrintableString "John Citizen"
        }
    }
    SET length = 46 {
        SEQUENCE length = 44 {
            OID 1.2.840.113549.1.9.emailAddress(1)
            IA5String "[email-masked]"
        }
    }
}

---

From: [email-masked]
Date: Fri, 26 Mar 1999 15:28:36 -0500

Timothy Fisher wrote:

> I like the idea of "alterniatively-encoded" extensions.  I agree with
> Peter's rationale that a non-critical extension should not have to be
> ASN.1 encoded.  I also, would like to hear other opinions on this
> subject.

If ASN.1 included a type called NOTANY, I would agree. It does not. There
many be tools and applications that inspect a DER-encoded certificate in its
entirety. If ANY data is not ANY ASN.1 data, they may fail.

Frank Balluffi
CertCo

---

From: [email-masked]
Date: Fri, 26 Mar 1999 16:51:44 -0500

Since Extension.extnValue is an OCTET STRING, I am a little confused by this
thread, including Peter Williams's question:

> If a X.509 extension is proposed to IETF (PKIX) which is designed to
> be interpreted - by a binary-decoding based process
> other than ASN.1/DER - is there an objection in principle?

My below comment, referred to DER-encoding in general.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, March 26, 1999 3:29 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: "Alternatively-encoded" extensions

Frank Balluffi
CertCo