[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Attribute Cert Policies Rationale
Steve,
I can't resist a response since you ended your previous message with a
question:)
My objection to the using the RDN isn't related to the complexities of
supporting multiple identities as much as it is to the complexity of
seamlessly switching back and forth between those identities without
interruption to the operation of the AA. If the AA supports responding to
requests for attribute certificates through an online protocol, security
controls pertaining to the activation of the AA's private key material would
likely make it problematic to switch back and forth between identities
without human intervention.
Besides that, embedding information about policy (or anything else other
than the name of the AA) in the DN just seems ..... inelegant. Yuk:(
Chris
-----Original Message-----
From: Stephen Farrell [mailto:stephen.farrell@xxxxxxxxxxxx]
Sent: Tuesday, December 10, 2002 12:13 PM
To: Christopher S. Francis
Cc: Ietf-Pkix
Subject: Re: Attribute Cert Policies Rationale
Chris,
I think we're pretty much there in terms of understanding one another,
so there's probably no need to prolong this thread - between us at least.
> Standing up two physically different
> AAs to do the same job is expensive. Having a single AA issue
certificates
> using multiple identities adds complexity that doesn't need to be there.
That depends entirely on your AA implementation, something about which
the rfc is properly silent, but I'd expect that any sensible AA or CA
could handle >1 identity smoothly, so I disagree that this really adds
unnecessary complexity to the AA (e.g. its almost the same as handling
key &/or cert rollover for the AA and if you don't handle that you're
broken).
In contrast your proposal adds complexity to the relying party, which is
IMO clearly less desirable when its not needed.
> Plus, having an explicit reference to the policies that apply to the
> certificate IN the certificate is better than an implied reference based
on
> the issuer DN.
We disagree there. Which is fine, since the sentence contains the word
"better", but I still fail to see how embedding an OID in the extensions
field SEQUENCE OF is "better" than embedding it in the RDN field
SEQUENCE OF. The code looks just the same anyway, but maybe you assume
there's a one true DIT for AA's?
Stephen.
>
> Cheers,
> Stephen.
>
> "Christopher S. Francis" wrote:
> >
> > Thank you for your comments Stephen.
> >
> > ... snip
> >
> > The reason it isn't desirable is that AC usage is still almost
> > non-existent, and adding yet more complexity is a very good way
> > to ensure that things stay as they are.
> >
> > ... end snip
> >
> > I can't believe you feel adding an extension w/ an OID is complex
compared
> > to the other topics that regularly get discussed here :)).
> >
> > While I agree that AC usage is not widespread, as someone who is
actually
> > operating a commercial attribute authority, I must respectfully
disagree.
> > It is precisely because my company is trying to use attribute
certificates
> > for something real that this issue has come up. Not making changes to
> > accommodate real-world experiences is a sure fire way to ensure that
usage
> > of ACs remains extremely limited.
> >
> > Chris
>
> --
> ____________________________________________________________
> 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
--
____________________________________________________________
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