Re: [keyassure] Interpreting certificates (and summary)

[Martin Rex <[e-mail]>]

It seems were quoting / replying to the wrong mail.

Phillip Hallam-Baker wrote:
> 
> 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.

I don't think that mentioning the encoding creates a problem.  My main
concern at this point was about "DER" alone rather than "ASN.1 DER".


> 
> 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.

Which is pretty much plain wrong.  ;-)

Nothing in TLS precludes the use of X.509v1 certs,
The last sentence of Section 1 of all TLS documents (2246,4346,5246) reads:

                         The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

Which clearly explains that PKIX is just one possible approach to
interpreting the certificates exchange -- and definitely not the
only one.

Similarily, RFC-2818, the informational RFC which describes how
"HTTP Over TLS" is commonly performed says this:

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.)

Which describes a case where the TLS server certificate matching
is a PKIX-free memcmp() on X.509 certificates.


> 
> Specifying X.509v3

If you keep sticking the v3 onto X.509, then you're creating
a necessity for a bare public key format.

While I'm pretty sure that self-signed end-entity X.509v1 certs
interoperate with all TLS implementations I've tested, I'm not aware
of a definition of a self-signed EndEntity X.509v3 cert (that isn't
in conflict with some version of 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.

If there was a wrapping ASN.1 structure, it would be named and its
ASN.1 definition appear in an Appendix of the document.  I don't think
that the document will grow the necessary level of ambiguity for this
to happen.

-Martin