Subject: Re: Certicate Format Independence

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

Hi Tony,

See my comments below...

> At 03:46 PM 7/12/99 -0700, Aram Perez wrote:
> [tony-snips]
>
>>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?
>
> (Warning: Novice Lurker Commentary)
>
> Suppose I choose an encoder that displays input dates in dd/mm/yy format.

Do you mean a decoder?

> I encode the date "07/12/99" (7 Dec 99), producing a "proper blob".

That's part of the issue, what is a proper blob? Are there more than one
proper blobs? If yes, how do you transform one proper blob (DER) into
another proper blob (XML)?

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

Another part of the issue is the "proper blob" (a.k.a. bits-on-the-wire or
blob of bits) vs. the display format. What do you verify, the proper blob or
the dsiplay 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?

From an ideal point of view yes. But not in practice for several reasons:
Generally, what we are discussing are operations/processes performed by
machines and not humans. So both machines have to follow the same set of
rules/standards. The use of public key encryption based digital signatures
(that's a mouth-full ;-) requires that the verifier have the identical bit
stream as the signer (that's the reason that X.509 specifies DER rules and
not BER rules). So even though Sam understands that 07/12/99 means 7 Dec 99
and Ted understands that 12/07/99 also means 7 Dec 99, with respect to a
digital signature, 07/12/99 is not the same as 12/07/99.

Regards,
Aram Perez

---

From: Russ Savage <[email-masked]>
Date: Tue, 13 Jul 1999 08:54:33 -0700

(Caution: newbie comments)

I went to sleep last night thinking about this phrase "bits-on-
the-wire or blob of bits." And thinking how everything builds 
from "bits on the wire." Even back in the "old" days when I 
was learning Fortran using Hollerenth punch cards. A byte is 
bits on the wire but files, fields and records build on bytes in 
dozens of "standards" - EBCDIC, ASCII, Unicode, and so on. 
The point is that once you get past "bits," you are into blob-of-bits-
on-the-wire. I don't think it's either-or - it's both, meaning 
structured bits on the wire. The problem sounds to my newbie ears 
like trying to define byte, field and record all in one standard - after 
IBM, Digital, Apple and Microsoft have started selling divergent 
stuff.

Which is where I think the XML attraction comes from. But I 
agree that the bit/blob-on-the-wire standard should be neutral about 
the "program" that reads it (XML, Java, C++, who cares). My 
understanding of ANS.1/BER/DER is that there is a structure of 
objects where some are ambiguous about when, why and how they 
are used. Sounds a little like saying this is a byte which means this 
if its EBCDIC but that if its ASCII and this other if its Unicode. 
(I know it's more like a field in a record that we sometimes use &
sometimes ignore - depending on who "we" are - 
but play with me here)

Maybe there needs to be nested standards just as there are 
for byte types, which lead to different file types (PKIX 
profiles) with differing record and field types. If I use ASCII 
and I know the incoming file is in EBCDIC, then can I convert 
on the fly. The same could happen here with a decoder 
becoming a collection of objects and my decoder looks at the 
certificate, attempts to figure out the profile (format type) and 
run it through the appropriate decoding object. As it is, 
I have to do that anyway so why not tighten it up.

As a user of PKI, I'm less concerned about a single, global 
set of rules than I am about rules that are consistent over 
time. I need to be able to create a digital signature that will 
be legally enforceable for years regardless of the changes to 
the standard (or cert revocation, etc). To me that's a 
consistent data structure (a blob in a bit stream) that I can read 
on any platform using any decoder compliant with the data 
structure version the cert is in.

What that implies is a "gold standard" bit stream structure 
that any cert can be translated to and behave in a standard, 
consistent way. I doubt we can throw out ANS.1 at this point. 
(we at least would have to have backward compatible decoding)
But, from what I know, it definitely needs to be made less 
ambiguous. Even if that means flavors ala EBCDIC and 
ASCII in the byte world - if the cert is this flavor, then the bit 
stream consistently reads this way but if it is this other flavor, 
then it consistently reads this other way.

I agree with this statement: "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." It does not follow that 
there can only be one set of rules for all bit streams, 
merely that the rules for that particular bit stream structure 
be known (identifiable by the decoder) and consistently used 
(the decoder "knows" the rules to use for that structure).

My vote : the decode default is the mush we have now, 
but we build tighter structure(s) from here on out.

The question then is cross-certification - I think it's possible,
maybe even easier, if you have strictly defined sets of 
date/rules to compare - 
even if the rules are in two different profiles/structures.

Russ Savage
[email-masked]