[x500standard] Re: [pkix] [Spam] Re: DER encoding of certificates
- From: Phillip Hallam-Baker <hallam@xxxxxxxxx>
- To: Erik Andersen <era@xxxxxxx>
- Date: Thu, 7 Jul 2011 08:16:15 -0400
I chose 4 or 5:
4) Eliminate the DER encoding requirement completely
5) Do nothing at all
PKIX is written to serve the needs of Internet applications. Canonical
encoding of certs has no value for those applications.
On Thu, Jul 7, 2011 at 2:44 AM, Erik Andersen <era@xxxxxxx> 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
> 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
> >
>
> _______________________________________________
> pkix mailing list
> pkix@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/pkix
>
--
Website: http://hallambaker.com/
Other related posts:
