[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: UIDs popping up in new-part1
I strongly disagree that "nobody uses unique identifiers" or that
"there's no good reason to retain support of them." And I even
more strongly reject the notion that just because it is alleged that no one
uses them, applications SHOULD reject certificates which disprove
the allegation!
I don't want to go into too much detail regarding a usage that would
be proprietary in any case, but we are considering the use of unique
IDs in order to facilitate finding and retrieving the appropriate keys in
a network-wide context, where the consuming application, the
encrypted data (if applicable), and the server on which the key
is stored (in encrypted form) may all be separate, and may tend to
migrate apart in a more or less unconstrained fashion. We observe that
servers are often split due to increased workload, or perhaps merged
as servers are replaced with more powerful models, directory information,
including encrypted information is often replicated to other servers, but
not all servers may have access to the encryption keys (perhaps they
are stored on a smart card which is unique to only one server), and
less-often accessed data is frequently migrated to archival media.
These can often be extremely complex issues, sometimes involving
terabytes of information. The data may be essential to the operation,
or it may be important business records that must be preserved for legal
reasons, but are not all that often accessed. Perhaps the data itself
is migrated to an off-site backup facility, but the key is retained in a smart
card.
In any case, the use of unique ID that may include some useful information
as to where the was generated or resides can be extremely helpful, and
yet can be dealt with using a standardized mechanisms that is quite compact.
Regards,
Bob
>
>>>> Steve Hanna <steve.hanna@xxxxxxx> 02/28/01 03:25PM >>>
>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
Robert R. Jueneman
Security Architect
Novell, Inc -- the leading provider of Net services software
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Bob Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell Inc. -- the leading provider of Net services software;DS eBusiness Solutions
TEL;PREF;FAX:01-801/861-2522
EMAIL;WORK;PREF;NGW:BJUENEMAN@xxxxxxxxxx
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;;Novell, Inc.\n1800 South Novell Place\n;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah 84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Bob Jueneman=0A=
Novell, Inc.=0A=
1800 South Novell Place=0A=
=0A=
Provo, Utah 84606
X-GWUSERID:BJUENEMAN
END:VCARD
BEGIN:VCARD
VERSION:2.1
X-GWTYPE:USER
FN:Robert R. Jueneman
TEL;WORK:01-801/861-7387
ORG:Novell, Inc.;DS eBusiness Solutions
TEL;PREF;FAX:01-801/861-2522
EMAIL;WORK;PREF;NGW:BJUENEMAN@xxxxxxxxxx
N:Jueneman;Bob
TITLE:Consultant Engineer
ADR;INTL;WORK;PARCEL;POSTAL:;PRV-F331;122 E. 1700 South;Provo;Utah;84606;USA
LABEL;INTL;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah 84606=0A=
USA
LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:Robert R. Jueneman=0A=
PRV-F331=0A=
122 E. 1700 South=0A=
Provo, Utah 84606
TEL;HOME:1-801-765-4378
TEL;CELL:1-801-361-1410
TEL;PREF:1-801-861-7387, 1-800-453-1267
X-GWUSERID:BJUENEMAN
END:VCARD