Re: DER encoding in RFC 3161
Phillip Hallam-Baker <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <CAMm+LwhdgfkbwXrfX8yiK3UDJRGOGzMJ2mXuyKqZWTdGbBE6gQ@mail.gmail.com> |
I have been doing X.509v3 for 30 years now. I have yet to hear a good answer to the question of why DER encoding is needed in PKIX. It is a requirement of X.509 but not one that makes the slightest sense in these days when you can store a billion certs on one disk drive and X.500 directory has fewer active users than Edison phonographs. Certificates are moved from point A to point B as an opaque binary blob which is encoded by the signer at signing time and only at signing time. This notion of signing the abstract data rather than the binary bits keeps coming up but I have yet to see anyone work out how to do it reliably, let alone add value by doing so. A digital signature is over a string of bits. The road to madness is paved by canonicalization schemes. It is sufficiently possible that there are ASN.1 parsers there that insist on strict DER with definite length encoding throughout that changing PKIX to allow BER encoding would now be a breaking change. And the same argument can be made for cases where BER encoding is indicated. So at this point, the best thing we can do is to just accept that the spec is going to be ugly and not try to fix it. On Tue, Jul 28, 2020 at 3:58 AM Koichi Sugimoto <koichi.sugimoto= [email protected]> wrote: > Hello PKIX members, > > > > RFC 3161 specifies “The eContent SHALL be the DER-encoded value of > TSTInfo.” in “2.4.2. Response Format” > > Why RFC 3161 does not require DER-encoded value for full time-stamp token > (CMS data)? > > > > On the other hand, following protocol encoding seems to require all > DER-encoded for entire time-stamp message. > > > > 3.1. Time-Stamp Protocol Using E-mail > > 3.2. File Based Protocol > > 3.3. Socket Based Protocol > > 3.4. Time-Stamp Protocol via HTTP > > > > This seems time-stamp token requires DER-encoded indirectly. > > > > Regards, > > Koichi Sugimoto. > > > _______________________________________________ > pkix mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/pkix > _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix