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
Our website uses cookies on your device to give you the best user experience. By using our website, you agree to the placement of these cookies. To learn more, read our privacy policy. Read Privacy Policy