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

Re: Updating RFC 3039 - and its impact on PI


Tom,

I disagree and agree. The meaning was that the OID itself would define what attribute it was defining semantics for. As such it does also identify the attribute.

But I agree that there are no mechanism to know what attributes that are involved if you don't know the OID

I'm not sure what should happen. As long as this function define semantics for attributes, I'm open to changes of its syntax.

Further I don't know any one that uses this feature yet. But I have come across applications where it would be very useful.

/Stefan

At 20:23 2002-03-15 -0500, Tom Gindin wrote:


Stefan:

      Are you proposing that the syntax of attribute semantics be changed
from RFC 3039 or not?  The syntax in RFC 3039 does not seem sufficient to
replace PI since it fails to bind registration authorities (and multiple
ones are permitted within it) to attributes directly.  Is anyone using this
at present?
      Furthermore, binding this function to QC's would, by itself, make the
feature less useful than PI's.  Publishing it there is a different matter.

Tom Gindin


Stefan Santesson <stefan@xxxxxxxxxxxx>@mail.imc.org on 03/15/2002 06:52:54
PM

Sent by: owner-ietf-pkix@xxxxxxxxxxxx


To:    Denis Pinkas <Denis.Pinkas@xxxxxxxx>
cc:    ietf-pkix@xxxxxxx
Subject:    Re: Updating RFC 3039 - and its impact on PI



Denis,

I will be more specific but I didn't want to take up to much space in the
start of the discussion

I'm not ready to suggest text replacement right now but the key usage
restriction should go and at least allow, without any restriction,
combination of digital signature AND non-repudiation.

For attribute semantics I think today that any such declaration has nothing

to do with any legal statements concerning qualified certificates. Having
that function in its current extension is to me a defect. If you want me to

be more specific I have to owe you but I wont' have trouble to come up with

examples and reasons.

I will also rise these problems with ETSI.

This was just an initiation of the discussion and I expect to discuss more
with you and others at Minneapolis.

Especially concerning assassination of PI :-)

/Stefan

At 15:03 2002-03-15 +0100, Denis Pinkas wrote:

>Stefan,
>
>See some comments below:
>
> > As author and implementer of RFC 3039 and in the light of practical
> > experience with RFC 3039, I think we should be ready to revise this RFC
> > and handle some defects.
> >
> > The defects I have recorded so far are:
> >
> > 1) Key usage
> > The key usage bit non-repudiation SHOULD NOT be set together with any
> > other key usage according to RFC 3039. This has caused a lot of
confusion
> > and this "SHOULD NOT" statement is not compatible with existing
reality.
>
>Could you be more explicit about a suggested text replacement ?
>
> > 2) Attribute semantics
> > This function to define semantics for attributes included in the
subject
> > field is very useful and it covers almost everything that the current
PI
> > draft wants to solve.
>
>Could you be more specific ?
>
> > The problem is that this function is part of the
> > qcStatements extension which it should not be. Firstly due to the fact
> > that this statement has nothing to do with the intent of this extension
> > and secondly because criticality setting for this function get mixed up
> > with completely unrelated stuff in its current form.
>
> > 3) Usage and purpose
> > RFC 3039 is the only RFC defining structure of a personal ID
certificate.
> > This should not be limited just to Qualified certificates. It should be
> > more clear that this RFC is useful for any personal ID certificate.
Also
> > non-qualified ones.
>
>Fine.
>
> > Finally I believe that a revision of RFC 3039 should include
> > considerations to avoid the need for a PI extension according to the PI
> > draft.
> >
> > I can't see that the PI draft accomplish anything that RFC 3039 doesn't
> > already solve, or at least would solve after revision.
>
>The revised document will not be able to solve what the PI document covers
>since the PI document applies to *any entity* whereas the revised RFC 3039
>document is planned to apply only to *personal ID certificates*. Maybe the
>revised RFC 3039 could take advantage and refer to the PI document.
>
> > The only exception is the function to define an identifier completely
> > independent of the subject name.
>
>Thank you for noticing this difference.
>
>Regards,
>
>Denis
>
> > I would tough argue that the total case with all aspects on
> > the table probably doesn't justify another feature for that and that
there
> > are other ways to solve this within the realm of X.509 and PKIX
standards.
>
> > I still believe that a creative revision of RFC 3039 could be made to
> > cover what we need in this area. And I also recall this as an initially
> > defined possibility laid down for the PI work.
>
> > /Stefan