Re: Updating RFC 3039 - and its impact on PI

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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