Re: Attribute Cert Policies Rationale

[Stephen Farrell <stephen.farrell@xxxxxxxxxxxx>]

Hi Chris,

> Both of the alternatives you have suggested are broken.  

Truth by blatent assertion. You're starting to sound like me:-)

> Your latest suggestion of where to put my "policy garbage" is also
> flawed.  The CA that issues the PKC to the AA may not be able (and
                                                ^^^
The "may" is the give-away. Its technically quite possible to setup an 
environment where the CA is so aware and where no policy extensions
are needed in ACs, but where all policy rules are followed, to the
extent that the 3280 implementation follows them that is, so the 3281 
code doesn't need to know and no new rfc is needed.

> probably does not want) to make claims regarding the policies enforced
> by the AA in validating asserted attributes.  If a commercial
> certificate authority (say VeriSign) issues the PKC to the AA, it's not
> likely that VeriSign is going to want to make assertions regarding the
> policies that apply to the AA's operations.  The CA issuing the PKCs has
> no insight into that.

So don't use such an AC-ignorant PKC service if you want this stuff. 
Build/buy a CA, or use a service that can put policy OIDs into PKCs 
more flexibly that those guys you mentioned:-). It can, and has, all 
been done already.

Unless there's a use case where it really isn't *possible* for the AA's 
PKCs to use a closely bound CA then this AC extension is not needed.
Most of the cases I can imagine would inherently call for the CA/AA
to know of one another or else wouldn't require any policy stuff. 
(Remember with ACs, all relying parties have to specifically "know" 
the AA is an AA, so they already have to have AA-specific configuration 
for this to work, which means that adding another PKC root CA isn't the
problem it usually is - i.e. the normal reasons why client-ssl is hard
don't apply.) 

But feel free to propose a use case that does justify this, its just
that I haven't seen one that convinced me so far.

Cheers,
Stephen.

> 
> Chris
> 
> Russ Housley wrote:
> >
> > Denis:
> >
> > >>Unlike Steve Farrell, I have no major objection to the inclusion of
> a
> > >>policy OID.
> > >
> > >Good.
> 
> Funnily enough, I do (still) have an objection: Its unnecessary
> additional
> crud and the same effect can be achieved now with no new specification
> and
> no new code. I already showed one way, here's another: put your policy
> garbage in the issuer's PKC which is fine with both 3280 and 3281 unless
> you're under the mistaken impression that PKCs are somehow expensive.
> 
> Stephen.
> 

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@xxxxxxxxxxxx
Ireland                             http://www.baltimore.com