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

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 27 Jun 2006 06:59:35 +0200

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: [email-masked]
> >From: Stephen Kent <[email-masked]>
> >Cc: Stephen Kent <[email-masked]>
> >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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Anyang Ren" <[email-masked]>
Date: Wed, 28 Jun 2006 08:15:11 -0700

> of a non-hierarchic PKIX deployment?

Although only one issuer per certificate is allowed, an end entity can
get multiple certificates from different CAs.

CAs can also issue certificates to each other (cross-certification).

-- 
Anyang Ren
Open source developer

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 29 Jun 2006 00:20:09 +0200

On Wed 28 Jun 2006 15:48, Stephen Kent wrote:

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

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

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Jun 2006 15:38:17 -0700

> rules. I am not interested in that.

I think I have to agree with Nikos here. TLS (2246 and 4346) are
deliberately agnostic about how to determine whether a certificate
matches the expected client or server. That is relegated to 
the upper layer protocol, in the case of HTTP it's described
in RFC 2818. So, I don't think that the document in question
needs to specify this.

-Ekr