Subject: Cross-organizational ACs

From: Steve Hanna <[email-masked]>
Date: Tue, 14 Nov 2000 17:20:28 -0500

I have recently confirmed with the ac509 authors that they did not mean
to prohibit an AC verifier from trusting multiple AC issuers for a given
attribute. They are planning to change the text in section 1.1 to make
this clear. This should provide more flexibility for organizations that
want to run multiple AC issuers.

However, I still think there are several unresolved issues with
cross-organizational ACs (where the issuer and the verifier are in
different organizations, especially with limited trust).

1) As Anders pointed out, in the pull scenarios the AC verifier may not
   know where to get an AC issued by another organization. We could add
   a pointer in the PKC saying how to get ACs for the subject, but I
   suspect that won't work very well due to the political and technical
   issues raised by Bob Jueneman. In all likelihood, pull scenarios
   will only use ACs from the verifier's organization.

2) With cross-organizational ACs, the AC verifier should not need to be
   configured with a complete list of trusted AC issuers. Otherwise,
   all AC verifiers will need to be updated whenever the list of
   trusted organizations changes. This would be especially bad with
   S/MIME, since each email client is an AC verifier.

   This problem can be addressed with the AAControls extension. The
   verifier trusts one or more AA CAs (probably run by their own
   organization). These AA CAs issue PKCs with the AAControls
   extension, vouching for AC issuers or other AA CAs. The AAControls
   extension includes constraints on the path length to an AC issuer or
   the attribute types that may be issued.

   Unfortunately, I suspect that these constraints will not be
   sufficient for most organizations. For instance, one organization
   may trust another to issue ACs containing the Group attribute, but
   only for certain groups. Or they might trust them to issue ACs with
   the Clearance attribute, but not for the topSecret class.

   If we were using delegation (a la X.509 2000), this could be handled
   by domination rules. At the risk of opening a huge can of worms,
   I'll inquire why we're creating our own delegation system (AA CAs)
   instead of profiling the system provided by X.509.

-Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Nov 2000 10:28:25 +0000

Hi Steve,

Your summary is correct. The reason for the text being as it is now
is that the X.509 (2000) delegation model was felt to be much too 
complex for an initial PKIX profile. AAControls was provided as
an attempt to provide some of the controls required in a simple
way.

So lets not open up the delegation can of worms, until someone
steps up with a simple, working solution for delegation of X.509
ACs.

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

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 15 Nov 2000 11:57:40 +0100

Steve,

> different organizations, especially with limited trust).

The major problem is IMO the lack of enthuseasm for the AC concept which
likely will leave it without TLS support.  Another problem is the packaging (ASN.1)
which is inappropriate for ACs which are *application specific* to an extent that
few other PKIX objects are.  The organizational issues (if not solved) just put the
final nail in the AC coffin.
 
>    will only use ACs from the verifier's organization.

Bob and I seem to agree that this limitation makes PULL fairly "boring" (my wording)

>    S/MIME, since each email client is an AC verifier.

E-mail clients as verifiers are a real PITA.  When I open PKIX-messages from some
people (who apparently run their own CAs) I constantly get alert messages due to
unknown CA etc.

I.e. ACs would make the burden worse, but the problem is really built into PKI itself.

IMO e-mail clients need SCVP or similar to get an almost "user-friendly" PKI.

Personally I see little point in S/MIME using ACs except maybe for server-based
apps where the trust configuration stuff becomes much more manageble.

<snip>

>    instead of profiling the system provided by X.509.

This is something I dont know about.  Any pointers to "free" documents?

Regards
Anders R

---

From: Steve Hanna <[email-masked]>
Date: Wed, 15 Nov 2000 10:22:36 -0500

> an attempt to provide some of the controls required in a simple

Unfortunately, AAControls does not provide the constraints that most
organizations will need in order to recognize ACs from other
organizations (constraints on attribute values, not just attribute
types).

Given this limitation, why keep AAControls at all? Wouldn't it be better
to work on simplifying and profiling X.509 delegation for some future
PKIX AC profile than to create a less functional duplicate system now
and have to support it in the future?

It is true that AAControls allows AC verifiers to recognize multiple AC
issuers with only a single configured AA CA. But the crude nature of the
constraints included in AAControls mean that all the AC issuers must be
within a single trust domain (unless the crude constraints are
sufficient, which isn't likely in my view). I don't think this feature
is very valuable. So I suggest that we omit AAControls from ac509prof.
It adds substantial complexity with little value.

> steps up with a simple, working solution for delegation of X.509

Agreed. Let's set aside delegation for now (at least in this forum). ACs
have many uses that do not require delegation.

-Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Nov 2000 15:44:21 +0000

Hi Steve,

> So I suggest that we omit AAControls from ac509prof.

It doesn't add any complexity since its in the "optional
to implement" section, just like attribute encryption. So,
if you want to, do it, if not, not. I think this was the
concensus of the WG at a number of meetings and on the
list discussion on the various revs of the I-D.

Stephen.

---

From: Steve Hanna <[email-masked]>
Date: Wed, 15 Nov 2000 11:04:19 -0500

> Bob and I seem to agree that this limitation makes PULL fairly

Boring to you, perhaps. Many people would be glad to have a uniform
authorization system for multiple applications, even if it was
server-side only.

> E-mail clients as verifiers are a real PITA. When I open
> PKIX-messages from some people (who apparently run their own CAs) I
> constantly get alert messages due to unknown CA etc.

Your email client should be configured to inform you in a more
unobtrusive fashion that a signature could not be verified. Such
failures are an inevitable result of the chaotic nature of email and PKI
trust models, but most of the time you probably don't care.

> IMO e-mail clients need SCVP or similar to get an almost

I doubt that ACs or SCVP will change things much. You'll still have many
signatures that can not be verified. You may also have clearance
attributes that could not be verified and certificate status issues
(certificates whose revocation status could not be determined).

> Personally I see little point in S/MIME using ACs except maybe for
> server-based apps where the trust configuration stuff becomes much
> more manageble.

Agreed. Most users probably won't need ACs with S/MIME. For military
applications, it may be important.

> This is something I dont know about.  Any pointers to "free"

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV6.doc

ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/X.509_4thEditionDraftV6.pdf

-Steve

---

From: Steve Hanna <[email-masked]>
Date: Wed, 15 Nov 2000 10:52:29 -0500

> list discussion on the various revs of the I-D.

It adds complexity to the spec. This makes it more difficult for
implementers to decide what to implement. And, if they decide to
implement this optional feature, it adds complexity to their
implementation. It also makes it more difficult for customers to decide
which features they need (since they will probably consult the RFC for
guidance). IETF specs (especially a profile!) should be as simple as
possible, but no simpler.

I just wanted to point out that AAControls is not sufficient for
cross-organizational ACs. If the consensus of the working group remains
to be that the AAControls extension is still valuable, I will certainly
accept this judgement. If there is a sudden flurry of emails saying
"take it out," that's fine with me, too. In either case, I will not
implement AAControls myself. And I will work on and think about a
simplified version of X.509 delegation that could be included in a
future AC profile.

-Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Nov 2000 10:32:07 +0100

Steve,

. See below.

> It adds substantial complexity with little value.

I basically agree with you. I have been advocating this removal. The
compromise made with Stephen Farrell (who wanted it), has been to make it
optional in the specification. Nevertheless, a deletion of it would be fine
with me.  :-)

Denis

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 16 Nov 2000 10:41:23 +0100

> applications, it may be important.

A more useful model would be that the client warns you only when it has already
received email from the same domain and/or same person with a different CA that the
one used in the message.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Nov 2000 10:49:03 +0100

Steve,

Since I am answering to the e-mail one by one, here is another comment.

> to be that the AAControls extension is still valuable,
 
Besides Stephen (and possibly the co-editors), it would be nice to know who
is (or is not) in favour of AAControls.

> I will certainly
> implement AAControls myself. 

The same for me. :-)

> And I will work on and think about a

If you plan to attend the next IETF meeting, I would like to have a chat
with you, so that we can possibly define such delegation schemes. No syntax
changes planed in the definition of ACs, simply the definition of rules on
how to use them in the context of delegation.

Denis

---

From: Steve Hanna <[email-masked]>
Date: Wed, 22 Nov 2000 11:15:19 -0500

Denis Pinkas wrote:
> Besides Stephen (and possibly the co-editors), it would be nice to
> know who is (or is not) in favour of AAControls.

This document has already passed WG Last Call and IETF Last Call.
Apparently, the consensus of the working group was to include the
AAControls extension. Although you and I don't agree with this, it's
probably too late to do anything about it unless there is a *major*
problem with the extension.

AAControls is an optional extension. It can be ignored. I suggest that
we allow it to be included for now and focus our energies on providing a
better delegation system (probably a profile of X.509 delegation,
focussed on the needs of Internet protocols). If we can accomplish that,
we can propose that AAControls be deprecated when ac509prof is ready to
move to Draft Standard status. After all, one purpose of Proposed
Standard documents (as described in RFC 2026) is to "gain experience and
to validate, test, and clarify the specification."

> If you plan to attend the next IETF meeting, I would like to have a
> chat with you, so that we can possibly define such delegation
> schemes. No syntax changes planed in the definition of ACs, simply
> the definition of rules on how to use them in the context of
> delegation.

I would love to do this. Anyone else who would like to participate,
please send me email and I will arrange an informal meeting.

-Steve