[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Attribute Cert Policies Rationale
Steve,
A CA's job is about binding identities to public keys. Coupling that to AA
policies and procedures is outside the scope of what a CA is supposed to
care about. That aside, of course it's *possible* to set up an environment
where the CA is aware of the AA's policies and practices and is willing to
assert AA policy information in the PKC, it's just not always practical or
cost-effective. This would almost certainly require that the AA and the CA
be operated by the same organization. Why should we engineer the technology
so that this is the only option available? If an organization wants to
operate an AA, why should we force them to also operate a CA that is tightly
coupled to the AA's operations?
Consider the calibration lab scenario I described initially. The lab is in
the business of calibrating stuff. They want to issue an electronic version
of their calibration stickers in the form of attribute certificates, but
they have no interest in also running a CA. Running their own CA increases
their costs and distracts them from their core business, which is
calibration (e.g. validating the attributes asserted in their ACs). Running
a CA, which again is about validating identities, is a job best outsourced
to someone who wants to be in that business.
Chris
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