Re: [Trans] path validation

liciously) mis-issued cert will be discovered quickly. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] defining "mis-issuance"

issue. Stephen, The "ability to provide immediate feedback to CAs that are issuing syntactically malformed certs" sounds like a nice idea, but surely this could be implemented as a stand-alone application or web service? Why would you want it to be an intrinsic part of CT? -- Rob S

Re: [Trans] defining "mis-issuance"

On 01/10/14 16:45, Peter Bowen wrote: On Wed, Oct 1, 2014 at 8:32 AM, Rob Stradling wrote: The "ability to provide immediate feedback to CAs that are issuing syntactically malformed certs" sounds like a nice idea, but surely this could be implemented as a stand-alone application or w

Re: [Trans] Precertificate format

_______ Trans mailing list Trans@ietf.org 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

Re: [Trans] Log servers by Feb 2015?

ansparency -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] TLS server with SCTs in stapled OCSP responses ?

Pilot and Aviator logs). (For clients that don't support ECC, it currently serves an RSA cert with 1 embedded SCT). Hope this helps. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing l

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

haracters (e.g., as a placeholder for a set of names) are not addressed by this specification. Applications with specific requirements MAY use such names, but they must define the semantics." So, as long as we "define the semantics" for our use of "?", I don't t

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

C5280 at all. AFAICT, "*" is neither more nor less legal than "?", as far as RFC5280 is concerned. Where is this 'explicit exception for "*"' that you're talking about? because it was a widely adopted convention. If you want to use "*&

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

eason to hide wildcard certs from the log. Steve ___________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Of

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

r "?" or whatever the DNS experts prefer) MUST NOT match "*" in the cert? I can't think of a legitimate reason to hide wildcard certs from the log. I agree that wildcard certs should be logged. Great. I think the two new tickets I mentioned above are sufficient. Steve

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

On 27/01/15 10:51, Rob Stradling wrote: On 21/01/15 18:49, Stephen Kent wrote: Rob, Hi Steve. That seems like a good idea. Did you have any particular DNS experts in mind? I'd ask Joel Jaeggli for suggestions. Thanks. I'll contact Joel. Actually, before I do that... We&

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

Or if not, is there any reason to prefer option 1 over option 2, or vice versa? On 28/01/15 22:56, Daniel Kahn Gillmor wrote: On Tue 2015-01-27 07:58:14 -0500, Rob Stradling wrote: On 27/01/15 10:51, Rob Stradling wrote: On 21/01/15 18:49, Stephen Kent wrote: Rob, Hi Steve. That seems l

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

On 29/01/15 21:41, Daniel Kahn Gillmor wrote: On Wed 2015-01-28 18:19:58 -0500, Rob Stradling wrote: Or if not, is there any reason to prefer option 1 over option 2, or vice versa? I think you're right, we should go for option 2 (also, it's the simplest and easiest to explai

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

f a redacted label? On 30/01/15 16:32, Daniel Kahn Gillmor wrote: On Fri 2015-01-30 11:09:10 -0500, Rob Stradling wrote: OK, let's discard option 1 and option 3. Before we settle on option 2, here's an option 4 to consider... 4. "?" matching =1 character in a redacted lab

Re: [Trans] [trans] #54 (rfc6962-bis): Simplify name redaction

overly redacted but which is otherwise considered compliant. It is expected that monitors will treat overly redacted Precertificates as potentially misissued. TLS clients MAY reject a certificate whose corresponding Precertificate would be overly redacted. -- Rob Stradling Senior Res

Re: [Trans] updated attack analysis

mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office

Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT

and good reasons to not do so (complexity, extra signing overhead). So, closing this ticket without changing the format. ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Deve

Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT

might be relevant to this discussion: http://trac.tools.ietf.org/wg/trans/trac/ticket/14 P.S. At least we're not trying to embed an MPEG video of a cat into a certificate field that you might expect to contain ASN.1 object(s). ;-) http://www.cypherpunks.to/~peter/T2a_X509_Certs.pd

Re: [Trans] changes to attack analysis

Incidentally, +1 to Steve's recent comment... "The description of the extensions field seems to be inspired by X.509v3. That's OK, but one needs to define a top-level format for extensions to ensure backward compatibility (as per v3 extensions)to make this work. That level of spec

Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT

this would encourage publication of experimental RFCs as a way to game the system. Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Bad Technical Decision: Closing out the SCT encoding discussion

n (an OCTET STRING inside an OCTET STRING). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Bad Technical Decision: Closing out the SCT encoding discussion

On 13/03/15 21:05, Stephen Farrell wrote: On 13/03/15 20:58, Rob Stradling wrote: On 13/03/15 20:25, Stephen Farrell wrote: And if we interpret 5280 strictly and conclude that is still a good plan then the question would be what to do about the SCT encoding, which could be to do something

Re: [Trans] Bad Technical Decision: Closing out the SCT encoding discussion

On 13/03/15 21:15, Rob Stradling wrote: On 13/03/15 21:05, Stephen Farrell wrote: On 13/03/15 20:58, Rob Stradling wrote: On 13/03/15 20:25, Stephen Farrell wrote: And if we interpret 5280 strictly and conclude that is still a good plan then the question would be what to do about the SCT

Re: [Trans] [trans] #34 (rfc6962-bis): use of RFC 5246 syntax to define the SCT

ausibly, be designated as an OCTET STRING. The vast majority of ASN.1 knowledgeable folks I know would find it easy and obvious to encode an SCT in ASN.1. Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] AIA/cRL for logged certificates

tigations: - Require that the client only use the AIA/CRL distribution point from the chain logged in the CT log (which forces the client to fetch it online, before completing the connection). - Require the presence of AIA/CRL distribution point in the end-entity certificate. Any other suggestion

Re: [Trans] Use of private OIDs in WG document

seems more feasible. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Use of private OIDs in WG (standard-track) documents

ate a ticket to the effect that the IANA considerations section needs revision (which it does, regardless of which arc the OIDs belong to). Ticket created. http://trac.tools.ietf.org/wg/trans/trac/ticket/81 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Tru

Re: [Trans] Poll for adoption of working group draft on threat analysisfor CT

Friday, April 10. Please review the slides and provide an indication of whether or not you support draft adoption. Thanks, Melinda & Paul -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mail

Re: [Trans] [pkix] Certificate Transparency and user agent warnings

62). But I feel like if the problem is issuing server certificates for domains *not* authorized to do so, then name constraints seems like a natural solution. Thanks in advance. -- Rob Stradling Senior Research & Development Scientist COMODO - Creatin

Re: [Trans] Empty extra_data

the cert in leaf_input and nothing in extra_data. Do you think that this is conformant with the specification? _______ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Cr

Re: [Trans] Tracking implementations

a wiki page listing implementations. Thanks again, Melinda -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Tracking implementations

On 03/06/15 17:50, Paul Wouters wrote: On Wed, 3 Jun 2015, Rob Stradling wrote: https://crt.sh Pronounced "search". :-) It's a web interface that lets you search for certs that have been logged by the publicly known RFC6962 logs. Very cool! Paul Thanks Paul. :-) -

Re: [Trans] Tracking implementations

h the company. Of course the domain is active. sigh tim On 6/3/15 7:26 AM, Rob Stradling wrote: https://crt.sh Pronounced "search". :-) It's a web interface that lets you search for certs that have been logged by the publicly known RFC6962 logs. Right now it's half a Mon

Re: [Trans] Tracking implementations

for handling SCTs to OpenSSL-next. [1] https://crt.sh/?id=7842948 Search for "Signed Certificate Timestamp" -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@iet

Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt

I hope to include an ASCII art diagram of the system, derived from DKG's nice slides from IETF 92. Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://w

Re: [Trans] [trans] #55 (rfc6962-bis): Security Considerations: Describe the implications of clients *not* doing certain optional checks

nt: I presume this should become part of the threat analysis I-D. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Format of SCTs

On 09/06/15 12:28, Ben Laurie wrote: I'd like to draw the WG's attention to http://trac.tools.ietf.org/wg/trans/trac/ticket/86, in which I propose that we return SCTs ready-made instead of in pieces. Opinions? Works for me. -- Rob Stradling Senior Research & Development Sc

[Trans] Log Monitoring API

search for certs issued to a particular domain name/space, setup notifications of (mis-)issuance, etc. Matt Palmer and I are planning to start work on a -00 draft soon. If anyone else would like to get involved, please let us know. -- Rob Stradling Senior Research & Development Scient

Re: [Trans] Log Monitoring API

It's on its way. Ditto (hopefully). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Log Monitoring API

ginal Message- From: Trans [mailto:trans-boun...@ietf.org] On Behalf Of Rob Stradling Sent: Thursday, June 11, 2015 5:16 AM To: trans@ietf.org Cc: Matt Palmer Subject: [Trans] Log Monitoring API 6962-bis notes that: "Those who are concerned about misissue can monitor the logs, asking

Re: [Trans] Log Monitoring API

this my contribution to your draft. Thanks for your input. It's good to know that someone else thinks it would be useful to be able to manipulate notifications programmatically. - Matt -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(

Re: [Trans] Log Monitoring API

lem statement. You're correct that the audit role is vital too. If the CT ecosystem is functioning as intended, then a monitor can be sure that they've seen every logged cert, without having to trust the log. But a client of a monitor has to trust the monitor. Is that any cl

Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signaturemust be over something other than just the TBSCertificate

Fixed at https://github.com/google/certificate-transparency- rfcs/commit/546e6e9451186e96ddd7b54ca02f17c8d86f951e. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] [trans] #79 (rfc6962-bis): Precertificate signaturemustbe over something other than just the TBSCertificate

to the right of "1 parent". Then do the same again, and you should arrive at... https://github.com/google/certificate-transparency-rfcs/commit/c62061213c5085cf4d0f266dc8aa2c803bcf4c8f -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Offi

Re: [Trans] Fwd: I-D Action: draft-ietf-trans-threat-analysis-00.txt

. So far we've only encountered CAA records for 2 domains, both of which belong to us! So I think it's fair to say that CAA records are not yet widely used! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __

Re: [Trans] [trans] #80 (rfc6962-bis): Re-introduce the issuer keyhash into the Precertificate

@ietf.org 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 Offi

Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log certvalidation is ambiguous

s/commit/716e7f5df4b465283f26d48bdf46e21c61d9c3d4 ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office

Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re log certvalidation is ambiguous

nk we can anticipate what all of those are. ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 O

Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re logcertvalidation is ambiguous

s mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text re logcertvalidationis ambiguous

e what set of checks it performs. Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 text relogcertvalidationis ambiguous

ll encourage CAs to adhere to 5280. That strikes me as a questionable design strategy. Actually, I don't expect the level of CA adherence to 5280 to increase or decrease due to this strategy. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online

Re: [Trans] [trans] #77 (rfc6962-bis): normative client behaviorspecified in Section 5

r Chrome's UI either, so please don't feel that IETF is being ignored any more than any other standards organization. ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Tran

Re: [Trans] [trans] #77 (rfc6962-bis): normative client behaviorspecified in Section 5

ed) that 5 is the maximum. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] [trans] #73 (rfc6962-bis): Section 3 textrelogcertvalidationis ambiguous

5280. That strikes me as a questionable design strategy. Actually, I don't expect the level of CA adherence to 5280 to increase or decrease due to this strategy. I don't either, yet that seems to be a part of the argument you made. It really isn't. Steve -- Rob Stradling Senior Re

Re: [Trans] #70 (rfc6962-bis): STH spec needs to define top-levelextension syntax

NA is asked to establish a registry of CT extension IDs, initially consisting of: +---+---+ | ID| Extension | +---+---+ | 65535 | reserved | +---+---+ TBD: policy for adding to the registry _

Re: [Trans] [trans] #77 (rfc6962-bis): normative clientbehaviorspecified in Section 5

re we likely to see web browsers starting to reject certs that are not accompanied by SCT(s), IMHO. And clearly there's no need for a plan that would only be needed once there's no longer any need for a plan. ;-) -- Rob Stradling Senior Research

Re: [Trans] #70 (rfc6962-bis): STH spec needs to definetop-levelextension syntax

ving this discussion on an IETF WG list. but thanks for the offer. You're welcome. However, I'm not clear if you've declined or accepted my offer. Could you clarify? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] #70 (rfc6962-bis): STH spec needs todefinetop-levelextension syntax

a pull request and kicked off the review here: https://github.com/google/certificate-transparency-rfcs/pull/70 (BTW, the fact that the TRAC ticket and the pull request are both numbered 70 is purely coincidental). -- Rob Stradling Senior Research & Development Scientist COMODO - Cr

Re: [Trans] #70 (rfc6962-bis): STH spec needstodefinetop-levelextension syntax

On 18/07/15 00:40, Rob Stradling wrote: On 17/07/15 14:35, Stephen Kent wrote: If you believe that there are folks who don't track this list and who rely on GitHub to track CT stuff, then feel free to post there. GitHub is what the 6962-bis authors are using to collaboratively edi

Re: [Trans] #70 (rfc6962-bis): STH specneedstodefinetop-levelextension syntax

revocation information passed in-band (i.e. OCSP Stapling). SCTs are passed in-band. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] #70 (rfc6962-bis): STHspecneedstodefinetop-levelextension syntax

ake even if that client doesn't also contact the log out-of-band to fetch and verify STHs and/or inclusion proofs and/or consistency proofs. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Tran

Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct

+1 On 23/07/15 21:25, Eran Messeri wrote: Another vote for adoption. On Thu, Jul 23, 2015 at 10:22 PM, Salz, Rich mailto:rs...@akamai.com>> wrote: Strong yes to adopt. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Tr

Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct

rated them. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Call for adoption, draft-linus-trans-gossip-ct

t this was before any of the browsers had introduced their certificate blacklisting mechanisms (i.e. Google's CRLSets, Microsoft's disallowed.stl, etc). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

[Trans] CT "Lite" idea (was Re: Call for adoption, draft-linus-trans-gossip-ct)

r figuring out which subset of logs should be checked. No doubt there are rough edges in this initial proposal, but is this idea worth pursuing? Or do folks feel that pursuing this idea would be too much of a distraction, and that we should instead focus on the long-term goal of getting "

Re: [Trans] Certificate Transparency Newsletter - August 2015

1] https://www.digicert.com/certificate-monitoring/ > [2] https://crt.sh/ > [3] https://github.com/tobermorytech/certificate-transparency-monitor -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Usage of Private Information Retrieval (PIR) in CT?

make it possible for servers/certs to optionally embed/send inclusion proofs instead of SCTs. When this option is used, the question of how to fetch inclusion proofs in a privacy preserving manner doesn't even need to be asked. :-) [1] http://trac.tools.ietf.org/wg/trans/trac/ticket/104

Re: [Trans] Usage of Private Information Retrieval (PIR) in CT?

>> Note [1] that for 6962-bis we're planning to make it possible for >> servers/certs to optionally embed/send inclusion proofs instead of SCTs. >> >> When this option is used, the question of how to fetch inclusion proofs >> in a privacy preserving manner

Re: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID

uest a 1.3... OID. (Without the >> ASN.1 >> tag and length, that would be 4 bytes for the first 128 logs, then 5 >> bytes >> thereafter). >> or >> 2. delegate a portion of the OID range 1.3..<0..16383>. (Without >> the >>

Re: [Trans] Usage of Private Information Retrieval (PIR) in CT?

arch doc, since we have no commitments to write individual docs for > these. I have grabbed text from 6962-bis, where appropriate, for these > sections. I would be happy to see others volunteer to write requirements > docs for these other elements of the CT system, but until then I am

Re: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID

ing OIDs from any OID arcs because I think making use of existing management entities would be overkill for allocating LogIDs. (If we had to involve IANA in allocating LogIDs, then I would not propose to use OIDs at all. Instead, I would propose "uint32 LogID", with unique integers allocated from a new dedicated IANA registry). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] Usage of Private Information Retrieval (PIR) in CT?

>> the arch doc, since we have no commitments to write individual docs for >>> these. I have grabbed text from 6962-bis, where appropriate, for these >>> sections. I would be happy to see others volunteer to write requirements >>> docs for these other ele

Re: [Trans] Usage of Private Information Retrieval (PIR) in CT?

w to create a name-redacted pre-cert. This seems > irrelevant to log > processing of pre-certs, since it doesn't appear to be a constraint > enforced by a log. > Text in 3.2.3 seems to be a set of directions to a CA, and maybe checks > to be performed by > a TLS client, but not

Re: [Trans] [trans] #105 (rfc6962-bis): Shrink LogID

were derived from the key. However, I agree that a log re-using a key from some other log would not be detected by this approach. Steve -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing l

Re: [Trans] Certificate Transparency Newsletter - August 2015

tension" This newly standardized certificate extension could be used to signal that the TLS server MUST send the CT TLS extension. I realize that this may not suit many early adopters, since few deployed servers support the CT TLS extension yet. But I figured it was worth mentioning.

Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015

On 19/10/15 14:29, Tom Ritter wrote: On 19 October 2015 at 06:31, Rob Stradling wrote: On 17/08/15 18:24, 'Adam Eijdenberg' via certificate-transparency wrote: (posted to certificate-transpare...@googlegroups.com, trans@ietf.org and ct-pol...@chromium.org) Lookahead: -

Re: [Trans] [ct-policy] Re: Certificate Transparency Newsletter - August 2015

g that the TRANS WG should specify (in 6962-bis or some other document)? Or should we punt it to WEBSEC or some other place? Thanks. On 19/10/15 17:29, Tom Ritter wrote: On 19 October 2015 at 09:05, Rob Stradling wrote: Perhaps 6962-bis should prohibit or recommend against using TLS Feature

Re: [Trans] [trans] #116 (rfc6962-bis): ned definition for mis-issuance

" Also, I suspect that this ticket is actually a duplicate of ticket #71. ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Onl

Re: [Trans] [trans] #117 (rfc6962-bis): log description as "untrusted"

ificates are added to it." _______ Trans mailing list Trans@ietf.org 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: +

Re: [Trans] proposed CA/Subject changes

oc for each component just seems like unnecessary editorial work. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] proposed CA/Subject changes

arate sections. It's likely that some implementers will have no interest in implementing precertificates. I think that conflating sections 3.1 and 3.2 would make it harder for those implementers to figure out which paragraphs they don't need to read. -- Rob Stradling Senior Research & De

Re: [Trans] [trans] #97 (rfc6962-bis): Allocate an OID for CMS precertificates

___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Onlin

[Trans] Oh...

http://trac.tools.ietf.org/wg/trans/trac/report/1 currently returns... "Oops… Trac detected an internal error: OperationalError: database or disk is full" Who can fix this? -- Rob Stradling Senior Research & Development Scientist COMODO - Creatin

Re: [Trans] Oh...

On 03/02/16 13:46, Stephen Farrell wrote: On 03/02/16 13:43, Rob Stradling wrote: http://trac.tools.ietf.org/wg/trans/trac/report/1 currently returns... "Oops… Trac detected an internal error: OperationalError: database or disk is full" Who can fix this? I'm not seeing tha

Re: [Trans] can CT defend against dual CA compromise?

e logged in the same logs as the end-entity certs they issue. - don't require SCTs or inclusion proofs for intermediates to be sent by TLS servers (except for the name-constrained case). - say that TLS clients SHOULD fetch and verify inclusion proofs for all intermediate certs that

Re: [Trans] can CT defend against dual CA compromise?

t TLS clients SHOULD fetch and verify inclusion proofs for all intermediate certs that they rely on. I'm nervous about this. Why so? I wasn't suggesting a "MUST". ;-) -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __

Re: [Trans] can CT defend against dual CA compromise?

On 23/02/16 10:41, Rob Stradling wrote: On 23/02/16 06:03, Tom Ritter wrote: [Rob] I think that blacklisting the shared issuer public key would be better than blacklisting the shared issuer name. At first glance, I agree - but there is that annoying trick where you can generate multiple (or

Re: [Trans] [trans] #23 (rfc6962-bis): How can TLS clients match an SCT to a certificate?

the certificates in the chain an SCT or inclusion proof corresponds to. ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505

Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers

e abound. This list will be used for answering questions of individual WG participants and for creating IETF-wide documentation on how to use GitHub effectively in WG processes." -- Rob Stradling Senior Research & Development Scientist C

Re: [Trans] [trans] #145 (rfc6962-bis): Section 9.2 (TLS clients) needs more guidance for browsers

at the time. If Github offers ways to help with version control on collaborative docs, I think that is to be encouraged. Yes! -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf

Re: [Trans] text to address DKG's conspiring CAs attack

intermediate _certificate_ just isn't sufficient. To be effective, the intermediate _public key_ needs to be revoked somehow. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] text to address DKG's conspiring CAs attack

work. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] text to address DKG's conspiring CAs attack

. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] text to address DKG's conspiring CAs attack

ificates issued by subordinate CA. Yes, that is DKG's attack. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

Re: [Trans] text to address DKG's conspiring CAs attack

s in a PKI. One revokes certs. Steve, I know very well how the existing IETF mechanisms for revocation (i.e. CRL and OCSP) work. But I don't see why that should mean that new revocation mechanisms can't be invented, especially if those new mechanisms can thwart attacks that CRL and OCSP

Re: [Trans] Co-existence of V1 and V2 embedded SCTs in certificates

gnore the V2 SCTs. V2 clients would remove the V1 SCTs and validate the signature over the resulting TBSCertificate, which would then exclude V1 and V2 SCTs and be identical to the TBSCertificate in the V2 (CMS) precertificate submitted to the log. Thoughts? Eran -- Rob Stradling Senior Rese

Re: [Trans] text to address DKG's conspiring CAs attack

mechanism, but CT won't need to be changed. I think raw key stuff is out of scope for now. Indeed. Revocation is out of scope for CT anyway. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1

Re: [Trans] Issue with redaction and CN-IDs

ilities around multiple CN-IDs, but we neglected to outlaw them in the CABF BRs. Ah, then ignore that question in the trans context. We can fix in the CABF context. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online __

Re: [Trans] Issue with redaction and CN-IDs

nds to the (zero or more) Subject CN(s), the second INTEGER corresponds to the first SAN dNSName, etc, etc. I also wonder how to handle multiple CN-IDs in a single certificate. There is not, to my knowledge, a requirement that the Subject only contain one attribute of type commonName. Thanks,

Re: [Trans] Issue with redaction and CN-IDs

s of labels in multiple CNs? I'm guessing not, in which case let's not make this more complex than it needs to be. Thanks, Peter -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ Trans mail

  1   2   3   >