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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Tue, 27 June 2006 04:59 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv5fs-0007Qq-S2; Tue, 27 Jun 2006 00:59:44 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv5fr-0007Qh-0I for tls@lists.ietf.org; Tue, 27 Jun 2006 00:59:43 -0400
Received: from ug-out-1314.google.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv5fp-0001gw-LS for tls@lists.ietf.org; Tue, 27 Jun 2006 00:59:42 -0400
Received: by ug-out-1314.google.com with SMTP id m3so1334242uge for <tls@lists.ietf.org>; Mon, 26 Jun 2006 21:59:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=L46Qg5wws1sBuC9vsuch7ab6qak9qQaVDOslQJEmURmULZp/4nRtGhaWLcnAEHutqKaHvVNU0AY6oXcbbFSU4GxkdeUvjKpYF1nKd1btn7nLb4M6pJn8RYgYCnqsuLFTxN4lwYr9w+LkUe1TaTiGVbvRgDq2iPU6lQAHp1/A2bY=
Received: by with SMTP id b13mr5673851ugj; Mon, 26 Jun 2006 21:59:40 -0700 (PDT)
Received: from ? ( []) by mx.gmail.com with ESMTP id k2sm5621626ugf.2006.; Mon, 26 Jun 2006 21:59:40 -0700 (PDT)
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Stephen Kent <kent@bbn.com>
Date: Tue, 27 Jun 2006 06:59:35 +0200
User-Agent: KMail/1.9.1
References: <20060626203923.59F81222426@laser.networkresonance.com>
In-Reply-To: <20060626203923.59F81222426@laser.networkresonance.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200606270659.37003.nmav@gnutls.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: tls@lists.ietf.org
Subject: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

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

 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.


TLS mailing list