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

[Nikos Mavrogiannopoulos <[e-mail]>]

On Thu 29 Jun 2006 15:43, 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.
>
> That's better, but it still is pejorative and technically inaccurate
> in its characterization of X.509/PKIX.  Let me say why.
> 	- a CA is a Certification Authority, not a Certificate
> Authority, as per all the X.509 and PKIX standards.

Corrected, thanks .

> 	- anyone can be a CA, as my Windows XP example shows, so it
> is unfair to suggest that the ability to ba a CA is somehow limited.
> Thus the situation in X.509/PKIX is more or less the same as in OPGP,
> i.e., if you can get other folks to "trust" you as a signer of certs,
> then you can be a CA, period.  The fact that the major, highly
> visible, commercial CAs have established themselves as
> widely-accepted trust anchors is not an intrinsic feature of
> X.509/PKIX PKI standards. Anyone is free to configure any set of TAs
> they want, as a purely local decision, just as OPGP users are free to
> decide who they trust and to what extent.

There a lots of practical issues that make the PKIX certificates 
unusable in "web of trust" implementations, and this is my point.
Some of them are:
* there is only one issuer per certificate
* revocation is a capability of the issuer only
and could be even more (given that X.509 was designed to support
a hierarchically structured directory).

Thus even if could be possible to implement web of trust with X.509 
certificates, I'd need to send everytime n certificates (the number of 
the signers of my key), and I would not be able to revoke my key unless 
all of my signers agreed (discarding the fact that they'd need to 
publish a crl periodically :)

This I believe makes the scheme impractical to use as a basis for a 
decentralized system such as the web of trust. (and I would consider it  
an abuse rather than a normal use of PKIX)

Maybe in the future there are extensions to the PKIX to allow for the 
web of trust. But I'm describing the current situation.

> considerations section. In particular, you should note that use of
> PGP certs with an application will require a document analogous to
> 2818 to explain how to use the certs being transported.

Maybe the wording wasn't clear. Would an update to the security 
considerations text like the one below be more clear to you?

         Security considerations about the use of the web of trust or
         the key verification procedure are outside the scope of this  
         document and are considered issues to be handled by the 
         application layer protocols.


regards,
Nikos


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls