Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates

[Phillip Hallam-Baker <[e-mail]>]

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
<[e-mail]>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: [phone]
> e-amail: [e-mail]
> Skype: andersen-erikhttp://www.x500.eu/http://www.x500standard.com/http://dk.linkedin.com/in/andersenerik
>
>
> -----Oprindelig meddelelse-----
> Fra: Steven Legg [mailto:[e-mail] <[e-mail]>]
> Sendt: 6. juli 2011 09:22
> Til: [e-mail]
> 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: [phone]
>
> e-amail: [e-mail]
>
> Skype: andersen-erik
> http://www.x500.eu/
> http://www.x500standard.com/
> http://dk.linkedin.com/in/andersenerik
>
>  _______________________________________________
> pkix mailing [e-mail]://www.ietf.org/mailman/listinfo/pkix
>
>
>
> _______________________________________________
> pkix mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>
>


-- 
Website: http://hallambaker.com/