[x500standard] SV: [pkix] SV: [Spam] Re: DER encoding of certificates
- From: "Erik Andersen" <era@xxxxxxx>
- To: <x500standard@xxxxxxxxxxxxx>, "'SG17-Q11'" <t09sg17q11@xxxxxxxxxxxxx>, "'PKIX'" <pkix@xxxxxxxx>
- Date: Thu, 7 Jul 2011 13:27:01 +0200
I have come to the same conclusion. It is clear by now that the text is
already there (if you can find it). So what is needed is some text here and
there to clarify the issue.
During the August meeting we will try to come up with pieces of text to be
included in the next edition.
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: pkix-bounces@xxxxxxxx [mailto:pkix-bounces@xxxxxxxx] På vegne af
Santosh Chokhani
Sendt: 7. juli 2011 13:19
Til: x500standard@xxxxxxxxxxxxx; SG17-Q11; PKIX
Emne: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of certificates
I would say that the order of preference should be 3, 2, and 1.
-----Original Message-----
From: x500standard-bounce@xxxxxxxxxxxxx
[mailto:x500standard-bounce@xxxxxxxxxxxxx] On Behalf Of Erik Andersen
Sent: Thursday, July 07, 2011 2:44 AM
To: x500standard@xxxxxxxxxxxxx; SG17-Q11; PKIX
Subject: [x500standard] SV: [Spam] Re: DER encoding of certificates
Hi Steven, Santosh, and others
6.1 of X.509 the HASH information object states that
-- shall be the result of applying a hashing procedure to the DER-encoded
octets --
-- of a value of --ToBeHashed
The ENCRYPTED-HASH also states
-- shall be the result of applying a hashing procedure to the DER-encoded
(see 6.1) octets --
The SIGNATURE information object class refers to ENCRYPTED-HASH.
Already the 1988 edition required signatures based on DER encoding.
Clearly, the X.509 requires and have always required signatures to be
performed over the DER encoded data.
I have a problem with requiring the standard to take into account
non-conforming implementations. However, my proposal was partly a
provocation to see the reaction.
I see three possible solutions:
1) The decoding and re-encoding in DER as it has been discussed
2) Remove the DER requirements from 6.1 of X.509
3) Mandate use of DER encoding for certificates and other similar data
types. This would also include signed operations. Implementations will then
always perform signature check over the "blob" (which could be BER encoded).
We will still have non-conformant implementations, but they would work and
X.509 would be consistent.
For some peculiar reasons, Extensions shall always be DER encoded. This
requirement was introduced already in 1997, when the concept of extensions
was introduced.
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: Steven Legg [mailto:steven.legg@xxxxxxxxxxxxxxxxxx]
Sendt: 6. juli 2011 09:22
Til: x500standard@xxxxxxxxxxxxx
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DER encoding of certificates
Erik,
On 6/07/2011 4:34 PM, Erik Andersen wrote:
> Hi folks,
>
> In contrast to RFC 5280, X.509 does not require DER encoding. It only
requires that the signature is
> generated across a DER encoded certificate, but the itself certificate may
be encoded using BER.
>
> Should we add a sentence somewhere in X.509 and possibly in RFC 5280
specifying that when verifying a
> signature a relying party shall decode and then encode the certificate in
DER to verifying the signature?
That would cause more problems than it solves because all too often in
the real world signatures are calculated over the BER encoding that is
transmitted rather than the DER encoding it is supposed to be calculated
over.
Erik Andersen wrote:
> If the RDN is part of a primary distinguished name, the
primaryDistinguished
> component is TRUE and the valueWithContext shall not be included. If in
addition,
> the primaryDistnguished component is absent taking the default value, the
encoding
> of a 5280 certificate and the encoding of an X.509 certificate are
identical.
> However, if the primaryDistingished component is present and takes the
value TRUE,
> a X.509 certificate will be different from a 5280 certificate and may not
be
> accepted by all systems. Apparently, some tool will always add the
primaryDistingished
> component with the value TRUE.
Is this an observed problem or a theoretical one ? A decoder using the 5280
definition may well treat the AttributeTypeAndValue type as implicitly
extensible, in which case the primaryDistinguished component will be an
unknown extension that is gracefully ignored. The certificate couldn't be
re-encoded in DER, but that's not a wise thing to do anyway for the reason
above.
Regards,
Steven
>
> 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
>
-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.
_______________________________________________
pkix mailing list
pkix@xxxxxxxx
https://www.ietf.org/mailman/listinfo/pkix
-----
www.x500standard.com: The central source for information on the X.500 Directory
Standard.
Other related posts:
