SCVP28 - PowerPoint PPT Presentation
Title:
SCVP28
Description:
Conflicting text in -27, but implied that servers should not sign responses when ... Draft -27 implied that EKU had to include SCVP client OID ... – PowerPoint PPT presentation
Number of Views:38
Avg rating:3.0/5.0
Title: SCVP28
1
SCVP-28
- Tim Polk
- November 8, 2006
2
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
3
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 dont accept anyKeyUsage.
4
Changes Since -27, contd
- 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.
5
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
6
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
7
Editorial changes since -27, contd
- 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 reqd parameter (format)
- Probably change subtype names
8
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
9
AD Comments Addressed Without Changes, contd
- Server handling of unrecognized flags is unclear
in 3.2.4.5 and 3.2.4.6 - Editors cited the text in section 4 that
addresses handling of unrecognized flags
10
AD Comments Addressed Without Changes, contd
- Client discovery of wantBacks/checks support by
server - Email 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
11
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?
12
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
13
SCVP Discussion on List since Montreal, contd
- Unprotected error responses (10/26)
- No changes required
- Unexplained (but obvious) error code (11/6)
- Will document and resubmit
14
Questions?
Recommended
CrystalGraphics Presentations
