Hi Carl-Uno,
Actually I read this document two days ago and it's very good.
Clear, concise, entirely applicable to IPP (because an insecure
link can be upgraded in place [in the same connection] to
a highly secure link by the proposed mechanism). The companion
recent I-D update on 'https:' with TLS is also quite good.
This stuff is starting to come together (finally...). So now
maybe the IESG will look with smiling eyes on the IPP/1.1
latest drafts?
If people haven't look at RFC 2659 and RFC 2660 (Secure HTTP
which uses the scheme 'shttp:' and provides transaction-level
security negotiated on the fly within a putatively insecure
existing connection - note that this could match IPP's
model that a SINGLE request and response can be outstanding
at once on a given HTTP connection and allow on-the-fly
addition of security for a Set-2 operation while running
anonymously for ordinary job viewing by GetJobAttributes).
Oops - my parentheses got away from me.
Anyway look very seriously at RFC 2659/2660 - I think this
is important because it gives HTTP an model of object
security (object being a transaction sequence) that
matches very well what people are already doing with
S/MIME and the Cryptographic Message Syntax by way
of the Common Indexing Protocol (CIP) outgrowth of
Whois++ and others.
Cheers,
- Ira McDonald
High North Inc
906-494/2697/2434