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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 28 June 2006 22:20 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviOS-0001eL-Be; Wed, 28 Jun 2006 18:20:20 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FviOQ-0001eG-DB for tls@lists.ietf.org; Wed, 28 Jun 2006 18:20:18 -0400
Received: from ug-out-1314.google.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FviOP-0004FV-2i for tls@lists.ietf.org; Wed, 28 Jun 2006 18:20:18 -0400
Received: by ug-out-1314.google.com with SMTP id m3so18817uge for <tls@lists.ietf.org>; Wed, 28 Jun 2006 15:20:16 -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=tCzeJxb2ovF6PitEjPWWPGnjg8Ty7hrEXbq2D0Stxn0WJKmacCMLmCbdsHjSUhxB9A+nmAsL+mbNXmPiAQO06xaVifDZXEuVItyFWnrotK/MX2PA/L++EL27aPC8sKskFLI0jAyfnW+BjnbQE97ThK0V8/u0tx6NnlmYIdWpwoM=
Received: by with SMTP id v6mr1205284ugl; Wed, 28 Jun 2006 15:20:15 -0700 (PDT)
Received: from ? ( []) by mx.gmail.com with ESMTP id m1sm224651ugc.2006.; Wed, 28 Jun 2006 15:20:14 -0700 (PDT)
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Stephen Kent <kent@bbn.com>
Date: Thu, 29 Jun 2006 00:20:09 +0200
User-Agent: KMail/1.9.1
References: <20060626203923.59F81222426@laser.networkresonance.com> <200606270659.37003.nmav@gnutls.org> <p0623091bc0c6e270e1f7@[]>
In-Reply-To: <p0623091bc0c6e270e1f7@[]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200606290020.10111.nmav@gnutls.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
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 Wed 28 Jun 2006 15:48, Stephen Kent wrote:

> >How would you support this?
> Each relying party is allowed to select the CAs that it views as
> trust anchors. As a result, different RPs may have differing views of
> the same PKI.  Because a CA may have its key cross certified by
> multiple other CAs, it is possible to create cert paths that
> terminate at different trust anchors, depending on what TAs a given
> relying party selects. All of these observations say that X.509 and
> PKIX are NOT strictly hierarchic.

Ok I see your point. I also noticed that hierarchical is used in several 
RFCs, to specify a specific form of hierarchy. So since this term is 
already common for this, would something like the following change
address your concerns?

   At the time of writing, TLS [TLS] uses the PKIX [PKIX]
   infrastructure, to provide certificate services.  Currently the PKIX
   protocols are limited to a structured certification model where only
   specific participants, the Certificate Authorities, are allowed to
   express trust. As a result, applications which follow more complex
   trust models, such as the web of trust, could not be benefited by  

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

> TLS is the IETF version of SSL.  SSL, like PGP (vs. OPGP) was not
> born in a standards environment, but rather existed prior to IETF
> involvement. The description of how to use the ID data from an X.509
> cert to provide authentication for a web server is an important part
> of the semantics of SSL and TLS. 

I disagree with that. Why do I have to cope with HTTP? I didn't write
this extension to use openpgp keys with web browsers. Sure this could be
done, but then the ones that need this functionality should write the
rules. I am not interested in that.


TLS mailing list