[x500standard] SV: [Spam] Re: DER encoding of certificates
- From: "Erik Andersen" <era@xxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>, "SG17-Q11" <t09sg17q11@xxxxxxxxxxxxx>
- Date: Thu, 7 Jul 2011 10:49:00 +0200
Hi David,
Thanks for pointing this out. This actually is in line with my suggestion 3), I
sent out a little while ago. As we can assume that a creator of a certificate
and similar data types know the abstract syntax of all the fields, it should be
stated clearly that DER encoding shall be used in such cases.
Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: era@xxxxxxx
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
-----Oprindelig meddelelse-----
Fra: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] På vegne af David Wilson
Sendt: 6. juli 2011 11:08
Til: x500standard@xxxxxxxxxxxxx
Emne: [Spam] [x500standard] Re: DER encoding of certificates
On Wed, 2011-07-06 at 16:48 +1000, Ramsay, Ron wrote:
>
> Maybe I’m trying to turn back time, but common sense would dictate
> that the signature should apply to the blob it is attached to, even if
> that blob doesn’t follow the DER rules. The notion that you have a
> signature to a blob which you don’t have, and can’t obtain, but for
> which you have a hint that should enable you to construct that blob,
> is a bit weird.
Actually, that is precisely what X.509 says. At the end of the section
for SIGNED:
"The Directory shall follow these rules:
– It shall preserve the encoding of received information whose abstract
syntax it does not fully know and which it expects to subsequently sign;
– When signing data for sending, it shall send data whose syntax it
fully knows with a distinguished encoding and any other data with its
preserved encoding, and shall sign the actual encoding it sends;
– When checking signatures in received data, it shall check the
signature against the actual data received rather than its conversion of
the received data to a distinguished encoding."
So, the signer should be as strict as possible, but the verifier does
not re-encode.
(Also, this section does not specify DER, but a restricted BER. This has
fewer constraints than DER. The need in DER to have a canonical form of
the data within ISO 2022 encoded character strings is an example.)
David
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
