On Mon, Jul 19, 2010 at 05:50:39PM -0700, Paul Hoffman wrote: > At 7:16 PM -0400 7/19/10, Shumon Huque wrote: > > > >Right, I agree with that. > > > >I'm not clear on whether you're objecting to an ordering rule. Or > >saying that the additional text in 4.3 about ordering is unnecessary. > > I am objecting to a MUST- or SHOULD-level ordering rule where it does not affect interoperability or security. I am still open to someone showing why this particular rule might affect those, but after many rounds, none has come forth, so I am suggesting dropping the rule altogether or making it MAY-level (with some reasoning as to why it is even worth the effort). Fair enough. I don't have a reason to offer beyond the already mentioned optimization. And as a possible hint to folks about what the preferred types are. And as I mentioned earlier, I don't have a strong opinion on this. This draft is all about matching identities. It should sketch out the explicit details of some matching algorithm. Is your proposal to match identities in the order of their appearance in the certificate? Something else? Or leave this unspecified? [...] > >I do have a stronger opinion on the following point: I think there is > >a longer term security goal here, of nudging application protocols to > >use application specific identity types -- so that we avoid situations > >where a certificate with a generic domain name identity, if compromised > >for a particular service, can be used to impersonate other unrelated > >services at that domain name. As a general rule, different application > >services running at the same domain name should not be using the same > >certificates, unless by conscious choice of the deployer. > > Fully agree, and that is correctly addressed, repeatedly, in the rest of the document. Oh, good. I was beginning to feel after several revisions of text, that the draft was not making this point (and the rationale behind it) strongly enough! [...] -- Shumon Huque University of Pennsylvania. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf