SCVP-28 Tim Polk November 8, 2006

Current Status Draft -27 was submitted in June ‘06 –AD requested a revised ID 8/11 –No related discussion on list –Editors discussion off list Draft -28 submitted in October ‘06 –Editors rationale for changes posted 10/31

Changes since -27 Two Error Code Definitions Generalized –In draft -27, the codes only allowed the server to indicate that the a value of TRUE (e.g., for required explicit policies) is unsupported. Added new specified KeyUsages item to validation policy –Supports applications that require EKU to be present but don’t accept anyKeyUsage.

Changes Since -27, cont’d Clients may require signed or MACed responses even when using protected transport –Conflicting text in -27, but implied that servers should not sign responses when communicating with TLS, etc.

Editorial Changes since -27 EKU with anyExtendedKeyUsage okay for signing requests & responses – Draft -27 implied that EKU had to include SCVP client OID Definition of new extensions does not require a new Version number –Unspecified in -27

Editorial Changes since -27 Client/Server CMS message types –Both MUST support signedData and SHOULD support authenticatedData Query tagging –Inserted comment in ASN.1 for query to clarify that tag zero is not used

Editorial changes since -27, cont’d Obtaining Key Agreement keys –In section 3, text cites the validation policy response as a source of keys MIME registration –Change controller is now IESG –Still need to: Delete unnecessary req’d parameter (format) Probably change subtype names

AD Comments Addressed Without Changes Version handling in validation policy request & response –Client asserts highest version that it can handle –Server returns highest version it can generate satisfying client limitations –AD Observed that ASN.1 is not very extensible Changes in the request syntax would cause failures Editors response –Request syntax is expected to be stable

AD Comments Addressed Without Changes, cont’d Server handling of unrecognized flags is unclear in and –Editors cited the text in section 4 that addresses handling of unrecognized flags

AD Comments Addressed Without Changes, cont’d Client discovery of wantBacks/checks support by server – explains why negotiation is unnecessary Requests assert a single check, so no confusion Servers MUST support core wantBacks For niche cases from 3779, an out of band relationship is assumed

Open issue AD: It's not clear that this meets RFC 2026's definition of interoperability. –Conforming clients will always generate requests that conforming servers can process. –If the server can not satisfy the request, it will generate an error message that is recognized by the client. Clients that request DPV services from a DPD-only server will receive such an error message. Does this satisfy the interoperability requirements in RFC 2026?

SCVP Discussion on List since Montreal Encoding of different ASN.1 types when encapsulated within the octet string (7/13) –No changes required SCVP ASN.1 “reuse” of structure names (10/20) –Name collisions with S/MIME ESS and attribute certificate ASN.1 modules –No changes, but could easily be addressed if WG traffic had indicated support

SCVP Discussion on List since Montreal, cont’d Unprotected error responses (10/26) –No changes required Unexplained (but obvious) error code (11/6) –Will document and resubmit

Questions?