0 *H 01 0 +0 *H $Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Steve, I am not assuming anything regards trust hierarchy. I also believe that bilateral cross certification will be the next phase to deploy, so we are in complete agreement that vision that organisational CAs protecting resources would be issuing cross certs with name constraints. If fact I see this as a dimension of the operational requirement not considered by the bridge CA model. I envisage a small number of CAs issuing certs to user, but I will have a larger number of CAs issuing the cross certificates. I see that model because organisations typically have a very clear line to who has authority of the identity (typically the HR department). I see the access to resources controlled in many parts of the organisation as each part has its own trust relationships. Large organisations do not have a homogeneous trust model. Each business unit wants to make alliances for itself. One the subject of administrative configuration - I am beginning to see a realisation by customers that running a CA is potentially a different direction to the administration of resources - so I see it as a realistic solution, that if you want that kind of control - run a CA. At the worst - you if you run your own CA to control access to resources, you will get the same level of assurance as out of band configuration of parameters to chain building - but you would have to work hard to be that bad - with a little effort, you should do better. Trevor -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com] Sent: Tuesday, March 06, 2001 11:52 AM To: Trevor Freeman Cc: ietf-pkix@imc.org Subject: RE: WG Last Call: Son-of-2459 Trevor, >Steve, >I think your original idea is the right one. I am sure that products >will appear which will support the features contained in son of RFC2459, >so I think it premature to introduce another mechanism. I also agree >with your premise that there will be a drive for the use of CAs who's >job is the issuance of cross certificates to other CAs with a view to >managing the trust relationships for a set of resources, and may never >in their lifetime issue a certificate to a end user. I have seen this as >an increasing trend with deployment planning due to the realisation of >the complexity of the trust relationships required by organisations. I appreciate the support, but I fear that we may be arguing for different models. I would want to see an organizational CA issue cross certs with name constraints, and that CA (or a subordinate of it) would certainly issue certs to end users. I am not fond of the "bridge CA" model that the U.S. federal PKI adopted, because none of its subscriber organizations can issue cross certs to the bridge containing other than simple, prohibited subtree name constraints. I'd be happier if the bridge CA subscriber organizations took the certs issued by the bridge CA and used them as a basis for issuing direct cross certs with name constraints. But I've been told that the complexity of doing that would be too great for the subscriber organizations, so ... Anyway, since it is clear that not all folks will issue cross certs as I suggested, I have to admit to liking the fallback position of allowing specification of name constraints as part of the validation procedure, on a per trust anchor basis. The main argument I've seen is the one that questions whether this should be a user configurable parameter, or an administrative parameter, or whether this is a MAY (vs. SHOULD/MUST), which allows vendors to ignore the facility entirely. Steve 0@0!%f^uG{Y0  *H 0L1 0 UUS10U  Microsoft10 U Ntdev10UNTDEV SA Root CA0 000920212445Z 020920213328Z0L1 0 UUS10U  Microsoft10 U Ntdev10UNTDEV SA Root CA00  *H 0)lIw=x[k%)FqLK/*+\ S2vgRg snjLθЁs&:2;a# Աzۘ!E8-$f2 <ίEPՖ;L!00 +7CA0 UF0U00Uwti,98eXν0U00Nhttp://whicasarootca.ntdev.microsoft.com/CertEnroll/NTDEV%20SA%20Root%20CA.crlPfile://\\whicasarootca.ntdev.microsoft.com\CertEnroll\NTDEV%20SA%20Root%20CA.crl0 +70  *H o$ͨ7@TU;=Q<ÚTܡ,]n.UsFddU(F,G?h%KJ|wB)f,≤=}׵051tR2|d000 ao0 *H80a1 0 UUS10U  Microsoft10 U Ntdev1.0,U%NTDEV Intermediate Subordinate Whica20 000925232723Z 010925233416Z0K1 0 UUS10U  Microsoft10 U Ntdev10UNTDEV ISSUE3 CA00  *H 07II֞؇6ɐH*?aE]ט湟p*sIh~(7墥g?(OLS6JUK R&t!4xkp .O+L=E]0Y0 +70UDVJ|3kЙ0 +7  SubCA0 UF0U00U#0y ޤ$W"m AB0VUM0I0EA=\http://whica2.ntdev.microsoft.com/CertEnroll/NTDEV%20Intermediate%20Subordinate%20Whica2.crlldap:///CN=NTDEV%20Intermediate%20Subordinate%20Whica2,CN=whica2,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ntdev,DC=microsoft,DC=com?certificateRevocationList?base?objectclass=cRLDistributionPoint0p+b0^0+0whttp://whica2.ntdev.microsoft.com/CertEnroll/whica2.ntdev.microsoft.com_NTDEV%20Intermediate%20Subordinate%20Whica2.crt0+0ldap:///CN=NTDEV%20Intermediate%20Subordinate%20Whica2,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ntdev,DC=microsoft,DC=com?cACertificate?base?objectclass=certificationAuthority0 *H800-AXY5&{yxni'TEr9\ !Zü0GZ00  60  *H 0L1 0 UUS10U  Microsoft10 U Ntdev10UNTDEV SA Root CA0 000925232416Z 010925233416Z0a1 0 UUS10U  Microsoft10 U Ntdev1.0,U%NTDEV Intermediate Subordinate Whica200+*H80^gq&8O 0׳cԘ\(L xG*WWzu=ck,6ʲAhTVOSY9!ܫΓf[fGTufF VX>?y ѐWp`oc u8(C;wA1tyVpA=^uIQ%R3PJ/yD< ǸKF܂:ֈGՋCfҹJ6hБcA% ~Hߋ$|.k:0m6ƒ ]~-3 z|Ы}COg5D/<G DHPe:a2d7 6!FaG07σ#<=I[muD 6Y;?DpuKOM#y\x55;h#GY᛭ Ta&0"05 +7 (0&0  +70 +0 +0-U &0$0" +7щNלӿ0 U0)U%"0  +7++0> +710/'+7щNלӿfh0U+X" 4bե:=E;0U#0DVJ|3kЙ0&U00 Dhttp://whica3.ntdev.microsoft.com/CertEnroll/NTDEV%20ISSUE3%20CA.crlldap:///CN=NTDEV%20ISSUE3%20CA,CN=whica3,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ntdev,DC=microsoft,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint0?+10-0k+0_http://whica3.ntdev.microsoft.com/CertEnroll/whica3.ntdev.microsoft.com_NTDEV%20ISSUE3%20CA.crt0+0ldap:///CN=NTDEV%20ISSUE3%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ntdev,DC=microsoft,DC=com?cACertificate?base?objectClass=certificationAuthority0VUO0M+ +7 trevorf@ntdev.microsoft.comTREVORF@exchange.microsoft.com0= +70.AutoEnrollSmartcardUser0  *H  g,:ЗE.LF;&:LSr ##A Jskh1(l~<]P6BF: G\Lޗ+ rc=-0BN ǫH.x_~BT:0{0 9@TS0  *H 0K1 0 UUS10U  Microsoft10 U Ntdev10UNTDEV ISSUE3 CA0 010227000419Z 010313000419Z010 &,dcom10 &,d microsoft10 &,dntdev1 0 U ITG10 U Users10UTrevor Freeman1-0+ *H  TREVORF@exchange.microsoft.com00  *H 0Ǖ% HKqlPyhпoO>凩̷uٸL@w %ss 'vtɀYvMzPAZx*Rɋ#ٹ(١e^a'w;eE0&fQ4006 *H  )0'0 *H 80 *H 80+0 +7 0 0 +0 U00U% 0 +0> +710/'+7щNלӿfbi0Uly~EdVbkM0U#0DVJ|3kЙ0&U00 Dhttp://whica3.ntdev.microsoft.com/CertEnroll/NTDEV%20ISSUE3%20CA.crlldap:///CN=NTDEV%20ISSUE3%20CA,CN=whica3,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ntdev,DC=microsoft,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint0?+10-0k+0_http://whica3.ntdev.microsoft.com/CertEnroll/whica3.ntdev.microsoft.com_NTDEV%20ISSUE3%20CA.crt0+0ldap:///CN=NTDEV%20ISSUE3%20CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=ntdev,DC=microsoft,DC=com?cACertificate?base?objectClass=certificationAuthority0VUO0M+ +7 trevorf@ntdev.microsoft.comTREVORF@exchange.microsoft.com0? +720AutoEnrollSmartCardEmail0  *H =c45jWDal [ څB1|+cs4+aDa>KG>\셤."Y2~a1Kz'6Eԑ^!E7$ךW _bU100Y0K1 0 UUS10U  Microsoft10 U Ntdev10UNTDEV ISSUE3 CA :0 +0 *H  1  *H 0 *H  1 010307005353Z0# *H  1Q-n.%P]LJ0X *H  1K0I0 *H 0*H 0+0 *H (0+0 *H 0h +71[0Y0K1 0 UUS10U  Microsoft10 U Ntdev10UNTDEV ISSUE3 CA 9@TS0j *H   1[Y0K1 0 UUS10U  Microsoft10 U Ntdev10UNTDEV ISSUE3 CA 9@TS0  *H lBn"ex_^3D-fbc _W1#CcT9K o| FZQ:~~`)f-'|#(jl;YEFAtۥ;/%5