Subject: Re: Certicate Format Independence

From: "Aram Perez" <[email-masked]>
Date: Mon, 12 Jul 1999 15:46:15 -0700

Hi Todd,

I really didn't think anyone would respond (I was trying to be facetious).
Please see my comments below...

[snip]
>> (used to be RE: ASN.1 vs XML (used to be RE: I-D
>> ACTION:draft-ietf-pkix-scvp-00.txt)), etc.
>>
>> Having been beat up over algorithm independence (and maybe the beating
>> isn't allowing me to think clearly), IETF should support format
>> independence for certificates.
>>
>> :-),
>> Aram Perez
>>
>
> Aram, Don't we already have that though?.

I do not think so, otherwise there would not be this flurry of postings on
this issue.

>
> The standard is set at the BER/DER encoding of the X.509 data structure
> represented in the ASN.1 Structure Standard. Anyone that wants to encode to
> the standard represented can chose to do so at either  the source level
> structure or  the "resolved" binary cert token, it should be up to their
> applications.
>
> There cert structure represents the greatest common denominator between a
> number of use models and that's why its the right standard as a crossing
> point in PKI systems. This places the level of interoperability of the trust
> processes at the data structure of the cert token. By the way, time and
> event stamps should be the same way, that is as datastructures rather than
> service API's or Protocol Models..
>
> meanwhile back to the rant - So the XML issue is really a question of  "can
> I represent the same structures in XML as I can in ASN.1?", and the answer
> is obviously "Yes"...

I won't disagree your concept of "data structures". I do not think the issue
is the data structure or whether I can "represent the same structures in XML
as I can in ASN.1". The issue is "How do I get the same bit stream to verify
the data structure that you signed?" In order for the data structure to be
verified, the verifier needs the same bit stream as the signer used. That is
why using BER (as someone earlier suggested) is wrong, because BER allows
more than one bit stream to represent that same value.

>
> My feeling here is that the stumbling block is that we are getting hung up
> on what it is we are standardizing here -  is it the blob of bits as
> processed through some encoder or resolver or is it the data structure that
> you feed into the resolver... or is it both? These are the questions that
> must be answered for this conversation to really make sense and these are
> relatively simple questions to answer.

I believe it is both. And while your questions may be "relatively simple
questions to answer", the answers certainly are not simple. What is supposed
to happen if you put in "07/12/99" to your encoder but I input your "blob of
bits" to my decoder I get "7/12/1999"? And does "07/12/99" represent July
12, 1999 or December 7, 1999?

>
> If the standards are about the data structure that represent the entities
> (certs) as raw binary, then the fact that they are made human readable by
> writing them in ASN.1 is irrelevant to the standard structure except as a
> reference notation. It becomes a nicety done purely for the reader's comfort
> and nothing more.
>
> If what is being standardized is that the X.509 cert is a ASN.1 represented
> structure as processed by a "Standardized" BER or DER compliant encoder,
> then we are stuck with ASN.1 and the encoders. But I think that what is
> being standardized is a binary token that happens for the use of the
> "standards" documents to refer to the data structures in ANS.1 for my
> reading ease. Nothing more. That makes the real issue here only one of
> whether someone wants to step to the plate and write a binary compiler ala a
> DER encoder for XML and the preprocessor/rules process to convert the XML
> structures into the appropriate ASN.1 compiled outputs.

I don't think is quite that simple. See my previous comments above.

Regards,
Aram Perez

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 12 Jul 1999 16:40:06 -0700

At 03:46 PM 7/12/99 -0700, Aram Perez wrote:
[tony-snips]

>12, 1999 or December 7, 1999?

(Warning: Novice Lurker Commentary)

Suppose I choose an encoder that displays input dates in dd/mm/yy format.
I encode the date "07/12/99" (7 Dec 99), producing a "proper blob".

The blob gets signed.  The blob gets received by two users Sam and Ted.
The blob gets verified by each.

Sam prefers a decoder that displays dates in dd/mm/yy format, while
Ted prefers a decoder that displays dates in mm/dd/yy format.

So... Sam sees the blob as 07/12/99, and understands this as 7 Dec 99.
and   Ted sees the blob as 12/07/99, and understands this as 7 Dec 99.

All is well, assuming Sam and Ted (and I) understand the encode/decode
interpretation to be supplied (and trust the encoders/decoders.)

Is this how its supposed to work?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL