Hi Kyle. Please review the TRANS charter [1]. The scope for 6962-bis
is "a standards-track mechanism to apply verifiable logs to HTTP over TLS".
I'm guessing you're thinking of S/MIME certificates, Code Signing
certificates, etc, which can be logged but which can only be checked via
OCSP Fetching (not OCSP Stapling). These are in scope for discussion,
possible future WG re-chartering and possible future WG work items.
[1] http://datatracker.ietf.org/wg/trans/charter/
On 01/09/14 01:57, Kyle Hamilton wrote:
The more you apply your own "best idea" decision tree, the more you
restrict perfectly valid options that would otherwise be legitimate by
the spec, in the name of "interoperability". This is why, for example,
Netscape's insistence on a "trustworthy" (which really devolves to
"known, without judgment of trustworthiness") certifier managed to
create a new and completely artificial cottage industry that suffered
artificial stunted growth patterns... because it insisted on
ITU-standard authentication before anyone knew what it was really good
for. It also basically destroyed one of the use-cases explicitly
permitted by the spec, that of the unauthenticated connection.
Don't insist on a client-protocol stapling. Not everything uses TLS --
and even though TLS is the intended use case, leaving low hanging fruit
for other protocols is probably better than binding it so tightly to TLS
that no one can conceive of a use aside from that binding.
-Kyle H
On August 31, 2014 11:44:10 AM PST, Brian Smith <[email protected]>
wrote:
On Sat, Aug 30, 2014 at 9:05 PM, Fabrice <[email protected]> wrote:
On Aug 30, 2014, at 15:43, Brian Smith <[email protected]> wrote:
On Sat, Aug 30, 2014 at 3:22 PM, Fabrice
<[email protected]> wrote:
On Aug 30, 2014, at 14:16, Brian Smith
<[email protected]> wrote:
I understand the issue you describe and how stapling has
less opportunities
for failures and is a MUST for TLS clients, but my
question was really about
what should a TLS client do when it does not get an OCSP
response through
stapling (RFC6066) but get one directly from the OCSP
responder or
potentially other means.
To me, it seems logical for the TLS clients to process
SCTs found in those
responses, no matter how it got them.
When the client is enforcing CT, it should reject the
certificate due
to the missing SCT before it even attempts revocation checking.
Thus, it would never fetch the OCSP response and so it would
never
learn the SCT from a fetched response.
I don't see any language in the RFC or draft that suggest there
is an
ordering between revocation checking and CT validation, or any
other parts
of the certificate validation. The only related language I found
is rather
succinct:
In addition to normal validation of the certificate and its
chain, they
should validate the SCT (...)
I understand that your question is "If I fetched an OCSP response,
should I recognize the SCTs
in the fetched response?" I don't have any
opinion on that.
You are right that the spec. doesn't talk about the ordering of doing
revocation checking and SCT processing during certificate chain
validation. I believe that the best ordering is to process SCTs, and
reject certificates without SCTs, before doing revocation checking or
path building, especially revocation checking and path building that
requires doing any networking (OCSP fetching and/or AIA chasing),
because this reduces the risks that are inherent in doing that
networking and with doing path building in general. The draft should
be changed to say that.
However, you agree that the current draft allows a client to reject a
certificate due to a missing SCT before it attempts any AIA chasing
and/or OCSP fetching, right? If so, then the server must provide the
SCT in the handshake--in the TLS extension, in the certificate, or in
a stapled
OCSP response--to interoperate with clients that work that
way, regardless of whether some clients process SCTs in fetched OCSP
responses.
If there are good reasons to ignore SCTs in non-stapled OCSP
responses, I'd
like to know about them, and it probably should be mentioned in
the RFC.
A browser needs a reliable mechanism for getting SCTs in order for the
browser to be able to make SCTs mandatory. Browsers that make SCT
mandatory would ultimately be what would make CT effective. OCSP
fetching is not reliable, in theory or on practice, so a client cannot
rely on getting SCTs via OCSP fetching. A browser that processed SCTs
in fetched OCSP responses would be encouraging websites to avoid the
reliable mechanisms of SCT delivery in favor of an unreliable
mechanism, causing CT to be
unreliable and thus ineffective.
Cheers,
Brian
------------------------------------------------------------------------
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
