Subject: Re: SCVP 16 comments deadline

From: Peter Sylvester <[email-masked]>
Date: Mon, 6 Dec 2004 12:38:50 +0100 (MET)

Denis and Trevor, > 
> Trevor,
> 
> > The deadline communicated at the DC meeting for making comments on SCVP 
> > 16 was Nov 30th which has now passed. I have had only three people send 
> > me comments to date. SCVP 17 will be closing very shortly so this is the 
> > last reminder.
> 
> Thank for the remainder. I missed the initial announcement.
What announcement?
what I can read here is: 

The minutes say (17 nov)

> SCVP (version 16) - Trevor Freeman (Microsoft)
	Lots of changes have been made from v15; many were editorial 
> but also many substantive changes and some new features. Another rev 
> of the document will be needed. We need to ensure that the ASN.1 is 
> correct, once we agree on the functionality, and so we will compile 
> it to verify. Presentation reviewed changes and new features 
> (relative to v15). See slides for additional details.

The minutes had not been challenged by Trevor.

I cannot see any announcement on the list about that date. There
are "no presentation files and no minutes' available in the IETF
server. 

According to my understanding of how IETF working groups
function, an announement during a meeting is non-existant 
if not reflected in the mailing list message. 

(It may be that someone filters the content of the imc server for me).

Peter

---

From: Tim Polk <[email-masked]>
Date: Thu, 09 Dec 2004 11:43:30 -0500

Folks,

As Trevor noted, I had established a deadline for comments on SCVP 16 
during the last meeting.  I think I promised to restate this on list, but 
apparently failed to do so.  Since it was not in the minutes, it was not 
communicated to the list and it doesn't count.  So, I am setting a new 
deadline:

Wednesday, December 15.

Yes, that is a very aggressive deadline, but everyone on the PKIX list 
should be aware by now that we need to finish SCVP.  If you were interested 
in commenting, I assume that you have read the drafts already, and should 
be able to easily prepare your comments.  (And if you didn't expect a 
deadline before, this thread should have clued you in!)  It should not take 
a week to complete your review and submit comments.

So, my apologies: to the list for the oversight; and to the editors for 
extending the comment period.

Tim Polk

---

From: Francis Dupont <[email-masked]>
Date: Sun, 12 Dec 2004 18:02:07 +0100

Some comments:
 - the requestorRef definition doesn't match its description in 3.2.
   IMHO we should keep the description, i.e., the requestorRef should be
   an octet string which is a local reference to the client. More, I'd like
   the rationale of 4.7 be reflected in 3.2...
 - please change wantBack (item name) and WantBack (type) into wantBacks
   and WantBacks (like [cC]ecks and [rR]eplyWantBacks: homogeneous use
   of the plural!)
 - I'd like to use other cert references than ESSCertIDs, IKE has and URL
   for instance. Please add an OID+Value choice in PKCReference/ACReference?
 - checks OIDs (id-stc-build-*) are different between 3.1.2 and the annex.
   IMHO the text which defines 7 cases is right.
 - 3.1.5.1 needs to be merged into 3.1.4.1. My understanding is there are
   a default validation policy and a basic validation algorithm.
 - spelling of basic valAlg errors (id-bvae-*) should be uniformized
 - same for name valAlg errors between definitions and descriptions
 - id-nvae-unknown-pupose -> id-nvae-unknown-purpose
 - there is nothing about the case where the extended key usage extension
   is absent. IMHO this is like key usage, i.e., the certificate MUST be
   considered goof for all extended usages...
 - responseFlags items *need* tags!
 - 4 uses id-ct-scvp-psResponse in place of id-ct-scvp-certValResponse (typo)
 - what are the differences between responseStatus 50 and 61, or 51 and 62?
 - in ValidationPolValues isCA and trustAnchors should be optional as they
   have no default values.
 - validationPolicyAttr is spuriously described again in 4.5.6
 - in 4.10 change valdationPolicy into validationErrors (typo) which is
   OPTIONAL (i.e., in the MAYs)
 - replyWantBacks for id-swb 10, 11 and 13 are missing
 - delete 4.10.6 validationAlg (moved to ValidationPolValues)
 - just a question "en passant": what OID to used in validationErrors for
   a failed "isCA" check? id-bvae-invalidEntity? id-bvae-invalidPurpose?
 - please change valPolRequest into VPRequest for the name of the type
 - same for valPolResponse and VPResponse
 - same in 6.4 for PolResponse
 - same in 6.6 for polResponse
 - delete 6.7 trustAnchors
 - IMHO dhPublicKeyInfo should be optional in VPResponse because DH is
   not the only protection way.
 - 6.14 VaidationPolValues (typo)
 - in ASN.1 annex:
    * nameValidationAlg -> NameValidationAlgParms
    * ValidationPolValues differs
    * some missing id-stc-build-*
    * id-svp-defaultValAlg -> id-svp-defaultValPolicy
    * missing id-svp-dnValAlg, incorrect id-nvae definition
 - in HTTP B.1 appendix:
   application/cv-policy-request -> application/cv-request
   (IMHO the Sample should be removed as the length header is missing too)

Regards

[email-masked]

PS: I have an implementation of draft 16 in OpenSSL 0.9.7d with a responder
and some test clients including racoon (IKE) and EAP-TLS. Of course as
only the beta version of OpenSSL really supports policies it is a very
partial implementation, BTW not worse than what already exists for
my applications (:-).

---

From: Francis Dupont <[email-masked]>
Date: Sun, 12 Dec 2004 18:02:07 +0100

Some comments:

Regards