Subject: RE: Comments on draft-ietf-pkix-ac509prof-05.txt

From: Carlisle Adams <[email-masked]>
Date: Mon, 16 Oct 2000 13:51:16 -0400

Hi Stephen,

> ----------
> From: 	Stephen Farrell[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Monday, October 16, 2000 1:03 PM
> To: 	[email-masked]
> Subject: 	Re: Comments on draft-ietf-pkix-ac509prof-05.txt
> 
> Looks like we disagree on this. This is the X.509 quote (I hope:-):
> 
>      "The signature on every certificate in the path must be verified.
> Procedures 
>      related to validating signatures and public-key certificates are not
> repeated 
>      in this clause. The privilege verifier must verify the identity of
> every entity 
>      in the path, using the procedures of clause 10. Note that checking
> the signature 
>      on an attribute certificate necessarily involves checking the
> referenced public-key 
>      certificate for its validity. Where privileges are assigned using
> attribute 
>      certificates, path processing engines will need to consider elements
> of both the 
>      PMI and the PKI in the course of determining the ultimate validity of
> a
>      privilege asserter's attribute certificate."
> 
> To me, that's prettly clearly saying: "check all PKC's involved" and
> nothing 
> about relationships between the different roots involved.
 
What it says is "verify the identity of every entity in the path, using the
procedures of clause 10."  The identities involved in the path are
represented by the holder's PKC (and all the CAs, if any, up to the root),
the AA's PKC (and those of all the AAs, if any, up to the SOA), and perhaps
the AA that signed the role certificate, if there is one (and all PKCs of
those AAs, if any, up to the SOA).

Now, does the text above mean that we take EACH of those entities above and
use the procedures of clause 10 to verify them, which may lead to multiple
PKIs?  Or does it mean that the whole collection of entities in the list
above all pertain to a single path (with respect to the authorization
decision), and so are all evaluated *collectively* according to clause 10,
which leads to a single PKI?

I suppose that, on its own, the text could be read either way.  However, all
the other places in the PMI text which talk only about "THE PKI" suggest to
me that only a single PKI is assumed.  Add to this the fact that having a
single PKI for all the entities involved in this authorization path can
eliminate the security hole, whereas having multiple PKIs absolutely cannot
eliminate this hole.  Add further the idea that it seems unreasonable for an
AA to issue certificates when it has no way of knowing whether any RPs will
be able to verify certificates in the particular set of multiple PKIs the AA
has chosen.  All of this, taken together, says to me that if the X.509 text
assumed anything at all on this issue, it assumed a single PKI.

Sure, the ACprof I-D can take no stance here, or can explicitly state that
multiple PKIs is the underlying model.  But why open up a potential security
hole when we don't need to (and then have to patch it using the sort of
extension that Polar suggested)?  The single-PKI (for all entities involved
in a given authorization path) model is not fundamentally any more limiting
than the multi-PKI model, but it is more secure, and it seems (to me) to be
more reasonable in terms of what an AA can expect RPs to know.  And (as I
keep saying) given that entities in two PKIs can't authenticate anyway
unless these PKIs are tied into one, I don't see what the objection is.

What exactly is the argument in favour of supporting multiple PKIs for this
purpose?  What problem does it solve?  What benefit does it bring?

Carlisle.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Oct 2000 19:20:43 +0100

Carlisle,

The text again:-)

     "The signature on every certificate in the path must be verified. Procedures 
      related to validating signatures and public-key certificates are not repeated 
      in this clause. The privilege verifier must verify the identity of every entity 
      in the path, using the procedures of clause 10. Note that checking the signature 
      on an attribute certificate necessarily involves checking the referenced public-key 
      certificate for its validity. Where privileges are assigned using attribute 
      certificates, path processing engines will need to consider elements of both the 
      PMI and the PKI in the course of determining the ultimate validity of a 
      privilege asserter's attribute certificate." 

> Now, does the text above mean that we take EACH of those entities above and use the procedures of
> clause 10 to verify them, which may lead to multiple PKIs?  Or does it mean that the whole
> collection of entities in the list above all pertain to a single path (with respect to the
> authorization decision), and so are all evaluated *collectively* according to clause 10, which
> leads to a single PKI?

That's the question all right. I read it as the former on the basis that it
doesn't say "collectively" or anything like it. If it did, you'd be right,
but it doesn't.

> [snip]...having a single PKI for all the entities involved in this authorization path
> can eliminate the security hole, whereas having multiple PKIs absolutely cannot eliminate this
> hole.  

Again, I disagree - I don't see how the existence of a cross certificate (compared
to the RP having two trustpoints) eliminates anything (not that there was anything 
to be eliminated in the first place:-). The cross-certificate *might* provide the RP 
with some better recourse in the event of a problem arising, but that's not a 
run-time issue, which is what we're discussing.

> What exactly is the argument in favour of supporting multiple PKIs for this purpose?  What problem
> does it solve?  What benefit does it bring?

It decreases the dependence between the PKI(s) and the PMI, which I
think is useful in practice, e.g. the "single" PKI model would mean that
certain RPs could not validate ACs without first getting the RP's
"local" PKI to issue cross certificates for the AA's and holder's PKI(s).
The issuance of such certificates is neither simple (procedurally), nor 
required, if the RP can safely configure in the relevant trustpoints.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 647 7406
61 Fitzwilliam Lane,                    fax: +353 1 647 7499
Dublin 2.                mailto:[email-masked]
Ireland                             http://www.baltimore.com