Re: QC comparisons are DEADLY serious!

Anders,

What you describe is another issue. Comparing the subjects name against an
access control database may be a desired function. 

It should be noted though that in this case it is up to the local policy of
the relying party (and the content of the certificate) to decide if a new
certificate match a specific entity in the database (matching the old
certificate). 

It should also be clear that it is NOT a function of the QC profile to
guarantee that two certificates for the same person will be considered to
match the same entity in an access control database. This must be resolved
by other means.

But I promise I will bring this up in Washington to check others view.

/Stefan 

At 03:20 PM 10/30/99 +0100, Anders Rundgren wrote:
>Stefan, 
>
>I strongly disagree on your conclusions regarding certificate comparisons. 
>Rather, I consider the possibility to compare certificates from a certain 
>issuer and CPS 
>to be a major "quality" property that deserves a section of its own. 
>
>To give an example. If you have a QC issued by a TTP (ID-certificates that 
>will only be used within the issuer's own domain are pretty uninteresting)
and 

AC Pull with multiple profiles

Hi Folks,

it seems that theres an obvious (?) limitation with the pull model when
dealing
with multiple profiles (i.e. a subject owns multiple ACs, according to
certain profiles).

That is, for a subject that owns multiple ACs, how can the server know which
AC to pull
from the AC repository for a given client request? The client *could*
specify a profile for the
server to use in it's LAAP request as a part of client-server exchanges, but
this would make
it qualify as a push model as well...?

If this is a downside to the pull model, then perhaps it could be mentioned
as such in the draft(s).

Cheers,

Andy

-----
Andy Dowling
SSE (A Siemens Company)
Fitzwilliam Court, Leeson Close,
Dublin 2, Ireland

E-Mail:  andy.dowling <at> sse.ie
Web: http://www.sse.ie

RE: QC comparisons are DEADLY serious!

Stefan,
Comments in line

>What you describe is another issue. Comparing the subjects name against an
>access control database may be a desired function. 

Can't say that I fully understand the value of unique identities in digital certificates if they
cannot be used by computers.

<snip>

>It should also be clear that it is NOT a function of the QC profile to
>guarantee that two certificates for the same person will be considered to
>match the same entity in an access control database. This must be resolved
>by other means.

I noted that QC "bans" such use which was the whole reason for bringing this up.

May I suggest an extension to the QC draft that specifically addresses this issue?

Slight puke-warning!

As the dnQualifier seems to be reserved for a particular purpose and also have
an arbitrary syntax it seems that dnQualifier is not a good candidate for access-control.

Therefore I would like to see a new "subject item" named something like staticUniqueIdentity that if
defined in a certificate, indicates that the CA indeed has the capability to (long-term) keep track
of its subscribers.   Some preliminary rules to support this:

16 decimal digits.  No more, no less.   Like VISA.  Why? to allow verbal communication of

NR, redux, again.

I agree with Ed that there have been a multiplicity of meanings 
proposed for the NR bit, and as yet no clear consensus. And that
despite the fact that the decedent horse has been well and
truly flogged.

Yet is it clear, I believe, that this matter simply MUST be resolved,
one way or the other (or the other, or the other).  Not everyone 
is going to be happy with the outcome, in all probability, but
if we can at least define the rules of the road, both subscribers
and relying parties will know whether to accept or reject a 
certificate that contains the NR bit.

The Washington meeting offers a fortuitous opportunity
to address this issue, in that the ABA Information Security committee
will have been meeting Monday - Wednesday, and an informal 
joint meeting has been proposed for Thursday.

I'm not certain what the agenda for that meeting is supposed to be --
I expect it will probably revolve around the work the ISC has been doing to 
define PKI evaluation guidelines -- but it would be a shame if we didn't
get the technologists and the attorneys together and try to hammer
out some consensus, even if it takes until midnight.

Then, once it becomes obvious that a single bit is not sufficient
to represent all of the different and useful notions that are at
least close to NR, we can them make progress in defining those
addition bits or states.

Bob

Re: NR, redux, again.

Bob Jueneman wrote:
> Then, once it becomes obvious that a single bit is not sufficient
> to represent all of the different and useful notions that are at
> least close to NR, we can them make progress in defining those
> addition bits or states.

Mr. Jueneman, list:

This might well constitute sticking my neck out too far, but since the
certificatePolicies extension has room for more than one
PolicyInformation SEQUENCE, could not the PKIX working group try working
out a set of the most common conceptions of the usage of the NR bit and
define CertPolicyId's for them that conformant CAs could add to their
own?

The combination of NR-specific policyIdentifier and presence/absence of
NR-bit should hopefully be sufficient to represent at least the
different notions present in the PKIX working group.

Just a thought.

//oscar

Re: NR, redux, again.

>>> Oscar Jacobsson <oscar.jacobsson <at> celocom.com> 11/01/99 09:46AM >>>
Bob Jueneman wrote:
> Then, once it becomes obvious that a single bit is not sufficient
> to represent all of the different and useful notions that are at
> least close to NR, we can them make progress in defining those
> addition bits or states.

Mr. Jueneman, list:

This might well constitute sticking my neck out too far, but since the
certificatePolicies extension has room for more than one
PolicyInformation SEQUENCE, could not the PKIX working group try working
out a set of the most common conceptions of the usage of the NR bit and
define CertPolicyId's for them that conformant CAs could add to their
own?

The combination of NR-specific policyIdentifier and presence/absence of
NR-bit should hopefully be sufficient to represent at least the
different notions present in the PKIX working group.

Just a thought.

//oscar

Oscar, that's a thought, and one of a number of possibilities.

But one of the most important issues that your suggestion brings up
is whether NR has anything to do with a CA  AT ALL, and therefore
whether it is appropriate to represent in a CertPolicyId extension.

RE: Comments on draft-ietf-pkix-ldap-v3-01.txt

Re: NR, redux, again.

Bob Jueneman wrote:
> Oscar, that's a thought, and one of a number of possibilities.
> 
> But one of the most important issues that your suggestion brings up
> is whether NR has anything to do with a CA  AT ALL, and therefore
> whether it is appropriate to represent in a CertPolicyId extension.

True.

I am, however, regretfully ignorant regarding the requirements existing
and emerging digital signature legislation might set on the presence or
absence of keyUsage bits in end-entity certificates. There may, for all
I know, exist Certification Authorities that are legally bound to set,
and thus applications legally bound to interpret, the non-repudiation
bit in a certain fashion.

//oscar

Re: NR, redux, again.

Bob Jueneman wrote:

> I agree with Ed that there have been a multiplicity of meanings
> proposed for the NR bit, and as yet no clear consensus.

Thank you for making my words clearer. The first WG consensus
was that setting the NR-bit is neither necessary nor sufficient to
define the provision of NR services. From this first consensus
emerged a multiplicity of meanings, for which there was no clear
consensus -- but it was recognized that the solution does not have
to be either/or (i.e., we could have two, three or more aceptable and
properly discriminated NR meanings).

The problem is to enumerate these meanings in a order relation
of "strength" and to map them to on/off states of bits.

There are at present two enumerations of these NR meanings,
and how they could be mapped to the states of on/off bits
in the keyUsage byte. The approach by Tom Ginding with a
proposed RFC and two NR states defined by the NR bit, and
 my own enumeration with four states of DS/NR defined by four
states of the DS/NR bits.

These efforts should be mentioned in the roadmap, at least as
"work in progress" -- caused by the first consensus.

The second WG consensus which the roadmap failed to
mention was that the NR definition MUST be changed, as Bob says:

> Yet is it clear, I believe, that this matter simply MUST be resolved,
> one way or the other (or the other, or the other).

I also agree with Bob that just one bit is not enough:

> Then, once it becomes obvious that a single bit is not sufficient
> to represent all of the different and useful notions that are at
> least close to NR, we can them make progress in defining those
> addition bits or states.

but, since "once it becomes obvious" may take some time, I think
that Tom's RFC could provide a useful bridge in the meantime. I
believe that this was Tom's intention. Which is another reason to
mention that RFC in the roadmap, as it distills if not the solution at
least IMO most of the WG's reasonings on the way to a solution [*].

Cheers,

Ed Gerck

[*] As commented in the book "Hare Brain, Tortoise Mind" by Guy
Claxton, the NR issue exemplifies the need for the Hare Brain in us to
have an RFC that can be used while the Tortoise Mind in us continues
to work on making progress towards a more comprehensive solution.

Re: NR, redux, again.

Ed Gerck wrote:
...snip

>
> but, since "once it becomes obvious" may take some time, I think
> that Tom's RFC could provide a useful bridge in the meantime. I
> believe that this was Tom's intention. Which is another reason to
> mention that RFC in the roadmap, as it distills if not the solution at
> least IMO most of the WG's reasonings on the way to a solution [*].
>

The next version of the roadmap will capture this.

spt