[TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt

On Mon 26 Jun 2006 22:31, Eric Rescorla wrote:

Hello,
 Thank you for the comments. They are addressed below.

> >Date: Mon, 26 Jun 2006 16:03:48 -0400
> >To: iesg@ietf.org
> >From: Stephen Kent <kent@bbn.com>
> >Cc: Stephen Kent <kent@bbn.com>
> >Subject: problems with  draft-ietf-tls-openpgp-keys-10.txt
> >
> >
> >This I-D contains an error in its characterization of X.509 certs,
> >as per RFC 3280, the IETF profile for these certs developed by the
> > PKIX WG.
> >
> >The text in the Introduction says:
> >
> >    Currently the PKIX
> >    protocols are limited to a hierarchical key management and as a
> >    result, applications which follow different - non hierarchical -
> >    trust models, could not be benefited by TLS."
> >
> >This is wrong. Neither X.509 nor PKIX restrict PKIs to be
> > hierarchic.

How would you support this? 

My understanding from reading the overview rfc3280:

   "Following is a simplified view of the architectural model assumed by
   the PKIX specifications.

   The components in this model are:

   end entity: user of PKI certificates and/or end user system that is
               the subject of a certificate;
   CA:         certification authority;
   ..."

and by the fact that only one issuer per certificate is allowed, makes 
clear to me there is a hierarchy of certification. Is there an example 
of a non-hierarchic PKIX deployment?

> >The Security Considerations section says:
> >
> >    Security considerations about the use of the web of trust or the
> >    verification procedure are outside the scope of this document
> > and they are considered an issue to be handled by local policy.
> >
> >The use of server certs with TLS is specifically designed to allow a
> >client (e.g., browser) to verify that the server identity expressed
> >in a URL is consistent with the subject identity expressed in the
> >cert, as a form of automated authentication. This authentication
> >technique is not perfect, but it is reasonably well understood by
> >the community.  RFC 2818 describes the checking to be performed for
> >server (and client) authentication based on X.509 syntax and this
> >document should do the same.

RFC2818 is a document that proposes a way on how to use HTTP over TLS. 
This is not the purpose of this document.

In more detail, you could see this is as an update of the TLS 
specification which handles the technical issues of establishing a 
secure connection. It doesn't mention anything about how to verify 
certificates, because this is at the application level scope.

regards,
Nikos

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls