[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Policy Contraints Object Identifier
<html><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META content='"MSHTML 4.71.1703.0"' name=GENERATOR>
</HEAD>
<BODY>
<DIV> </DIV>
<DIV><BR> </DIV>
<DIV>-----Original Message-----<BR>From: Mike Smith <<A
href="mailto:mfsmith@zionsbank.com";>mfsmith@zionsbank.com</A>><BR>To: <A
href="mailto:jduffy@bbn.com";>jduffy@bbn.com</A> <<A
href="mailto:jduffy@bbn.com";>jduffy@bbn.com</A>>; <A
href="mailto:peter@verisign.com";>peter@verisign.com</A> <<A
href="mailto:peter@verisign.com";>peter@verisign.com</A>><BR>Cc: <A
href="mailto:ietf-pkix@tandem.com";>ietf-pkix@tandem.com</A> <<A
href="mailto:ietf-pkix@tandem.com";>ietf-pkix@tandem.com</A>><BR>Date: Friday,
September 12, 1997 8:04 AM<BR>Subject: Re: Policy Contraints Object
Identifier<BR><BR></DIV>
<DIV>>Policy mapping would imply re-issuance to get the new mappings onto the
required certs. I believe this is a classic case for cross certification
for each (BBN and GTE) authority, recognizing the root public key as a CA in
their own hierarchy (if they have a hierarchy) or chain (web) of
trust.<BR>><BR>>Michael </DIV>
<DIV> </DIV>
<P><FONT face=Courier>Mike,</FONT></P>
<P><FONT face=Courier>In the last 7 years, I have heard that offline
cross-certification will<BR>seemingly "solve" any cert domain- or
management problem one cares to<BR>characterise; its a magic bullet to be loaded
& fired whenever a trust or<BR>recovery (vs issuing) scenario is
encountered. Under controlled management,<BR>I'm not so sure this
one-stop-shopping experience is quite so<BR>sound as many make out. Lets look
more deeply based on v. large-scale<BR>environments which have received much
actual analysis. (Just<BR>as 1422 contained a domain-model and rationale,
perhaps PKIX 1 (or 3)<BR>needs to embrace some guidance on the authority/naming
structures<BR>anticipated for <STRONG>Internet PKI
</STRONG>scenarios.)</FONT></P>
<P><FONT face=Courier>I was (indirectly) thinking about a DoD ops concept when I
wrote the<BR>problem statement. It is expected that, every ~2 years, service men
and<BR>women will become based in new localities, even though their
home<BR>regiment, or core, or other organizational unit, stays
constant<BR>during the move, as does their personal rank and
title.</FONT> </P>
<P><FONT face=Courier>This is a lot of regular name changing, either in the
directory indexes,<BR>or the names in certs, if cert subject-names convey
any<BR>locality info.</FONT> </P>
<P><FONT face=Courier>In a token-centric world, this means given your
troops<BR>a (re)new(ed) Fortezza-card (or RSA smartcard) every two years.
<BR>While you are at this expensive task, issue them a new cert (or<BR>two) when
they get to the new base and commence their<BR>new job in a new
command.</FONT> </P>
<P><FONT face=Courier>I do not imagine a cross-certification scenario here.
Rather,<BR>its more of a periodic re-org, where everyone gets new names/tokens,
and<BR>any associated privileges due to the change in their
enviornment/job.</FONT> </P>
<P><FONT face=Courier>Many corporate mergers are re-orgs (and sometimes mass
<BR>layoffs/revocations) versus friendly merging of assets, know-how, etc.
<BR>Firing 2000 people overnight makes for a large CRL in the morning<BR>even if
you rehire 1900 of them next day on new contracts<BR>with a new corporate
identity.</FONT> </P>
<P><FONT face=Courier>As I say, this second-order domain management control is a
fun topic. The<BR>more you regulate it with complex name schemas, and perform
key management,<BR>based upon name-management dynamics, the more intractable it
becomes even<BR>with the support of a well-managed centralised and ubiquitous
directory<BR>performing name management (not certificate/CRL
distribution).</FONT> </P>
<P><FONT face=Courier>In a "prototype" "Internet PKI" we
have been running in<BR>the PKI industry for 2 years now we had a philosophy of
- keep names out<BR>of the picture until momentum has built to undersatnd the
obvious value of<BR>certs per se: name management debates are endless! When its
time (i.e the <BR></FONT><FONT face=Courier>market expects more and greater
discretionay control) move to<BR>schematise naming as an option to those local
domains who desire<BR>name-based controls.</FONT> </P>
<P><FONT face=Courier>It may be time to clean up all our acts generally on
names, now that there <BR>is a discerning corporate/organizational market
attaching itself to the<BR>residential PKI and the evolving, open management
infrastructure for<BR>inter-domain secured interworking.</FONT> </P>
<P><FONT face=Courier>Peter.</FONT></P>
<P><BR>><BR>>>>> Peter Williams <<A
href="mailto:peter@verisign.com";>peter@verisign.com</A>> 09/11/97 03:55PM
>>><BR>>><BR>>> >Thanks,<BR>>> >Jean
Duffy<BR>>> ><BR>>> >GTE Internetworking<BR>>>
>Powered by BBN<BR>><BR>><BR>>I know BBN an GTE have been off and on
friends for years; but<BR>>its still a little sad for us Internet types to
see any diminishment<BR>>of the BBN name!<BR>><BR>>Corporate mergers of
this sort are, of course, common.<BR>><BR>>Lets say BBN has issued 50,000
certs to employees, and GTE corporate<BR>>dictum now wanted to change
everyone over to [a-z]*@bbn.gte.com. (I<BR>>do not know if they do or do
not.)<BR>><BR>>Obviously one way to do it is to revoke and reissue all
certs (and<BR>>handle 50,000 tokens if token-based).<BR>><BR>>Another
way is to revoke the BBN CA(s), and start again with<BR>>new trust
points.<BR>><BR>>How would PKIX technology migrate folk intelligently? A
policy mapping, or<BR>>name mapping in a renewed BBN CA certificate,
perhaps?<BR>><BR>>This is a fun topic, after all the recent fuss. It
will<BR>>not be long before someone has to deal with precisely<BR>>this
scenario.<BR>><BR>>
!<BR>>
<BR>> </P></BODY></HTML>
</html>Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Disposition: attachment;
filename="smime.p7s"
Attachment converted: Lutefisk:smime.p7s 9 (????/----) (0001BDF7)