Steve, Both of the alternatives you have suggested are broken. I've already stated my opinions on why using a separate DN for each AA policy is cumbersome, so I wont repeat them. 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 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. 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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature