[x500standard] Re: [pkix] [Spam] Re: DER encoding of certificates
- From: Peter Sylvester <peter.sylvester@xxxxxxxxxx>
- To: Erik Andersen <era@xxxxxxx>
- Date: Thu, 07 Jul 2011 14:57:26 +0200
Hi all.
removing a DER requirement is unacceptable. Most implementations tolerate
certain deviations from DER (the second half of point a below for example)
are probably not prepared to handle a violation of the first part of
point a.
I think the following text in X/509 is sufficiently clear (assuming that
we are all in THE directory):
In 6.1 : (draft version 2008):
Generating a distinguished encoding requires the abstract syntax of the
data to be encoded to be fully understood. The Directory may be required
to sign data or check the signature of data that contains unknown
protocol extensions or unknown attribute syntaxes. 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.
== too bad that this doesn't work if one wants to work with XER only.
The text above in 6.1 (with comments inline)
SIGNED { ToBeSigned } ::= SEQUENCE {
*toBeSigned ToBeSigned,*
*COMPONENTS OF SIGNATURE { ToBeSigned } }*
In order to enable the validation of *SIGNED* and *SIGNATURE* types in a
distributed environment, a distinguished encoding is required.
PS: == a distinguished encoding is only required if one decodes and
reencodes which is not
what is recommended later. Nevertheless, this is not a reason to remove the
requirement for the encoding and open it to an arbitrary BER.
A distinguished encoding of a *SIGNED* or *SIGNATURE* data value shall
be obtained by applying the Basic Encoding Rules defined in ITU-T Rec.
X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions:
a) the definite form of length encoding shall be used, encoded in the
minimum number of octets;
b) for string types, the constructed form of encoding shall not be used;
c) if the value of a type is its default value, it shall be absent;
d) the components of a Set type shall be encoded in ascending order of
their tag value;
e) the components of a Set-of type shall be encoded in ascending order
of their octet value;
f) if the value of a Boolean type is true, the encoding shall have its
contents octet set to "FF"16;
g) each unused bit in the final octet of the encoding of a Bit String
value, if there are any, shall be set to zero;
h) the encoding of a Real type shall be such that bases 8, 10, and 16
shall not be used, and the binary scaling factor shall be zero.
i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690
(2002) | ISO/IEC 8825-1:2002;
j) the encoding of a Generalized time shall be as specified in ITU-T
Rec. X.690 (2002) | ISO/IEC 8825 1:2002.
PS: == the points above are just a description of DER? This part of the
text shouldn't be there and simply reference DER (which is actually done
in the comments like in
*ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {*
/-- shall be the result of applying a hashing procedure to the
DER-encoded (see 6.1) octets --/
*/-- of a value of -- ToBeSigned -- and then applying an encipherment
procedure to those octets -- /})
*
A very bad style to define meaning in comments IMO (without doing it in
the text).
On 07/07/2011 08:44 AM, Erik Andersen wrote:
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
X.509 does not require this and recommends against. (see above)
2) Remove the DER requirements from 6.1 of X.509
This will break any conformant and strict verifiers,
and many tolerant verifiers.
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).
Isn't that exactly what X.509 says.
We will still have non-conformant implementations, but they would work and
X.509 would be consistent.
Consistency and compatibility in time is not exactly where X standards
are the best. (x400 84 vs 88, well that's old)
recent X.509 keyusage changes breaks XER decoders
(Non Repudiation vs Contentcommitment).
Since two names are allowed for the same bit there is no longer
a distinguished XML encoding possible.
For some peculiar reasons, Extensions shall always be DER encoded. This
requirement was introduced already in 1997, when the concept of extensions
was introduced.
It is for exactly the same reason, to have a distinguished encoding.
With extensions it has become even impossible to decode
them and reencode completely.
regards
Peter Sylvester
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
_______________________________________________
pkix mailing list
pkix@xxxxxxxx
https://www.ietf.org/mailman/listinfo/pkix
Other related posts:
