Re: Updating RFC 3039 - and its impact on PI

[Stefan Santesson <stefan@xxxxxxxxxxxx>]

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