Executive Summary: I have submitted
https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-04
that (hopefully) resolve the gen-art and secdir feedback.
Paul Kyzivat writes:
> This draft is on the right track but has open issues, described in the
> review.
Hello Paul. I am sorry for the delay i
Ben Campbell writes:
>> -- section 7
>>
>> Does the GSS-API description introduce security considerations? If
>> not, please say so.
>>
>
> I did not see a response to this comment.
I missed this in my last e-mail. I propose we add another sub-section
of the security considerations like this
Ben Campbell writes:
> -- section 4, 3rd and 4th paragraph (paragraph a and b)
>
> These seem like protocol affecting differences. If so, they need
> elaboration, such as normative statements and formal definitions, or
> references to such.
>
> -- section 5, general:
>
> The section seems to need
writes:
> Some form of identifier will be required for the otp-algID in the
> PA-OTP-CHALLENGE and the PA-OTP-REQUEST and from what I remember about
> when this was first discussed, it was agreed that it would make sense
> to use the registry of identifiers already being established for PSKC
> ra
Hi Kathleen,
Thank you for the careful review. I have no objections to your proposed
changes, and have merged them into my private copy. I've asked Sean
whether I should submit a new document or wait until AUTH48 to fix this.
Regards,
/Simon
writes:
> I am the assigned Gen-ART reviewer for t
Alexey Melnikov writes:
>>The I-D says:
>>
>>The original
>> GSS-API->SASL mechanism bridge was specified by [RFC], now
>> [RFC4752]; we shall sometimes refer to the original bridge as GS1 in
>> this document.
>>
>>I don't see
Nicolas Williams writes:
>> In particular, the current consensus of the SASL community appears to
>> be that SASL "security layers" (i.e., confidentiality and integrity
>> protection of application data after authentication) are too complex
>> and, since SASL applications tend to have an
"Spencer Dawkins" writes:
> Summary: This document is almost ready for publication as a Proposed
> Standard. I did have one minor question about 13.3 (in my LATE
> review), but it should not be difficult to resolve, if an AD agrees
> with my question.
Hi Spencer. Thank you for your careful revi
"Miguel A. Garcia" writes:
> Summary: The document is ready for publication as an informational RFC.
Thanks for review!
> Nits/editorial comments:
>
> - Expand acronyms at first occurrence. This includes: SRP
Fixed, thanks.
> - Section 5, 6th paragraph:
>
> s/a list that map realm names/a lis
Ben Campbell writes:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please wait for direction from your document shepherd
> or AD before posting a new
Elwyn Davies <[EMAIL PROTECTED]> writes:
> Hi.
>
> Think we are almost done
Yup. Thanks for following up on the review.
/* Decode base64 encoded input array IN of length INLEN to
output array OUT that can hold *OUTLEN bytes. Return
true if decoding was success
Elwyn Davies <[EMAIL PROTECTED]> writes:
> I looked over the diff .. couple of notes below.
>
> Glad you trapped the test vector errors!
Yup. Just checking if anyone was paying attention... :)
> Simon Josefsson wrote:
>> Hello Elwyn, and thanks for your care
Hello Elwyn, and thanks for your careful review!
I have incorporated most of your suggestions (see below) and updated
the document. The new document, with yours (and others) fixes, is
available from:
http://josefsson.org/base-encoding/draft-josefsson-rfc3548bis.txt
The differences compared to t
13 matches
Mail list logo
