[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETF-PKIX] Subject/Issuer Name Population
Tim,
>At 12:11 PM -0400 4/9/98, Tim Polk wrote:
>>For those who weren't in the LA meeting, this proposal was requested by the
>>S/MIME working group. An empty issuer name wreaks general havoc with their
>>protocols. We expect S/MIME to be a major "customer" for PKIX, so that is
>>an important consideration.
>
>I will point out that TLS (née SSL) has a similar requirement, as it uses a
>list of Distinguished Names to specify supported CAs when requesting client
>certificates.
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. Even in your example, its not clear that the list of CA names sent
in SSL/TLS be DNs, other than for historic reasons. TLS could choose to
mandate use of GeneralNames for CAs in this context, as another minor
deviation from SSL that would make it more general.
Denis pointed out that use of the NameConstraints extension is problematic
when the Issuer and Subject name types differ, although that problem might
be mitigated. 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.
Steve