Re: UIDs popping up in new-part1

[Steve Hanna <steve.hanna@xxxxxxx>]

Perhaps a good compromise would be to remove any discussion of UIDs from
section 6 and change the end of section 4.1.2.8 to say that
"Applications conforming to this profile MAY be capable of parsing
unique identifiers and making comparisions. Applications that do not
make such comparisons SHOULD reject certificates that contain unique
identifiers to avoid accepting invalid chains."

This will allow PKIX-compliant applications to continue to accept UIDs
if they so choose, while removing any recommendation or requirement that
they do so. However, I do think that it's important to recommend that
applications that don't include UID support not accept certificates that
contain unique identifiers. Even though the PKIX profile recommends
against the use of UIDs, there may be CAs that use them. Accepting a
certificate with a UID without performing the UID comparison would be
analogous to accepting a certificate with a critical name constraints
extension without performing the required checks.

-Steve

Ari Kermaier wrote:
> 
> Steve,
> 
> My suggestion was that if the certificates contain the info required to
> do new-style certificate chain validation, then the UIDs could be
> ignored. If UIDs are deprecated, then UID mismatches shouldn't really
> matter, as long as the new chaining can be done correctly. Besides, if
> UIDs are so rarely used, a possible scenario might be where CA-1 issued
> (say, 2 years ago) a cert to CA-2 with UIDs and CA-2 issues (today) a
> cert to an EE without UIDs, relying on new chaining algorithms. Why
> should that certificate chain be rejected?
> 
> Also, it is not a fact, but rather a general impression, that nobody
> uses UIDs. It may have been a mistake to include them in previous
> profiles, but I think we're stuck with them -- we can't disinherit their
> children, we can only leave them out of family photos going forward.
> 
> ::Ari
> 
> >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
> > >