[x500standard] Re: [pkix] [Spam] Re: DER encoding of certificates
- From: Santosh Chokhani <SChokhani@xxxxxxxxxxxx>
- To: Phillip Hallam-Baker <hallam@xxxxxxxxx>, Peter Sylvester <peter.sylvester@xxxxxxxxxx>
- Date: Thu, 7 Jul 2011 09:10:42 -0400
Phillip,
So, you are saying, do not transmit the payload; do not reassemble the pay and
do not require to do DER.
Whow.
From: pkix-bounces@xxxxxxxx [mailto:pkix-bounces@xxxxxxxx] On Behalf Of Phillip
Hallam-Baker
Sent: Thursday, July 07, 2011 8:11 AM
To: Peter Sylvester
Cc: x500standard@xxxxxxxxxxxxx; SG17-Q11; PKIX
Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates
Removing a DER requirement is perfectly fine by me.
Removing the requirement that the encoder emit the bit stream that was signed
is the issue. That would be totally ridiculous
* X.500 is obsolete. No matter what the technical merits there is no example in
our industry of a 20 year old technology that has had minimal success eclipsing
a successor.
* Even LDAP is of limited use unless an enterprise writes its own applications
to pull information from it.
* Breaking a cert up to store the attributes in a directory and then
reassembling is guaranteed to fail. It was nonsense when first proposed
If we made any change here at all it should be to require applications to
accept PKIX certificates that are encoded using any valid BER encoding and drop
mention of DER altogether. I believe that this has been the defacto requirement
in any case.
On Thu, Jul 7, 2011 at 5:14 AM, Peter Sylvester
<peter.sylvester@xxxxxxxxxx<mailto:peter.sylvester@xxxxxxxxxx>> wrote:
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<tel:%2B45%202097%201490>
e-amail: era@xxxxxxx<mailto: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<mailto: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<tel:%2B45%202097%201490>
e-amail: era@xxxxxxx<mailto:era@xxxxxxx>
Skype: andersen-erik
http://www.x500.eu/
http://www.x500standard.com/
http://dk.linkedin.com/in/andersenerik
_______________________________________________
pkix mailing list
pkix@xxxxxxxx<mailto:pkix@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix mailing list
pkix@xxxxxxxx<mailto:pkix@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/pkix
--
Website: http://hallambaker.com/
Other related posts:
