I have read the draft and I support most of the ideas. However, is
publishing this as a separate RFC that updates RFC 6125 by patching it the
best way forward? I think it would be much better to rewrite RFC 6125 with
all the patches applied, and then have that new document obsolete
RFC 6125 instead
Leif Johansson wrote:
> Salz, Rich wrote:
> > *>* I think it would be much better to rewrite RFC 6125 with all the
> patches applied, and then have that new document obsolete RFC 6125 instead
> of updating it.
> >
> > I took another look at 6125 and I am happy to put up a draft if the WG
> prefer
Eliot Lear wrote:
>
>- CAs MUST populate a SAN.
>- Verifiers MUST use a SAN if present.
>- Verifiers MUST reject certificates without a SAN by default.
>- Verifiers MAY be configured to accept certificates without SANs when
>very long lived certificates are expected to be enco
Eliot Lear wrote:
> The issue for me is library support. If libraries take the doc too
> seriously, it screws the apps that really need to do the right thing for
> their use cases.
>
>
What you're trying to prevent is the entire purpose of this, as I had
originally proposed it. The goal is to ha
Eliot Lear wrote:
> [+iotops]
>
> Brian,
>
> On 21 Apr 2021, at 00:22, Brian Smith wrote:
>
> Eliot Lear wrote:
>
>> The issue for me is library support. If libraries take the doc too
>> seriously, it screws the apps that really need to do the right thing
Eliot Lear wrote:
> If this is scoped to dnsNames then I’m fine with it going forward as is.
> Other names would be problematic.
>
Could you be more specific as to what other names would be problematic and
list them explicitly? Here are the choices in a GeneralName:
otherName
Eliot Lear wrote:
> On 21 Apr 2021, at 20:25, Brian Smith wrote:
>
> otherName [0] OtherName,
> rfc822Name [1] IA5String,
> dNSName [2] IA5String,
> x400Address
Eliot Lear wrote:
> Actually, according to 802.1AR-2009, the subject MUST contain requires a
> DN with serial number, and it may contain a SAN (e.g., don’t count on it).
> That’s the major concern. To me, the rest is really negotiable.
>
OK, great. I don't think what Rich or what I'm proposing
Salz, Rich wrote:
>
>
>- Some sections mention "server" while other sections does not state
>anything, therefor applying to both client and server. I think the draft
>needs to be very clear on this point.
>
>
>
>- I saw that there was a discussion on client certs and that some
>
Jim Fenton wrote:
> Rich replied:
>
> > Clients must be free to ignore wildcards, because of things like *.
> air-traffic-control.aero and others that are on the public suffix list.
>
> Does that then mean that there is an obligation on the part of certificate
> checkers to make sure that public
Ryan Sleevi wrote:
> On Mon, Jul 12, 2021 at 4:20 PM Brian Smith wrote:
> > If we get to the part of validation where RFC 6125 is relevant then we
> already know the wildcard dNSName subjectAltName entry is valid. Given
> that, RFC 6125 just needs to specify how to match, s
On Sun, Oct 5, 2014 at 12:26 PM, Yaron Sheffer wrote:
> 1. Say explicitly that opportunistic TLS is out of scope.
> 2. Or say explicitly that it is in scope, and with the same requirements as
> "regular" TLS.
> 3. Or come up with a different set of requirements for opportunistic TLS.
I think you
On Tue, Nov 11, 2014 at 6:01 PM, Orit Levin (LCA) wrote:
> https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
> o Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246].
>
> Rationale: TLS 1.0 (published in 1999) does not support many
> modern, strong cipher suites.
I thi
Stephen Farrell wrote:
> 3) Wrt Brian's point about DHE 1024, I think that was already discussed
> on the list earlier and while the mozilla figures are interesting they
> don't change my mind - I think the benefit of PFS and the fact that
> s/w updates can fix this silently after one has configur
On Thu, Nov 13, 2014 at 6:15 PM, Peter Saint-Andre - &yet
wrote:
> The authors have given this further consideration and we have a question: in
> practice will it be OK to send *both* status_request and status_request_v2
> in the same handshake?
If the client supports both, then it will include b
Draft 7 says 'Thanks to Brian Smith, whose "browser cipher suites"
page is a great resource.' I very much appreciate the thank-you. Could
you please adjust the reference to the proposal:
s/"browser cipher suites"/"Proposal to Change the Default TLS
Ciphersui
Stephen Kent wrote:
> These numbers suggest a 35%-40% performance penalty for 256-bit vs. 128-bit
> AES.
> So, on a percentage basis, that's non-trivial. But, in terms or raw
> performance,
> it may not be an issue for many platforms. Not clear how this plays out
> for smart phones. I hope someone
Peter Saint-Andre - &yet wrote:
> OLD
>o There are no protocol mechanisms to negotiate the DH groups or
> parameter lengths supported by client and server.
>
>o Many servers choose DH parameters of 1024 bits or fewer.
>
>o There are widely deployed client implementations th
Peter Saint-Andre - &yet wrote:
> On 11/11/14, 9:10 PM, Brian Smith wrote:
>>>o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>>>
>>>o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>>>
>>>o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>>>
>
Peter Saint-Andre - &yet wrote:
> On 12/1/14, 9:43 PM, Massimiliano Pala wrote:
>>
>> Hi Peter, all,
>>
>> It looks ok.. although I would have preferred to maintain some kind of
>> reference to partitioned and delta CRL with reference to X.509 (PKIX) -
>> since we are talking about TLS, x.509 is t
On Tue, Dec 2, 2014 at 11:34 PM, Stephen Farrell
wrote:
>
> Hi Brian,
>
> I'm not seeing what part of your email is new and not
> something already discussed by the WG. Can you clarify?
I answered the question that was asked of me.
Cheers,
Brian
___
U
Richard Barnes wrote:
> Pete Resnick wrote:
>> Until we are able to get better community consensus on this topic and how
>> to explain it in documents, I think (and I believe the WG agrees) that the
>> right thing to say is, "This document isn't talking about OS" and leave it
>> at that, which is
Richard Barnes wrote:
> On Thu, Feb 19, 2015 at 1:26 AM, Brian Smith wrote:
>> IMO, unauthenticated TLS is so different from secure use of TLS that
>> it deserves its own document once we've learned what the *best*
>> *current* practices for unauthenticated TLS are, wh
On Fri, Apr 10, 2015 at 9:34 AM, Leif Johansson wrote:
> This starts a 2 week WGLC on draft-ietf-uta-email-tls-certs. Please
> provide your comments on the UTA list before EOB (any TZ) Friday April
> 24 2015.
What is the reason for making SRV-ID support required for email client
software implemen
Viktor Dukhovni wrote:
> Brian Smith wrote:
>> That said, maybe I'm not understanding the importance of SRV-ID.
>> Clarification of why supporting SRV-ID is important would be useful.
>
> My understanding is that clients should support SRV-ID when they
> locate the s
Alexey Melnikov wrote:
> On 12/04/2015 00:08, Brian Smith wrote:
>> Even if the client uses SRV records, it will still operate just fine
>> using DNS-IDs and without supporting SRV-ID, right?
>
> In general case this is not true. This will only work correctly if DNS SRV
>
Viktor Dukhovni wrote:
> Brian Smith wrote:
>
>> When the MUA connects to imap.gmail.com, how would the server know
>> which certificate to give the MUA? Would the MUA put
>> "_imap.example.com" in the SNI extension of the TLS ClientHello when
>> connecti
27 matches
Mail list logo
