[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UIDs popping up in new-part1

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