Re: [keyassure] Interpreting certificates (and summary)

BER encoding is supported by practically every ASN.1 library. It is
identical semantically to DER which is a pain in the patootie.

>From a drafting perspective, I would first state that the identifier
corresponds to an X.509v3 cert without mentioning encoding at all.

Then I would follow that with a statement that the TLS protocol requires
certificates to conform to the X.509v3 requirement for DER encoding and the
requirements of the PKIX certificate profile.

Specifying X.509v3 in DER encoding may appear to be more precise and less
ambiguous, but might well actually introduces ambiguity since another
interpretation of the statement is that there should be an additional ASN.1
structure wrapping the cert.

On Wed, Feb 23, 2011 at 1:57 PM, Martin Rex <mrex@sap.com> wrote:

> Scott Schmit wrote:
> >
> > An item for security considerations:
> > * Now that CAs aren't necessarily issuing these certs, the client needs
> >   to be much more careful in its parsing (the null terminated vs length-
> >   delimited string bug comes to mind)
>
> This sounds somewhat strange to me.
>
> When doing TLS authentication of a peer, the peer's certificate
> is always untrusted at the time when it is parsed.  Parsing the
> received X.509 cert is a prerequisite to being able to validate
> the cert and determining whether it is trusted/trustworthy or not.
>
> An ASN.1 parser that is not careful is an unconditionally bad idea
> and asking for trouble; lots of trouble.  Tolerance to common
> bugs of encodings produced by peers should never be accepted
> "by accident", only by conscious trade-off decisions that are
> clearly documented for the caller/consumer of the technology.
>
>
> -Martin
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
>

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