Subject: "Alternatively-encoded" extensions

From: "Peter Williams" <[email-masked]>
Date: Sat, 24 Apr 1999 11:02:00 -0500

Steve,

Lets us establish principles, so PKIX is fair, non-arbitrary,
and rule-based. Im more interested in the principles
for use of "alternatively-encoded objects" in certs, than whatever
Anders was contemplating, for context.

 Interestingly, in the VeriSign trust domain, there is/was already
an implicitly MIME-encoded object (text/plain) - be this
sensible or nay - in certificates, whose
profile and issuing practices is/are licensed
and accredited by a US state authority and a Big 6 firm, one
may note. Said content is/was an X.509 extension.

One  could argue the object is actually an implicitely encoded SMTP-body if
you
prefer, or a SGML-tagged <PRE> element - it does not matter for
the argument - it ain't BER-encoded or an ASN.1-specified object
or string. There are/or at least were a few hundred thousand of such
certificates floating out there, today. Nothing has broken to my knowledge,
including interaction with S/MIME. The Internet world today is largely happy
to
accept certs with unknown, non-critical extensions, even large ones.

(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.)

But let me ask the question, a different way, and propose an example
and a concluding argument, so we might establish the principle :

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?

For example, CompanyX patented a (binary-encoded)
extension for certs  designed to be intepreted by
multimedia hardware. The content of the extension was
a simple state-machine language which drove the multimedia capability
of the chip, which leveraged public key cryptography to perform
certain cert-based protection functions for multimedia content/capabilities
based on the cert subject's identity, as authenticated using certificates.

Now, I know X.509 and the various national standards bodies making up ISO
does/do not object to string-encoded objects embedded in octet-string
extensions, per se.

Do PKIX WG managers, and the IESG? Nothing in 2459 suggests
such an interpretation. 2459 suggests quite the opposite, in fact.

My conclusion is: a minimally-conforming PKIX 2459
implementation should not reject a cert because of
an unknown (non-critical) extension, unless other signals such
as a policy (known to the implementation) requires extension-type and
schema and extension value-constraint checking for
cert validity, or subsequent digital signature verification.

-----Original Message-----
From: Stephen Kent <[email-masked]>
To: Peter Williams <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Wednesday, March 24, 1999 9:38 AM
Subject: Re: Biometrics in Qualified Certificates

Peter,

>You may wish to define a name form for the alternative subject name
>extension, as permitted by X509 and PKIX. Its form can be
>a MIME-encoded name, an SMTP-extended address field, etc.
>
>My reading of PKIX-1 is that implementations receving such
>a field should not balk at its mere inclusion, unless the security
>policy (or CertPolicyId or KeyUsageRestriction) they are enforcing
>is more strict than RFC 2459 regarding the extension and
>extension-value schema rules.

Yes, one could do what you say, Peter, but it seems to make no sense to use
any MIME encoding here, given the binary nature of certificates.  Thus, the
WG co-chair would not view such a proposal as appropriate, unless you can
provide some good rationale for it.  Extensible syntax is not a license to
do silly things; we always need a good rationale for adding extensions,
name forms, etc.

>As for your
>>second query, my position is that it is a bad idea to put such information
>>into a public key certificate.
>
>X.509 supports the idea that an opaque data field created by
>the Naming Authority be conveyed in a public-key certificate,
>to engender assurances relevant to uniqueness of
>(subject) naming (vs key certification) quality.
>
>"A certification authority produces the certificate of a user by signing
>(see clause 9)
>a collection of information, including the user’s distinguished name and
>public key, as well
>as an optional unique identifier containing additional information about
the
>user. The exact
>form of the unique identifier contents is unspecified here and left to the
>certification
>authority and might be, for example, an object identifier, a certificate, a
>date, or some
>other form of certification on the validity of the distinguished name. "

But the argument that has been made here is not the use of this data for
further qualification of a user DN; it is "let's find a place in a cert to
put some data we think might be useful in some application contexts."

Steve

---

From: Timothy Fisher <[email-masked]>
Date: Thu, 25 Mar 1999 14:15:12 -0700

Do Object Identifiers exist for the various PKIBody message types?

For example, the Object ID for the PKCS7-SignedData type is:
1.2.840.113549.1.7.2

Is there any such IDs for the PKIBody types, such as the CertReqMessage,
or the CertRepMessage?

Thanks,
Timothy Fisher

---

From: Timothy Fisher <[email-masked]>
Date: Fri, 26 Mar 1999 08:42:44 -0700

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.

Timothy Fisher

---

From: Stephen Kent <[email-masked]>
Date: Fri, 26 Mar 1999 11:35:51 -0500

Peter,

>Anders was contemplating, for context.

PKIX is a WG and operates on a rough concensus basis, as judged by the WG
chair(s), subject to adjudication by the IESG and IAB, when necessary. As a
WG chair I consider inputs from WG members in forming an opinion, and I
weigh technical and architectural considerations, based on my judgement.
Hopefully, the judgement that WG chairs employ as part of this process is
not arbitrary, though it is not codified in a simple rule set.

>may note. Said content is/was an X.509 extension.

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.

>accept certs with unknown, non-critical extensions, even large ones.

One could interpret encodings in this fashion, but I fear one would be
engaging in sophistry.  In my mind, pre-existing bad practices do not
justify codification, nor should they be used to justify future bad
practice.

>is useful in a very particular application context, and for specific (legal)

See my comments on that extension above.

>other than ASN.1/DER - is there an objection in principle?

Unless there are very persuasive, extenuating circumstances, yes.  Certs
are binary objects that have to be DER encoded for signing and there needs
to be very good reason to deviate from the model presented in X.500.

>based on the cert subject's identity, as authenticated using certificates.

Since this is a patented encoding, I would not suggest that PKIX consider
such an extension for standardization. I suggest that Company X get an OID
for a private extension.

>such an interpretation. 2459 suggests quite the opposite, in fact.

Strings are fine represetnations when they represent a natural base
encoding for the data in question.  The JPEG exmample we were debating
clearly fails this test.

>cert validity, or subsequent digital signature verification.

I would not disagree with this statement, but it also does not seem to be
especially relevant to the ongoing debate.

Steve