Re: [IETF-PKIX] Subject/Issuer Name Population

[Paul Hoffman / IMC <paulh@xxxxxxx>]

At 07:02 PM 4/16/98 -0400, Stephen Kent wrote:
>I think the problem we see here is that some applications have a legitimate
>interest in requiring DNs for issuers, but not all application share this
>need. Thus it may be inappropriate to rerquire that ALL PKIX certs contain
>an Issuer DN, rather than allowing a null Issuer DN if an IssuerAltName is
>present.

It is only inappropriate to require it if we have a clear, unambiguous way
of doing cert path validation that includes IssuerAltNames. I don't think
we have one.

>What if we if we specify that a subjectAltName is validated
>against an IssuerAltName when both are present, and if the Subject name is
>null?  I do worry though that this might lead to confusion since the Issuer
>and IssuerAltName might differ under such circumstances.

That is an excellent example of confusion, and one that led me to believe
that we're not going to get reliable chaining with those kinds of
decisions. Let me give you another: there are plenty of kinds of AltNames
that might not be distinguished. I'm not talking about the malicious case
where BadCA tries to impersonate GoodCA. I'm talking about some of the many
kinds of names in GeneralNames that GoodCAEast might take and GoodCAWest
might take and have name collision without knowing it.

I have no love for DNs, but it seems much harder to have an accidental name
collision in the DN space than in many of the spaces in the AltNames.

And, let me bring up a topic again that no one responded to before: when
validating chains on AltNames, is it the AND of all the items in the
GeneralNames sequence, or is it the OR of them? If my IssuerAltName is a
SEQUENCE of three rfc822Names, and you're comparing against a cert that has
just one of those names, does the comparison pass or fail? In asking people
in the hallways in LA, I got about a 50/50 split of what people thought it
was. This alone should scare us away from using AltNames and expecting
people writing validating code to get it right.


--Paul Hoffman, Director
--Internet Mail Consortium