If we allow relying parties to ignore UIDs, won't that break backward
compatibility in an even more dangerous manner than requiring RPs to
reject certificates that contain UIDs? Ignoring UIDs would allow RPs
to accept chains with UID mismatches. Since UID checking was previously
required, this would be a potentially dangerous contravention of the
issuing CA's intent.
An RP should either reject certificates containing UIDs or process
them properly, not simply ignore them. Since nobody uses this feature
and nobody can argue for why it is needed, I suggest that we require
RPs to reject certificates containing UIDs.
-Steve
>The recommendation that Section 6.1.3 be amended to remove references to
>UIDs makes sense; CAs conforming to the current profile should not be
>required to support this mechanism for certificate chaining, nor should
>UIDs be allowed to needlessly complicate the revised validation algorithm.
>
>However, requiring that UIDs be absent from a certificate would be a
>serious error, as would recommending that conforming CAs reject
>certificates containing UIDs. If the certificate in question contains the
>information required to perform chaining and validation as per the current
>profile, why should the CA not be free to ignore the presence of extraneous
>infomation? I think it would be a Very Bad Idea to break backwards
>compatibility for what is essentially nothing more than an aesthetic
>reason. A CA conforming to the current X.509 v3 profile should NOT reject a
>certificate that has a deprecated field from a X.509 v2 profile -- it
>should just ignore that field. Of course, eveyone "knows" that "nobody"
>uses UIDs, but that's not a good reason to break, even hypothetically,
>certificates that do use them unless there's a truly compelling positive or
>negative functional benefit.
>
>Ari Kermaier
>Phaos Technology
>
>>Last fall, we agreed to remove issuer and subject unique identifier
>>comparison from the validation algorithm. At least, I think we did. The
>>argument was that nobody uses unique identifiers and there's no good
>>reason to retain support for them.
>>
>>In draft-ietf-pkix-new-part1-04.txt, this has almost been done. However,
>>they remain in step (a) (5) of section 6.1.3, which says:
>>
>> (5) The certificate issuer unique identifier is the
>> working_issuer_UID, meaning:
>>
>> (i) working_issuer_UID is non-null and matches the value in
>> the issuerUID field, or
>>
>> (ii) working_issuer_UID is null and the issuerUID field is
>> not present.
>>
>>But working_issuer_UID is no longer set anywhere. We should either put
>>back the text that initializes and updates this state variable or we
>>should change this step so that it doesn't refer to this uninitialized
>>varible. I suggest that we remove support for unique identifier chaining
>>by changing this step to say:
>>
>> (5) The issuerUniqueID and subjectUniqueID fields are not
>> present in the certificate.
>>
>>This will ensure that compliant implementations will not accidentally
>>accept certificates that use these fields, since support for these
>>fields is no longer required. I also suggest that we change the sentence
>>in section 4.1.2.8 that reads "Applications conforming to this profile
>>SHOULD be capable of parsing unique identifiers and making
>>comparisons." to read "Applications conforming to this profile SHOULD
>>reject certificates that contain unique identifiers."
>>
>>-Steve
>