RE: RFC3039bis last call ?

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

In-line.

/Stefan
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Denis Pinkas
> Sent: den 23 december 2003 16:18
> To: Stefan Santesson
> Cc: ietf-pkix@xxxxxxx
> Subject: Re: RFC3039bis last call ?
> 
> 
> > Denis,
> >
> > I have replied to these comments before and these were also
discussed at
> > the IETF meeting and concluded.
> >
> > Name:
> > ------
> > The scope is the same but it is just worded a bit different. This
> > profile has never limited itself to just Qualified Certificate, i.e.
> > this profile defines the framework that is considered useful for
> > Qualified Certificate but the use of the profile is not limited to
> > Qualified Certificates. It can be used to create or support also
other
> > type of certificates. This was also clearly stated in RFC 3039.
> 
> "Qualified Certificate" has two meanings. Two meaning for the same
acronym
> is confusing. We should not perpetrate confusion.

The use of the term Qualified Certificates is well defined in RFC 3039.

> 
> > The reason for the wording change in the abstract was that many
readers
> > had missed the fact that this profile can be used to support any
> > ID-certificate, qualified or not. Example of such use could be use
of
> > the bimetricInfo extension for attaching picture.
> >
> > The meeting, the WG chairs and the Security AD agreed that the name
of
> > the document should be kept. I don't feel strongly either way but I
> > respect that decision and think it is the best one.
> 
> I believe that RFC 3039 should be kept as it is.
> 
> If you believe that additions are neeed, then I have no objection in
> principle for a new document.

I guess we have to agree to disagree. We ARE in a process to update this
document. I'm open to hear any input from you in this process. If you
disagree to the process as such then this is an issue between you and WG
chairs.

> 
> > Requirement from ETSI:
> > ----------------------
> > There is a need to harmonize development of ETSI TS 102 280 with RFC
> > 3039. This has also been expressed in circulated ETSI documents, but
> > there are also other reasons to update RFC 3039.
> 
> This is wrong.
> 

I know you think so, but do you have any arguments to present?

> There may be a need to revise ETSI TS 102 280, but there is no need to
> revise RFC 3039, as far as ETSI is concerned.

Revise TS 102 280?? It isn't written yet. 

> 
> > Replacement of RFC 3039:
> > ------------------------
> > As concluded at last IETF it is impossible to update RFC 3039 and
keep
> > RFC 3039. It would cause several extensions to be defined in
multiple
> > RFCs.
> 
> If we keep RFC 3039 as it is and have a new document, I don't see what
the
> problem is. Please elaborate your argumentation.

RFC 3039 defines 2 new extensions and some new attributes. We can't
create e new document that is living in parallel that defines the same
extensions one more time.

> 
> > Reference to RFC 3280
> > ---------------------
> > RFC 3039 is a profile of RFC 3280 so we reference it.
> 
> We all know that the key usage section in RFC 3280 has a problem and
needs
> to be fixed.
> 
> The text of RFC 3039 should stay as it is.

I know you think so, but why.

The only thing is said was that if NR is set it SHOULD be set
exclusively.
This statement has no context in RFC 3039 and is thus bad and prevents
deployment. This has however a context in TS 102280 where it is to be
found instead of here.

Note that RFC 3039 allows both encryption as well as DS to be set.

Note also that it is YOU who promotes a definition of the DS bit that
will force many CAs to issue certificates with both DS and NR set,
because that will be the only way to allow a single signing certificate
to be used for arbitrary signing operations, regardless of purpose.

I argue for a DS bit (according to RFC 3280) that has no limitations of
usage of DS, to allow an environment with a single certificate for
signing to have only DS set. Then we MAY be able to avoid NR+DS
certificates, which actually would be a good thing.

But as it is now, RFC 3039 have no context to say that this is an
invalid combination in general. We could though add a section in the
security considerations section highlighting threats that may arise due
to this combination.

> 
> > If you have any problem with this that is an issue you have to take
up
> > with the WG chairs or Russ as AD. As far as I'm concerned RFC 3039
does
> > not define any meanings of the key usage bits and thus should not be
> > dependent on any resolution of that.
> 
> The current text contains text which should not be deleted.
> 
> > Finally there is nothing in any definition of Qualified Certificates
> > that prevents such certificates from being used for Authentication.
> 
>   ... which is precisely why the text on the key usage section should
be
> kept.

As I said, there is nothing in the old text that prevents or even
recommends against this.

> 
> Denis
> 
> > /Stefan
> >
> >
> >>-----Original Message-----
> >>From: owner-ietf-pkix@xxxxxxxxxxxx
> >
> > [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> >
> >>On Behalf Of Denis Pinkas
> >>Sent: den 4 december 2003 21:08
> >>To: ietf-pkix@xxxxxxx
> >>Subject: RFC3039bis last call ?
> >>
> >>
> >>
> >>I probably missed the e-mail about an RFC3039bis last call, but
since
> >
> > it
> >
> >>is mentioned in the WG minutes that there will be a last call. In
case
> >>it is already going, I would like to reiterate that the concerns I
> >>raised before the Minneapolis meeting are still valid.
> >>
> >>In particular, I would like to reinsist on two points:
> >>
> >>RFC3039 states in the abstract:
> >>
> >>This document forms a certificate profile for Qualified
Certificates,
> >>based on RFC 2459, for use in the Internet. The term Qualified
> >>Certificate is used to describe a certificate with a certain
> >>qualified status within applicable governing law.
> >>
> >>RFC3039bis states in the abstract:
> >>
> >>This document forms a certificate profile, based on RFC 3280, for
> >>identity certificates issued to physical persons.
> >>
> >>It is clear from the abstract that the topic of the two documents
are
> >>different and that the new draft should be renamed: Identity
> >>Certificates Profile.
> >>
> >>As a consequence, this new draft is NOT a replacement for RFC 3039.
> >
> > One
> >
> >>argument has been that ETSI needed changes to RFC 3039. There is not
> >>such a requirement from ETSI.
> >>
> >>Another major issue is that RFC3039bis states:
> >>
> >>Key usage settings SHALL be set in accordance with RFC 3280
> >
> > definitions.
> >
> >>We know that the key usage bit section of RFC 3280 is going to be
> >>changed. However we still don't know what will be the new text.
> >>Discussions are going on within ISO SC6 both to redefine bit 0 in
> >
> > terms
> >
> >>of the security services it may support (instead of saying "all
> >
> > security
> >
> >>services except one security service"), and to rename bit 1. This
> >
> > means
> >
> >>that referencing RFC 3280 is fine, except for the section on the key
> >>usage bits.
> >>
> >>Qualified Certificates are to be used when a signer wants to commit
to
> >>the content of a document, not when a signer wants to authenticate.
As
> >>it is, the new draft would create confusion.
> >>
> >>Denis
> >>
> >>
> >>
> >
> >
> >
>