Re: [Trans] OCSP and SCTs

[Rob Stradling <[e-mail]>]

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 <[e-mail]>
> wrote:
>
>     On Sat, Aug 30, 2014 at 9:05 PM, Fabrice <[e-mail]> wrote:
>
>         On Aug 30, 2014, at 15:43, Brian Smith <[e-mail]> wrote:
>
>             On Sat, Aug 30, 2014 at 3:22 PM, Fabrice
>             <[e-mail]> wrote:
>
>                 On Aug 30, 2014, at 14:16, Brian Smith
>                 <[e-mail]> 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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/trans
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
> _______________________________________________
> Trans mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
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.