Apologies for the slow reply, currently travelling with limited Internet
access...
>Header/Abstract/Intro: Doesn't this update RFC 6347 and either or both of RFC
>6066 and RFC 5246 since it defines a new extension?
It doesn't really update any other RFC, it does add a new extension but then
the p
>However, there are some issues (mostly editorial) that I would like the
>authors to address.
One comment on this, I didn't write the original text so I'll try and
accommodate as much as possible, but in some cases I've had to guess at what
the original authors intended. Also, the explanations fo
Hi,
>Maybe some text about all that somewhere (e.g., in the Introduction section,
>or in a dedicated "History" section)?
The "Background Notes" section already contains a pretty complete (without
going overboard) history and notes on what changed. What I can do if this
will help is add a referen
Replying to my own message: The proposed text would then read:
This specification defines a protocol, Simple Certificate Enrolment Protocol
(SCEP), for certificate management and certificate and CRL queries. While
widely deployed (see the Background Notes
section for more on the history behind SC
Steve Fenter writes:
>I've done a fair amount of TLS handshake troubleshooting, and it's usually
>long and painful because the error codes are so vague.
>[...]
>The vague error messages are leading directly to more downtime, and this
>should be balanced with the other security needs.
This was
Bill Frantz writes:
>We have always avoided the long form error messages in TLS because they can
>be of great help to attackers as well as debuggers.
That's why I said it was a debug-only capability, not an always-enabled on-by-
default capability.
>I think this objection is much weaker if we
Kathleen Moriarty writes:
>I agree with Eric’s assessment, this could be in a new draft as an extension.
Anyone want to work on this? I can contribute a bit by recycling the EtM
text, which sets out how to communicate a boolean flag (for "I speak extended
alerts") as an extension, apart from t
Salz, Rich writes:
>>format, which I assume just means adding a free-form text field to the
>>existing alerts.
>
>Doesn't it have to be tagged with language and codeset these days?
Possibly, if you consider being able to say "Invalid length encoding in
preferred-ECC-curves extension" in
Eric Rescorla writes:
>In my experience, there are four major scenarios for diagnosing this kind of
>failure. Under the assumption that you control one end, the other end can be:
>
>1. A live endpoint.
>2. A testing endpoint someone has put up.
>3. An endpoint that someone is actively working on
Ion Larranaga Azcue writes:
>And for the malicious user that, knowing the server is currently in debug
>mode and returning extended errors, can more easily perform attacks on it...
If there's someone on the Internet who can scan every TLS server on the planet
once a minute to see a brief debug w
Linda Dunbar via Datatracker writes:
>It needs to be made clear of the consequences if those PKC test keys are not
>published. Recommend adding a paragraph to describe behaviors when those PKC
>test keys are not specified.
Uh, I'm not sure I understand the problem, if the keys aren't published
t
11 matches
Mail list logo
