Re: [Gen-art] Genart last call review of draft-ietf-wish-whip-09

[Sean Turner]

Dale,

Hi! Just a heads up that Sergio is out on PTO until early September.

spt

> On Aug 8, 2023, at 11:45, Dale Worley via Datatracker  
> wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document:  draft-ietf-wish-whip-09
> Reviewer:  Dale R. Worley
> Review Date:  2023-08-08
> IETF LC End Date:  2023-08-08
> IESG Telechat date:  [not known]
> 
> Summary:
> 
>This draft is on the right track but has open issues, described in
>the review.
> 
> The exposition could be clarified in several places.  A few of the
> clarifications could be considered technical issues.  I list the
> issues in textual order, with an initial summary of the most important
> issues.
> 
> * Summary of the major issue:
> 
> A very important aspect of this document is that it defines the usage
> of "ICE via SDP via HTTP", equivalently, "supporting ICE offer/answer
> over HTTP" (as opposed to the original "ICE via SDP via SIP").  That
> definition likely will have broader usage than just WHIP.  But the
> document suffers from the "expert's disease", in that the authors
> clearly have deep knowledge of ICE and consequently only document the
> details of the ICE processing without providing any of the framework.
> This leaves naive readers to reconstruct the big picture.  I was going
> to add "As far as I can tell, all of the needed details are listed
> somewhere in section 4", but as you can see below, once I wrote an
> outline of what is needed, there are a few points that don't seem to
> be specified, at least not to the point that I recognized it.)
> 
> I suggest that section 4 be organized by:
> 
> - stating that it is defining "supporting ICE offer/answer
>  over HTTP" (so that it can be clearly referenced by later
>  specifications)
> 
> - specifying the abstract operations involved (with the mapping to
>  specific operations listed either in this list or a later list):
> 
> - - starting the ICE negotiation (via POST carrying
>application/sdp)
> 
> - - updating the ICE when trickling (via PATCH carrying
>application/trickle-ice-sdpfrag)
> 
> - - restarting ICE (via PATCH carrying (via PATCH carrying
>application/trickle-ice-sdpfrag, but it's not clear how this is
>distinguished, RFC 8840 does not specify it; perhaps because it
>carries ice-ufrag/ice-pwd attributes (see section 4.1)?)
> 
> - - termination (via DELETE from the client; not clear how from the
>server)
> 
> - specifying how WHIP constrains the ICE abstraction (Media server
>  MUST not do trickle ICE updates, not clear if Media server MAY do
>  ICE restarts, Media server MAY not support trickle ICE or ICE
>  restart, etc.)
> 
> - discussion of how out-of-order requests may arise (which isn't at
>  all clear to me, as requests seem to be generated only by the
>  server, and carried by TCP, so they seem to be inherently
>  serialized)
> 
> - discussion of how ETags MAY/MUST be handled, as that is
>  comprehensible only when one looks at the serialization needs of all
>  of the operations together
> 
> - specifying the particular features of each of the operations,
>  including any particulars of request and response fields and what
>  response codes are to be used for what error situations
> 
> * Summary of minor issues that might have technical content:
> 
> At various points in section 4 the text refers to a device sending a
> request or generating a response but in many of them, the text doesn't
> state whether the device is on the client or server end, or might be
> both.  I assume that the nature of the operation implies what devices
> might perform it based on text elsewhere, but it's hard to fully
> understand on the first reading pass.  If possible, each sentence
> should make this clear. -- Then again, if section 4 is reorganized to
> describe generic ICE/SDP/HTTP usage, attention should be paid that the
> generic usage may define how e.g. the server does an operation, even
> if WHIP servers may not do that operation.
> 
> Section 4 lists a collection of 4xx and 5xx response codes to be used
> in certain situations.  Are these set due to the specific semantics of
> the codes or just to ensure that the recipient can tell what the cause
> of the error was?  (HTTP suffers from having a large number of error
> responses but all of them have vague semantics.  Unfortunately, there
> doesn't seem to be an HTTP response header that can carry codes
> defined for ICE usage specifically.)
> 
> Section 4 requires the WHIP server to reject certain specific request
> methods, but no others.  Verify that you intend this specific
> limitation.
> 
> Section 4.1 references 

Re: [Gen-art] Genart last call review of draft-ietf-lamps-documentsigning-eku-04

[Sean Turner]

Dale,

Thanks for the review.  Version -05 should address these:
https://datatracker.ietf.org/doc/draft-ietf-lamps-documentsigning-eku/
https://www.ietf.org/rfcdiff?url1=draft-ietf-lamps-documentsigning-eku-04=draft-ietf-lamps-documentsigning-eku-05=--html

spt

> On Aug 7, 2022, at 15:45, Dale Worley via Datatracker  
> wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document:  draft-ietf-lamps-documentsigning-eku-04
> Reviewer:  Dale R. Worley
> Review Date:  2022-08-07
> IETF LC End Date:  2022-08-11
> IESG Telechat date:  (none)
> 
> Summary:
> 
>This draft is basically ready for publication, but has nits that
>should be fixed before publication.
> 
> The technical content of the draft is quite good, but there is an
> editorially critical issue regarding the allocation of the
> identifiers.  There are three places where "to be done" identifiers
> are specified:
> 
> 3.1.  Including the Extended Key Purpose for Document Signing in
> 
> id-kp-documentSigning  OBJECT IDENTIFIER  ::=  { id-kp XX }
> 
> 8.2.  Informative References
> 
> Appendix A.  ASN.1 Module
> DocSignEKU { iso(1) identified-organization(3) dod(6) internet(1)
>   security(5) mechanisms(5) pkix(7) id-mod(0)
>   id-mod-docsign-eku(TBD1) }
> 
> id-kp-documentSigning OBJECT IDENTIFIER ::= { id-kp TBD2 }
> 
> However, section 7 "IANA Considerations" does not explicitly mention
> any of these substitutions.  Compare with
> e.g. draft-ietf-curdle-cms-chacha20-poly10305.  Section 7 does say
> that assignments need to be made to the appropriate registries but
> provides no reference or "Note to the Editor" what substitutions need
> to be made in the text.  Also, "XX" must be the same as "TBD2", but
> that is not specified.
> 
> There is also a redundant specification at the end of section 7,
> 
>   No further action is necessary by IANA.
> 
> Given that the previous sentences in the paragraph state that there
> are two actions and then enumerate them, adding a statement that there
> are no others is redundant.
> 
> [END]
> 
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [Last-Call] Genart last call review of draft-uberti-rtcweb-rfc8829bis-02

[Sean Turner]

bump

> On Apr 26, 2022, at 21:39, Sean Turner  wrote:
> 
> Hi! I would really love to give our AD a revised version of this I-D soon.
> 
>> On Apr 17, 2022, at 12:37, Christer Holmberg 
>>  wrote:
>> 
>> Hi,
>> 
>>> I feel very strongly that we must reference a stable version or else there 
>>> is no way to know what is reviewed. The w3c spec was not approved before 
>>> and was a draft
>>> so it was hard but at this point I think the REC version is the correct 
>>> references. 
>> 
>> I don't object to referencing a specific version - I actually agree.
>> 
>> My question is why JSEP uses an INFORMATIVE WebRTC reference WITH a version, 
>> while other RTCWEB RFCs use NORMATIVE WebRTC references WITHOUT a version...
> 
> I didn’t do an exhaustive search, but I did note that
> RFCs 8825, 8827, and 8834 refer to the the W3C specification normatively as 
> follows:
> https://www.w3.org/TR/webrtc/
> There is no chance that there is any energy whatsoever to go back and change 
> those three to refer to a specific version. So I think we will need to call 
> those done.
> 
> For this I-D, I originally submitted the following PR to update the reference 
> to the final recommendation.  I have updated that PR to also move the 
> reference to be normative. See:
> 
> https://github.com/rtcweb-wg/jsep/pull/1024
> 
> Is there any objection to moving the reference to normative?
> 
>>> So it should reference https://www.w3.org/TR/2021/REC-webrtc-20210126
>> 
>> RFC 8829 references https://www.w3.org/TR/2020/PR-webrtc-20201215/. I just 
>> want to verify that there is no text etc in 8829bis that is not aligned with 
>> 20210126.
> 
> Harald or Cullen can one of you comment on this? The vast majority of PRs 
> merged into the 202110126 version were marked as editorial.
> 
> spt
> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>>> On Mar 29, 2022, at 6:39 AM, Christer Holmberg 
>>> <mailto:christer.holmberg=40ericsson@dmarc.ietf.org> wrote:
>>> 
>>> Hi,
>>> 
>>> A couple of comments:
>>> 
>>> First, in general, if we are going to update the reference version, we need 
>>> to verify that we don’t break anything.
>>> 
>>> Second, most of the RTCWEB RFCs referencing the WebRTC spec seem to 
>>> reference *without* a version (i.e., https://www.w3.org/TR/webrtc/). Many 
>>> RFCs also reference to RFC 8825 for WebRTC, and RFC 8825 also reference 
>>> WebRTC without a version.
>>> 
>>> So, is there a reason why we would use a version in JSEP, while not in 
>>> other RFCs? Note that often the WebRTC reference is Normative.
>>> 
>>> I do understand that JSEP is very closely linked to WebRTC, why there might 
>>> be a need to reference a given version. But, then again, we need to make 
>>> sure that updating the version does not break anything.
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> From: Gen-art <mailto:gen-art-boun...@ietf.org> on behalf of Joel M. 
>>> Halpern 
>>> <mailto:j...@joelhalpern.com>
>>> Sent: Tuesday, March 29, 2022 6:08:37 AM
>>> To: Sean Turner <mailto:s...@sn3rd.com>
>>> Cc: mailto:last-c...@ietf.org <mailto:last-c...@ietf.org>; 
>>> mailto:gen-art@ietf.org 
>>> <mailto:gen-art@ietf.org>; RTCWeb IETF <mailto:rtc...@ietf.org>; 
>>> mailto:draft-uberti-rtcweb-rfc8829bis@ietf.org>> mailto:9bis@ietf.org>
>>> Subject: Re: [Gen-art] Genart last call review of 
>>> draft-uberti-rtcweb-rfc8829bis-02
>>> 
>>> Thanks Sean.  I finally concluded that was the intent.  And I think 
>>> technically it says so.
>>> If you could look at making that more clear early, it would probably 
>>> help those readers who are not as familiar with the cited W3C API.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 3/28/2022 10:47 PM, Sean Turner wrote:
>>>> 
>>>> 
>>>>> On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker 
>>>>> <mailto:nore...@ietf.org> wrote:
>>>>> 
>>>>> Reviewer: Joel Halpern
>>>>> Review result: Ready with Issues
>>>>> 
>>>>> I am the assigned Gen-ART reviewer for this draft. The General Area 
>>>>> Review Team (Gen-ART) reviews all IETF documents being 

Re: [Gen-art] [Last-Call] Genart last call review of draft-uberti-rtcweb-rfc8829bis-02

[Sean Turner]

Hi! I would really love to give our AD a revised version of this I-D soon.

> On Apr 17, 2022, at 12:37, Christer Holmberg  
> wrote:
> 
> Hi,
> 
>> I feel very strongly that we must reference a stable version or else there 
>> is no way to know what is reviewed. The w3c spec was not approved before and 
>> was a draft
>> so it was hard but at this point I think the REC version is the correct 
>> references. 
> 
> I don't object to referencing a specific version - I actually agree.
> 
> My question is why JSEP uses an INFORMATIVE WebRTC reference WITH a version, 
> while other RTCWEB RFCs use NORMATIVE WebRTC references WITHOUT a version...

I didn’t do an exhaustive search, but I did note that
RFCs 8825, 8827, and 8834 refer to the the W3C specification normatively as 
follows:
https://www.w3.org/TR/webrtc/
There is no chance that there is any energy whatsoever to go back and change 
those three to refer to a specific version. So I think we will need to call 
those done.

For this I-D, I originally submitted the following PR to update the reference 
to the final recommendation.  I have updated that PR to also move the reference 
to be normative. See:

https://github.com/rtcweb-wg/jsep/pull/1024

Is there any objection to moving the reference to normative?

>> So it should reference https://www.w3.org/TR/2021/REC-webrtc-20210126
> 
> RFC 8829 references https://www.w3.org/TR/2020/PR-webrtc-20201215/. I just 
> want to verify that there is no text etc in 8829bis that is not aligned with 
> 20210126.

Harald or Cullen can one of you comment on this? The vast majority of PRs 
merged into the 202110126 version were marked as editorial.

spt

> Regards,
> 
> Christer
> 
> 
> 
>> On Mar 29, 2022, at 6:39 AM, Christer Holmberg 
>> <mailto:christer.holmberg=40ericsson@dmarc.ietf.org> wrote:
>> 
>> Hi,
>> 
>> A couple of comments:
>> 
>> First, in general, if we are going to update the reference version, we need 
>> to verify that we don’t break anything.
>> 
>> Second, most of the RTCWEB RFCs referencing the WebRTC spec seem to 
>> reference *without* a version (i.e., https://www.w3.org/TR/webrtc/). Many 
>> RFCs also reference to RFC 8825 for WebRTC, and RFC 8825 also reference 
>> WebRTC without a version.
>> 
>> So, is there a reason why we would use a version in JSEP, while not in other 
>> RFCs? Note that often the WebRTC reference is Normative.
>> 
>> I do understand that JSEP is very closely linked to WebRTC, why there might 
>> be a need to reference a given version. But, then again, we need to make 
>> sure that updating the version does not break anything.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Gen-art <mailto:gen-art-boun...@ietf.org> on behalf of Joel M. Halpern 
>> <mailto:j...@joelhalpern.com>
>> Sent: Tuesday, March 29, 2022 6:08:37 AM
>> To: Sean Turner <mailto:s...@sn3rd.com>
>> Cc: mailto:last-c...@ietf.org <mailto:last-c...@ietf.org>; 
>> mailto:gen-art@ietf.org 
>> <mailto:gen-art@ietf.org>; RTCWeb IETF <mailto:rtc...@ietf.org>; 
>> mailto:draft-uberti-rtcweb-rfc8829bis@ietf.org> mailto:9bis@ietf.org>
>> Subject: Re: [Gen-art] Genart last call review of 
>> draft-uberti-rtcweb-rfc8829bis-02
>> 
>> Thanks Sean.  I finally concluded that was the intent.  And I think 
>> technically it says so.
>> If you could look at making that more clear early, it would probably 
>> help those readers who are not as familiar with the cited W3C API.
>> 
>> Yours,
>> Joel
>> 
>> On 3/28/2022 10:47 PM, Sean Turner wrote:
>>> 
>>> 
>>>> On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker 
>>>> <mailto:nore...@ietf.org> wrote:
>>>> 
>>>> Reviewer: Joel Halpern
>>>> Review result: Ready with Issues
>>>> 
>>>> I am the assigned Gen-ART reviewer for this draft. The General Area 
>>>> Review Team (Gen-ART) reviews all IETF documents being processed by 
>>>> the IESG for the IETF Chair.  Please treat these comments just like 
>>>> any other last call comments.
>>>> 
>>>> For more information, please see the FAQ at
>>>> 
>>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>> 
>>>> Document: draft-uberti-rtcweb-rfc8829bis-02
>>>> Reviewer: Joel Halpern
>>>> Review Date: 2022-03-27
>>>> IETF LC End Date: 2022-04-05
>>>> IESG Telechat date: N

Re: [Gen-art] Genart last call review of draft-uberti-rtcweb-rfc8829bis-02

[Sean Turner]

> On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker  
> wrote:
> 
> Reviewer: Joel Halpern
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-uberti-rtcweb-rfc8829bis-02
> Reviewer: Joel Halpern
> Review Date: 2022-03-27
> IETF LC End Date: 2022-04-05
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is ready for publication as a Proposed Standard. 
> However, there are some issues that should be considered before final 
> approval.
> 
> Major issues: None
> 
> Minor issues:
>I found myself confused as a reader about one aspect of this document  The
>document seems to describe both the Interface to the JSEP and the details
>of what the underlying system must do in response to JSEP operations.  The
>later is described very well and clearly.  The former is described quite
>vaguely.  I suspect that the assumption is that the required parameters are
>described in the W3C documents.  But it is hard to tell, and the only
>formal reference is a vague citation in the introduction to an outdated W3C
>specification.  A little more clarity on how an implementor is supposed to
>know what actual interface objects, methods, and parameters they need to
>provide would be helpful.  Also, the reference should be updated to
>whatever is the current W3C specification.

Will check on updating the reference. I would be floored if we couldn’t point 
to it.

The basic idea here is that the W3C WebRTC spec is API and this is the protocol 
spec.

> Nits/editorial comments:
> 
> 
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] draft-ietf-lamps-5480-ku-clarifications-01

[Sean Turner]

> On Mar 3, 2020, at 16:09, Alissa Cooper  wrote:
> 
> Dale, thanks for your reviews. Sean, thanks for your responses. I entered a 
> No Objection ballot. If Dale’s questions can be clarified for non-expert 
> readers, I think that would be good.
> 
> Alissa
> 
> 
>> On Mar 1, 2020, at 11:00 PM, Dale R. Worley  wrote:
>> 
>> Looking at draft-ietf-lamps-5480-ku-clarifications-01, these points
>> occur to me:
>> 
>>  1.  Introduction
>> 
>>  This document corrects this omission, by updating Section 3 of
>>  [RFC5480] to make it clear that neither keyEncipherment nor the
>>  dataEncipherment key usage bits are set for key agreement algorithms.
>> 
>> I think it would be more accurate to say something like "neither ... are
>> set in certificates that specify key agreement algorithms" -- usage bits
>> are logically a component of a certificate rather than a feature of an
>> algorithm.
>> 
>> But it's unclear to me whether id-ecPublicKey is only used in key
>> agreement certificates.  RFC 5480 states that if the cert uses id-ecDH
>> or id-ecMQV and provides keyUsage, then keyAgreement must be set.  So
>> it's clear that certs with id-ecDH or id-ecMQV are key agreement certs.
>> But RFC 5480 says that if the cert lists id-ecPublicKey, then
>> keyAgreement is optional.  That suggests to me that some certs can use
>> id-ecPublicKey without being key agreement certs.  In turn, section 1 of
>> this I-D suggests the I-D is not intended to apply to those certs, but
>> section 3 seems to apply to them anyway.
>> 
>> To try to distill it to one sentence:  Can id-ecPublicKey appear in
>> certs that are not for key agreement, and if so, are keyEncipherment and
>> dataEncipherment allowed in the keyUsage of those certs?
>> 
>>  3.  Updates to Section 3
>> 
>>  If the keyUsage extension is present in a certificate that indicates
>>  in SubjectPublicKeyInfo, then following values MUST NOT be present:
>> ---^
>> 
>> Is "id-ecPublicKey" missing here?

Yes - The OPSDIR review noted my took quick to submit.  It’s fixed in this 
version:

https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/

>>  If the keyUsage extension is present in a certificate that indicates
>>  id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
>>  values also MUST NOT be present:
>> 
>> Is it a fact that all certificates with these three algorithms are
>> certificates for key agreement?  If so, it would be nice to state that
>> either in section 3 or section 1, to show how section 3 is connected
>> with "for key agreement algorithms" in section 1.  Otherwise, the
>> connection between the two requires information that is stated
>> elsewhere.

To address this, I ended up making the following tweaks in s1:

 This document corrects this omission, by updating Section 3 of
 [RFC5480] to make it clear that neither keyEncipherment nor the
 dataEncipherment key usage bits are set for key agreement algorithms
 defined therein.  The additions are to be made to the end of
 Section 3.

So, there’s a link from 5480 s3 where the three algorithms are defined to this 
document’s s3.

spt

>> Dale
>> 
>> ___
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
> 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00

[Sean Turner]

> On Feb 20, 2020, at 21:03, Dale R. Worley  wrote:
> 
> Sean Turner  writes:
>>>> From the discussion it appears that id-ecDH and id-ecMQV are "key
>>> agreement algorithms" and that, as such, they should not be used with
>>> keyEncipherment or dataEncipherment.  [this draft, section 3]
>>> Conversely, id-ecPublicKey is not a "key agreement algorithm".  [RFC
>>> 5480, section 2.1.2, para. 1, sentence 1]
>> 
>> Ah ... this might be where some of misunderstanding comes from because
>> id-ecPublicKey MAY be a key agreement algorithm that is why it is
>> "unrestricted". In other words, when key agreement certificates can
> I assume that "when" in the above line should be omitted.
>> include the following OIDs: id-ecDH (for an EC DH algorithm), id-ecMQV
>> (for EC MQV), or id-ecPublicKey (for any algorithm). Here's the text
>> from 5480 about id-ecPublicKey being used as key agreement algrithm:
>> 
>> If the keyUsage extension is present in an End Entity (EE)
>> certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo,
>> then any combination of the following values MAY be present:
>> 
>> digitalSignature;
>> nonRepudiation; and
>> keyAgreement.
> 
> I'm still finding this an uphill climb.  If I understand you correctly,
> "key agreement" is not an attribute of an algorithm per se, but rather
> an attribute of a certificate.  And thus id-ecPublicKey may be specified
> in a key agreement certificate (that is, one with keyAgreement), but can
> also be specified in non-key agreement certificates (that is, ones
> without keyAgrement).  But id-ecDH and id-ecMQV may only be used in key
> agreement certificates, and in that sense they can be considered "key
> agreement algorithms".  Is that correct?
> 
> Dale

Yes.

BTW - I spun a new version to make the changes I noted early (at the request of 
Roman)

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00

[Sean Turner]

Dale,

Hi! And, thanks for your review comments in-line.

spt

> On Feb 18, 2020, at 22:07, Dale Worley via Datatracker  
> wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft.  The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document:  draft-ietf-lamps-5480-ku-clarifications-00
> Reviewer:  Dale R. Worley
> Review Date:  2020-02-18
> IETF LC End Date:  2020-02-07
> IESG Telechat date:  [unknown]
> 
> Summary:
> 
>   This draft is on the right track but has open issues, described
>   in the review.
> 
> The text is difficult to follow in places.  I believe that the WG has
> a clear understanding of what is intended, but a few small editorial
> errors have unfortunately rendered the text incorrect and
> contradictory to RFC 5480.

Sometimes when you are too familiar with the context you assume too much so a 
fresh set of eye can help!

> Note that I am unfamiliar with the details of PKI certificates; this
> review is based largely on what I have learned from RFC 5480 and this
> I-D.
> 
>> From the discussion it appears that id-ecDH and id-ecMQV are "key
> agreement algorithms" and that, as such, they should not be used with
> keyEncipherment or dataEncipherment.  [this draft, section 3]
> Conversely, id-ecPublicKey is not a "key agreement algorithm".  [RFC
> 5480, section 2.1.2, para. 1, sentence 1]

Ah ... this might be where some of misunderstanding comes from because 
id-ecPublicKey MAY be a key agreement algorithm that is why it is 
“unrestricted”. In other words, when key agreement certificates can include the 
following OIDs: id-ecDH (for an EC DH algorithm), id-ecMQV (for EC MQV), or 
id-ecPublicKey (for any algorithm). Here’s the text from 5480 about 
id-ecPublicKey being used as key agreement algrithm:

If the keyUsage extension is present in an End Entity (EE)
certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo,
then any combination of the following values MAY be present:

 digitalSignature;
 nonRepudiation; and
 keyAgreement.

> 1.  Introduction
> 
>   This document corrects this omission, by updating Section 3 of
>   [RFC5480] to make it clear that neither keyEncipherment nor the
>   dataEncipherment key usage bits are set for key agreement algorithms.
> 
> This could be clearer by replacing or augmenting "key agreement
> algorithms" with a description of which of these algorithms are key
> agreement algorithms, viz., id-ecDH and id-ecMQV.  Otherwise, one must
> first have read RFC 5480 to understand this introduction correctly.

See above.

I also pondered how much to put in the intro to accommodate those readers that 
are not as familiar with RFC 5480. I went the minimal route since this is 
supposed to be just adding two sentences to RFC 5480. I sure hope people that 
are not intimately familiar with RFC 5480 do immediately go read RFC 5480 
because this draft isn’t all that much use without doing so :)

> 3.  Updates to Section 3
> 
>   If the keyUsage extension is present in a certificate that indicates
>   id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in
>   SubjectPublicKeyInfo, then following values MUST NOT be present:
> 
> keyEncipherment; and
> dataEncipherment.
> 
>   If the keyUsage extension is present in a certificate that indicates
>   id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following
>   values also MUST NOT be present:
> 
> keyEncipherment; and
> dataEncipherment.
> 
> The structure of this section is peculiar, since it presents almost
> the same text about "id-ecPublicKey" and about "id-ecDH or id-ecMQV".
> If the intention is to say the same thing about all three, these
> should be folded together.

There are two reasons I’d like to not merge these two bits of text:

1. Agreed it is a bit odd, but it does mirror RFC 5480, which talks about 
id-ecPublicKey for CA certificates and then EE certificates and then 
id-ecDH/id-ecMQV. I guess we could collapse it, but for me then it’s a style 
thing and I’d rather mimic the RFC it’s updating.

2. With separate sentences we leave open the door for ECC encryption algorithms 
like ECIES


These algorithm need a lot of metadata (including EC point, KDF algorithm, hash 
algorithms, metadata of hash or KDF, etc…), and we are not sure, but believe, 
when specified they will not use id-ecPublicKey.
However, they may use SubjectPublicKeyInfo for their metadata.

If we integrate two sentence together, a possible future ECIES draft will 
conflict with our draft.

> It is also not clear why the first paragraph refers to
> AlgorithmIdentifier but the second paragraph uses 

Re: [Gen-art] Genart last call review of draft-ietf-rtcweb-security-arch-18

[Sean Turner]

I generated PR for these:
https://github.com/rtcweb-wg/security-arch/pull/85

> On Feb 9, 2019, at 13:50, Russ Housley  wrote:
> 
> Reviewer: Russ Housley
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-rtcweb-security-arch-18
> Reviewer: Russ Housley
> Review Date: 2019-02-07
> IETF LC End Date: 2019-02-15
> IESG Telechat date: unknown
> 
> Summary: Almost Ready
> 
> 
> Major Concerns:
> 
> Section 4.1 says "... preferably over TLS ...", but it does not tell
> what the consequences are if TLS is not used.  Since this is the
> security architecture, I would expect these consequences to be
> described.

There is s9.1 that addresses this :)

> Section 4.2: Please add a sentence or two that defines Interactive
> Connectivity Establishment (ICE) data and non-ICE data.

Since s4.2 of this document points to s4.2 of security-arch and there’s an 
entire subsection on ICE I am hoping that the references are enough.

> Section 6.5 includes a contradiction.  One place it says, " MUST NOT
> negotiate cipher suites with NULL encryption", and another place it
> says, "if Null ciphers are used ...".  Please make these consistent.

I deleted the display requirements section because I think the prohibiting on 
negotiating NULL drives the display requirement.

> Section 6.5 requires implementation of certificate fingerprints or a
> Short Authentication String (SAS).  Please add a sentence to tell how
> they are used to provide out-of-band verification.  Without such a
> sentence, it is easy to imagine an implementation with a UI that is
> too awkward to actually get the information on the screen while the
> call is in progress.

Would something like this work:

  These are compared by the peers to authenticate one another.

> Section 10: since this is a standards track document, the IESG should
> be responsible for this new codepoint, not the document author.

changed

> Minor Concerns:
> 
> Section 3.1 uses https://www.evil.org/ as an example.  However, this is
> a registered domain.  It would be better to follow the IESG statement on
> examples: https://www6.ietf.org/iesg/statement/examples.html.

I was really hoping a Dr. Evil included their info the DNS.  It wasn’t there.
I changed to http://example.org

> Section 6.2 uses customerserv...@ford.com  as an example.  Of course,
> ford.com is a registered domain. It would be better to follow the IESG
> statement on examples (the URL is above).

Changed it to customerserv...@example.org

> Section 7 uses Poker Galaxy  as an example.  Of course, this is a real
> web site. It would be better to follow the IESG statement on examples
> (the URL is above).  It seems best to use the same names here as are
> used in Section 7.2.

I changed to “a poker site” to match that phrase, which is used in the 1st para 
of that section.

> Nits:
> 
> Section 1 includes: "... SDP-based like SIP."  Please add a reference
> for SDP.

I have to admit that I’d probably be confused if there was a reference to SDP 
after "SDP-based like SIP [RFC4566]” and it reads a little awkward if we do 
"SDP-based [RFC4566[ like SIP.  RFC 4566 is referred to in s3 when the SDP 
attribute is defined and there’s a reference tor SIP, which also refers to SDP, 
 earlier.  I tend think the reader won’t be that confused ;)

> Section 4.1: s/ permissions till later/ permissions until later/

Fixed

> Section 4.4: please add a reference for STUN.

The reference is a sentence later.

> Section 6.2: s/(though see Section 6.3/(See Section 6.3/

fixed

> Section 6.4: please do not enclose the note is '[' and ']'.  Avoid
> confusion with reference syntax.  One solution is to put the note at
> the end of the paragraph.

fixed (I just remove the [ ]).

> Section 6.4: s/non-turn candidates/non-TURN candidates/

fixed

> Section 6.5: the phrase "Implementations MUST implement" seems awkward.
> Perhaps "Implementations MUST support".  This appears several places.

fixed

> Section 6.5 ought to begin with "All data channels MUST be secured via
> DTLS."  This appears half way through the section, but the material that
> comes before is really in support of this sentence.

Eh - when I read that I thought - generic requirements and then ones for media 
and the data channels.

> Section 8.1 discusses "@", but the discussion of "user"
> (note the quotes) and the discussion of domain (note the absense of
> quotes) are using different conventions.  Please use quotes in both
> places or neither place.

I think I fixed this.

> There are places in this document where "settings" is confusing.  It is
> unclear whether the word is referring to configuration settings or it
> is 

Re: [Gen-art] [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04

[Sean Turner]

> On Feb 27, 2018, at 11:21, Russ Housley  wrote:
> 
> 
>>> Minor issues:
>>> 
>>> I think convention is to list the documents being updated in the Abstract, 
>>> but
>>> cannot find any formal guidance.
>> 
>> You’re right that is the convention, but it’s not required.  
>> draft-flanagan-7322bis is attempting to make including updates in the 
>> abstract a must, but it’s not been through any kind of LC yet.  There is a 
>> sentence there saying that a lot of RFCs are updated and to see the updates 
>> header so I think under the 7322 to balance concise and to not include 
>> references I’m thinking this is okay.
>> 
> 
> If another update top the document is needed, then it does not seem hard to 
> comply with the coming convention.

Just an FYI I plan to object to the coming convention :)

> ==
>>> 
>>> If an item is marked as not recommended it does not necessarily mean
>>> SB> Do you mean "marked as not recommended" or "not marked as recommended”.
>> 
>> There are two states for the Recommended column: YES and NO.  I can go 
>> either way on whether
>> marked as not recommended = NO
>> not marked as recommended = NO
>> 
>> WG - thoughts?
> 
> I think the second wording is more clear.

fixed

>>> ===
>>> SB>  I am worried about the semantics of Recommended = no.
>>> SB> Presumably there are three states: recommended, not recommended,
>>> SB> and silent/don't know/don't care/not yet. Which of these
>>> SB> states does Recommended = no represent?
>> 
>> There are two states and a draft that specifies a value in a registry that 
>> has a Recommended column needs to state which it is.  I’m not too concerned 
>> because we can change the column value later if it turns out a NO should 
>> have been a YES.
> 
> It would be more clear is Section 6 said that each parameter will have either 
> "yes" or "no" in the new recommended column.

Can do:

OLD:

  The instructions in this document add a Recommended column to many of the
  TLS registries

NEW:

  The instructions in this document add a Recommended column with a value
  of YES or NO to many of the (D)TLS registries

PR: https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04

[Sean Turner]

> On Feb 27, 2018, at 09:55, Sean Turner <s...@sn3rd.com> wrote:
> 
> 
> 
>> On Feb 27, 2018, at 09:51, Benjamin Kaduk <bka...@akamai.com> wrote:
>> 
>> On 02/27/2018 08:11 AM, Sean Turner wrote:
>>> There are two states for the Recommended column: YES and NO.  I can go 
>>> either way on whether
>>> marked as not recommended = NO
>>> not marked as recommended = NO
>>> 
>>> WG - thoughts?
>> 
>> I thought we had always been clear that it was "not marked as
>> recommended", i.e., "we make no comment about its status".
> 
> In s6 it is "marked as not recommended”.  This is easily changed.

https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04

[Sean Turner]

> On Feb 27, 2018, at 09:55, Salz, Rich  wrote:
> 
> 
>>   I thought we had always been clear that it was "not marked as
>>  recommended", i.e., "we make no comment about its status".
> 
> That was my understanding to.  The choices are "recommended" or "no comment”

Yes, but we put “NO” as a column value.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [TLS] Genart last call review of draft-ietf-tls-iana-registry-updates-04

[Sean Turner]

> On Feb 27, 2018, at 09:51, Benjamin Kaduk <bka...@akamai.com> wrote:
> 
> On 02/27/2018 08:11 AM, Sean Turner wrote:
>> There are two states for the Recommended column: YES and NO.  I can go 
>> either way on whether
>> marked as not recommended = NO
>> not marked as recommended = NO
>> 
>> WG - thoughts?
> 
> I thought we had always been clear that it was "not marked as
> recommended", i.e., "we make no comment about its status".

In s6 it is "marked as not recommended”.  This is easily changed.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-tls-iana-registry-updates-04

[Sean Turner]

> On Feb 20, 2018, at 14:50, Stewart Bryant  wrote:
> 
> Reviewer: Stewart Bryant
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-tls-iana-registry-updates-05
> Reviewer: Stewart Bryant
> Review Date: 2018-02-20
> IETF LC End Date: 2018-03-01
> IESG Telechat date: 2018-03-08
> 
> Summary: A well written document that is difficult to check and easy to make a
> mistake with. There are a tiny number of editorial matters. The matter of the
> semantics of Recommended = no may need to further thought and clarification.
> 
> Major issues: None
> 
> Minor issues:
> 
> I think convention is to list the documents being updated in the Abstract, but
> cannot find any formal guidance.

You’re right that is the convention, but it’s not required.  
draft-flanagan-7322bis is attempting to make including updates in the abstract 
a must, but it’s not been through any kind of LC yet.  There is a sentence 
there saying that a lot of RFCs are updated and to see the updates header so I 
think under the 7322 to balance concise and to not include references I’m 
thinking this is okay.

> ==
> 
>  If an item is marked as not recommended it does not necessarily mean
> SB> Do you mean "marked as not recommended" or "not marked as recommended”.

There are two states for the Recommended column: YES and NO.  I can go either 
way on whether
marked as not recommended = NO
not marked as recommended = NO

WG - thoughts?

> ===
> SB>  I am worried about the semantics of Recommended = no.
> SB> Presumably there are three states: recommended, not recommended,
> SB> and silent/don't know/don't care/not yet. Which of these
> SB> states does Recommended = no represent?

There are two states and a draft that specifies a value in a registry that has 
a Recommended column needs to state which it is.  I’m not too concerned because 
we can change the column value later if it turns out a NO should have been a 
YES.

> Nits/editorial comments:
> Abstract
> 
>   This document describes a number of changes to (D)TLS IANA registries
> 
> SB> TLS is not a well known abbreviation and so needs expanding

Right well I should fix that ;)

I made the following tweak:

OLD:

  (D)TLS

NEW

  Transport Layer Security and Datagram Transport Layer Security ((D)TLS)

PR:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/63

> 
> 
>   This document instructs IANA to make changes to a number of (D)TLS-
> 
> SB> TLS needs expanding

See above.

spt

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-rtcweb-overview-18

[Sean Turner]

> On Mar 16, 2017, at 20:43, Meral Shirazipour  
> wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the 
> IETF Chair.  Please treat these comments just like any other last call 
> comments.
> For more information, please see the FAQ at 
> .
>  
>  
> Document: draft-ietf-rtcweb-overview-18
> Reviewer: Meral Shirazipour
> Review Date: 2017-03-16
> IETF LC End Date:   2017-03-20
> IESG Telechat date: 2017-04-13
>  
>  
> Summary:
> This draft is ready to be published as Standards Track RFC but I have 
> comments.

Harald and I (the shepherd) thank you for your review.

> Major issues:
> Minor issues:
> Nits/editorial comments:
> -[Page 3] "an other hardware has">"and other hardware have”
fixed
> -[Page 4], the word "subprotocol" was not clear to me. Would it be possible 
> to add in parenthesis a few example for protocol and subprotocol?
Mostly talking about Websockets-related sub-protocols. XMPP and SIP are 
examples noted later. 
> -[Page 4], "an WebRTC"--->""a WebRTC”
fixed
> -[Page 7], "Interactive Connectivty"--->"Interactive Connectivity”
fixed
> -General: please spell out acronyms at first use
I caught a couple, but I’m sure I missed some.  I figured I let some go like 
“SDP Agent” in the terminology section because people can just as easily go 
there.  There’s also a lot in the RFC acronym list that don’t necessarily need 
to be expanded.
> -General: the writing (or perhaps lack of punctuation) in this draft made it 
> hard to read. Please consider reviewing it especially if the draft is 
> intended as Standards Track.
I’m going to leave this one to the RFC editor.  Every time I try to make 
something sound better they just do a better job.

PR can be found here:
https://github.com/rtcweb-wg/rtcweb-overview/pull/13/

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-sidr-bgpsec-pki-profiles-18

[Sean Turner]

Dale,

Thanks for the review.  Responses inline.  And, assuming Steve agrees I’ll 
submit a version that incorporates these and other changes before the IESG does 
its eval.

spt

> On Dec 13, 2016, at 16:45, Dale Worley  wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft.  The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by
> the IESG for the IETF Chair.  Please treat these comments just like
> any other last call comments.
> 
> Document: draft-ietf-sidr-bgpsec-pki-profiles-18
> Reviewer: Dale R. Worley
> Review Date: 12 Dec 2016
> IETF LC End Date: 19 Dec 2016
> IESG Telechat date: unknown
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits that
> should be fixed before publication.
> 
> Some of these items appear to be technical, but I suspect that the
> intended meanings are clear to people well-versed in PKI and are known
> to work.  However, they are unclear to a naive reader.
> 
> 2.  Describing Resources in Certificates
> 
>   The RIR, in turn, issues a CA certificate to an Internet Service
>   Providers (ISP). 
> 
> s/Providers/Provider/
>   
>   The CA also
>   generate.  The CA also generates Certificate Revocation Lists
> (CRLs).
> 
> The first "The CA also generate." is extraneous.

Alvaro caught these too in his AD review so I’ve got them in the editor's copy 
I’m working with.

> 3.1  BGPsec Router Certificate Fields
> 
>   A BGPsec Router Certificate is a valid X.509 public key
> certificate,
>   consistent with the PKIX profile [RFC5280], containing the fields
>   listed in this section.  This profile is also based on [RFC6487]
> and
>   only the differences between this profile and the profile in
>   [RFC6487] are specified below.
> 
> I suspect this paragraph is going to cause implementers some trouble.
> What, exactly, are the constraints on the BGPsec Router Certificate?
> 
> It looks like the certificate must conform to:
> 
> - X.509
> 
> - RFC 5280
> 
> - RFC 6487 as modified by "below"
> 
> and I see that RFC 6487 requires that certificates conform to RFC
> 5280.  So it seems that the first two items are directly required by
> this document and transitively required by RFC 6487.
> 
> I suggest changing the first two items to be required only by
> transitivity, only mentioning X.509 and RFC 5280 as explanatory:
> 
>   A BGPsec Router Certificate is consistent with the profile in
>   [RFC6487] as modified by the specifications in this section.  As
>   such, it must be a valid X.509 public key certificate and
>   consistent with the PKIX profile [RFC5280].
> 
> Also, "below" is vague.  I suspect you mean "The differences between
> this profile and the profile in [RFC6487] are specified in this
> section.”

It’s basically profile of a profile of a profile plus some stuff.  I’m happy to 
adopt your suggestion modulo s/must be/is.

> 3.1.1.1.  Subject 
> 
>   However, each
>   certificate issued by an individual CA MUST contain a Subject name
>   that is unique within that context.
> 
> What is "that context"?  Do you mean:
> 
>   However, the certificates issued by an individual CA MUST contain
>   unique Subject names.
> 
> However that has difficulties when it comes time for the CA to issue
> new certificates with later validity times.
> 
> Why there is a constraint based on "issued by an individual CA" is not
> clear, given that there is no constraint regarding which CA issues
> certificates to which routers.  Merely aggregating the work of
> multiple CAs into one CA could require changing the subject names in
> the next revision of issued certificates, whereas splitting the
> work of one CA into multiple CAs would loosen this requirement.  In
> addition, the definition of "an individual CA" is not clear.  Is there
> really an operational requirement for this uniqueness constraint?
> 
> More to the point, is the combination of common name (i.e. AS number)
> and serial number (router ID) required to be globally unique or not?
> That seems to be the only question that can be operationally
> significant.
> 
> I suspect that someone well-versed in PKI knows these answers, but for
> the naive, what is required and why seems confusing.

I think this is just a case of a missing “CA” in front of the word “context” so 
tweaking it to: “…. that is unique to that CA context”.  The certs only need to 
be unique on a per CA basis the subject name does not need to be unique across 
the whole of the RPKI.  The combination of issuer+subject+serial # plus all the 
parent certs provides the uniqueness.

> 3.2.  BGPsec Router Certificate Request Profile
> 
>o The SubjectPublicKeyInfo and PublicKey fields are specified in
>  [ID.sidr-bgpsec-algs].
> 
> There is no "PublicKey field" discussed in ID.sidr-bgpsec-algs.  Is
> "subjectPublicKey" intended?  If so, "subjectPublicKey" seems to be a
> sub-field of SubjectPublicKeyInfo (per 

Re: [Gen-art] Gen-ART LC review of draft-ietf-tls-chacha20-poly1305-04 - resend

[Sean Turner]

> On Apr 07, 2016, at 09:40, Roni Even  wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
> please see the FAQ at 
> .
> 
> Please resolve these comments along with any other Last Call comments you may 
> receive.
> 
> Document:  draft-ietf-tls-chacha20-poly1305-04
> 
> Reviewer: Roni Even
> 
> Review Date:2016–3-28
> 
> IETF LC End Date: 2016–4-9
> 
> IESG Telechat date: 
> 
>  
> Summary: This draft is almost ready for publication as a standard track  RFC.
>  
>  
>  
> Major issues:
> I am wondering why this is a standard track document and not informational 
> since the registration requirements are specification required.  (RFC5246)

I’m not sure I agree that Specification Required implies informational track.  
Specification Required permits registrations from informational/experimental 
drafts, but it certainly doesn’t require informational/experimental.

Also note, the registry rules are:

0-191   Standards ActionRefers to value of first byte
192-254 Specification Required  Refers to value of first byte
255 Reserved for Private UseRefers to value of first byte

> I am also wondering why this document updates RFC5246 and RFC6347.  Reading 
> the document it looked to me that the registration document is used also to 
> endorse this cypher suite by the IETF and if this is the case my view is that 
> there should be two documents, one Informational for registration and the 
> will be standard track and update RFC5246 and RFC6347
> For Example the following text from section 1 “Therefore, a new stream cipher 
> to replace RC4 and address all the  previous issues is needed. “  provides 
> what may look as a normative recommendation.

As far as the updates header:

The RC4 stream cipher which was in TLS1.0-1.2 is now prohibited [RFC7465] (note 
not deprecated it’s prohibited) and ChaCha20-Poly1305-based ciphers are the 
replacement.  So, we do in fact want folks who were using RC4 to switch to 
ChaCha20-Poly1305, hence the updates header.

As far as splitting the registrations/updates:

What you’re suggesting is certainly one way to do it, but the way we’ve been 
doing it for years in the security area (e.g., TLS, IPSec, S/MIME, PKIX) is as 
follows (there have, of course, been exceptions):

- (if needed) Informational RFC for algorithm

- Standards track RFC for how to use algorithm with security protocol. This is 
how AES, Camellia, etc. were documented for TLS.

Also in play here is the need to avoid a bunch of DOWNREFs because two of the 
ChaCha20-Poly1305 suites are SHOULDs in the draft TLS1.3.  DOWNREFs aren’t 
anything to be scared of, but where we can avoid them I think we should.

I guess I’d rather not devise new process and just keep on doing what we’ve 
been doing.

spt

PS we are currently in the process of discussing a change to make the entire 
range (minus the reserved) specification required, but that won’t complete for 
a while and the implementers want this now (technically yesterday). 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art LC review of draft-ietf-tls-encrypt-then-mac-02

[Sean Turner]

On Jun 15, 2014, at 09:23, Elwyn Davies elw...@dial.pipex.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments
 you may receive.
 
 Document: draft-ietf-tls-encrypt-then-mac-02.txt
 Reviewer: Elwyn Davies
 Review Date: 15 June 2014
 IETF LC End Date: 20 June 2014
 IESG Telechat date: (if known) -
 
 Summary: Almost ready.
 
 Major issues:
 
 Minor issues:
 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? 

My feeling is that it doesn’t update any of the drafts.  It documents a new 
optional extensions that implementations are free to implement so it need not 
update the base specs.  WRT including all the extensions in one draft, RFC 6066 
defines many extensions but not all:

http://datatracker.ietf.org/doc/rfc6520/
http://datatracker.ietf.org/doc/rfc6961/

this is just another one.

 s3.1: [I am not a TLS expert so I may not have got this right...] If the
 rehandshake proposes to use a cipher that doesn't need encrypt-then-mac
 as per GenericStreamCiphers, or GenericAEADCiphers as mentioned in s3,
 then presumably this is allowed whether encrypt-then-mac had or had not
 been negotiated previously on the session.  It should be clarified
 whether this is allowed and, if it isn't, what the response should be.
 
 If it is allowed and the session switches to a GenericStreamCipher, or a
 GenericAEADCipher, then it appears that if the original session was
 using encrypt-then-mac, a downgrade to a cipher that does need
 encrypt-then-mac but isn't using it could be achieved by using a second
 rehandshake without encrypt-then-mac since the first rehandshake goes to
 a situation that doesn't use encrypt-then-mac after the first
 rehandshake.   The solution seems to be to record whether the session
 ever used encrypt-then-mac rather than whether is is currently using it,
 and then apply the rules in s3.1 based on the record.  

I’ll leave this one to Peter.

 Nits/editorial comments:
 s3: (very nitty nit)  I think the MAC calculation piece would be clearer
 with what it updates noted before the update. Thus:
 
 OLD
 In TLS [2] notation the MAC calculation is:
 
   MAC(MAC_write_key, seq_num +
   TLSCipherText.type +
   TLSCipherText.version +
   TLSCipherText.length +
   ENC(content + padding + padding_length));
 
   for TLS 1.0 without the explicit IV and:
 
   MAC(MAC_write_key, seq_num +
   TLSCipherText.type +
   TLSCipherText.version +
   TLSCipherText.length +
   IV +
   ENC(content + padding + padding_length));
 
   for TLS 1.1 and greater with explicit IV (for DTLS the sequence
   number is replaced by the combined epoch and sequence number as per
   DTLS [4]).
 
 NEW:
 In TLS [2] notation the MAC calculation is:
  o For TLS 1.0 without the explicit IV
 
   MAC(MAC_write_key, seq_num +
   TLSCipherText.type +
   TLSCipherText.version +
   TLSCipherText.length +
   ENC(content + padding + padding_length));
 
  o For TLS 1.1 and greater with explicit IV
 
   MAC(MAC_write_key, seq_num +
   TLSCipherText.type +
   TLSCipherText.version +
   TLSCipherText.length +
   IV +
   ENC(content + padding + padding_length));
 
  o For DTLS the sequence number in the TLS 1.1 description is replaced 
by the combined epoch and sequence number as per DTLS [4]).
 
 s3, next to last para:
 For DTLS, the record MUST be discarded and a fatal bad_record_mac MAY
   be generated [2].
 Shouldn't the reference here be [4] for DTLS? 

Nope - the bad_record_mac is defined in [2].  DTLS and TLS share some things: 
e.g., alert protocol values.

 s3.1 (last para)/s7.1: Shouldn't the TLS_ext reference [3] be to the updated 
 RFC 6066?

At first I thought the answer was no, but since three people have commented on 
it I guess should be updated.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-moriarty-pkcs12v1-1-03.txt

[Sean Turner]

My other thought here is that we know complexity is bad ;)  The specific 
concern about that command is specific to openssl ad though widely deployed 
doesn’t really belong in this draft.

spt

On Jan 21, 2014, at 16:38, Moriarty, Kathleen kathleen.moria...@emc.com wrote:

 Hi Jari,
 
 Since this document is meant to transfer change control to the IETF, RSA 
 would prefer to leave the document in-tact to match their published version 
 as much as possible.  There is IETF interest in starting a draft as soon as 
 this is published to correct the well-known issues.  We would prefer to take 
 that approach and I am working to make sure we have at least one resource to 
 edit the new document who has the background to make the changes and there 
 may be others.
 
 Thank you,
 Kathleen
 
 -Original Message-
 From: Jari Arkko [mailto:jari.ar...@piuha.net] 
 Sent: Tuesday, January 21, 2014 10:31 AM
 To: Moriarty, Kathleen; Sean P. Turner
 Cc: francis.dup...@fdupont.fr; gen-art@ietf.org; 
 draft-moriarty-pkcs12v1-1@tools.ietf.org
 Subject: Re: [Gen-art] review of draft-moriarty-pkcs12v1-1-03.txt
 
 Thanks for your review, Francis, and for your edits, Kathleen.
 
 Do you Kathleen or Sean think that Francis' comment on strengthening the 
 security considerations would be something that you should address?
 
 jari
 
 On Jan 13, 2014, at 6:02 PM, Moriarty, Kathleen kathleen.moria...@emc.com 
 wrote:
 
 Hi Francis,
 
 I went to update your comments in my draft version and in thinking about it 
 more, I agree with the current text on the public/private order.  As I read 
 it, the referenced keys are discussed for the keys that validate and I 
 assume you read it as the creation of a signature or to encrypt.  I'm going 
 to leave that as-is.
 
 Thanks,
 Kathleen
 
 -Original Message-
 From: Moriarty, Kathleen
 Sent: Monday, January 13, 2014 9:42 AM
 To: 'francis.dup...@fdupont.fr'; gen-art@ietf.org
 Cc: draft-moriarty-pkcs12v1-1@tools.ietf.org
 Subject: RE: review of draft-moriarty-pkcs12v1-1-03.txt
 
 Thank you for the review, Francis.
 
 Once this version is published, change control and copyright is transferred 
 to the IETF.  The next version of this document will work to improve known 
 issues.
 
 I will make the change from public/private to private/public as noted, that 
 makes sense.  I would imagine it was only written that way as the key pairs 
 are typically referred to in that order as opposed to the original author 
 thinking through the sentence as you had done.
 
 I have a few other edits to include and will have this ready before the end 
 of the week.
 
 Thank you,
 Kathleen
 
 -Original Message-
 From: francis.dup...@fdupont.fr [mailto:francis.dup...@fdupont.fr]
 Sent: Monday, January 13, 2014 8:56 AM
 To: gen-art@ietf.org
 Cc: draft-moriarty-pkcs12v1-1@tools.ietf.org
 Subject: review of draft-moriarty-pkcs12v1-1-03.txt
 
 I am the assigned Gen-ART reviewer for this draft. For background on 
 Gen-ART, please see the FAQ at
 
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
 
 Please resolve these comments along with any other Last Call comments you 
 may receive.
 
 Document: draft-moriarty-pkcs12v1-1-03.txt
 Reviewer: Francis Dupont
 Review Date: 20130104
 IETF LC End Date: 20130110
 IESG Telechat date: unknown
 
 Summary: Ready
 
 Major issues: None
 
 Minor issues: (not really technical)
 PKCS#12 was subject to concerns from teh cryptography community, in 
 particular from Peter Gutmann, based on:
 - its (too) high complexity (BTW IMHO it is a legitimate concern:
 complexity is not wellcome for a security device)
 - (related to the previous item) its possible misuse with private  key, 
 summarized by this famous warning in OpenSSL FAQ:
 Occasionally someone suggests using a command such as:
 
 openssl pkcs12 -export -out cacert.p12 -in cacert.pem -inkey cakey.pem
 
 DO NOT DO THIS! This command will give away your CAs private key and reduces 
 its security to zero: allowing anyone to forge certificates in whatever name 
 they choose.
 
 Unfortunately I can't see how we can address these concerns in the document. 
 Perhaps with a stronger security considerations section?
 
 Nits/editorial comments:
 - TOC page 3 and F page 29: Acknowledgements - Acknowledgments
 
 - 1 page 4 in:
 The most secure of the privacy
  and integrity modes require the source and destination platforms to
  have trusted public/private key pairs usable for digital signatures
  and encryption, respectively.
 
 respectively suggests the same order but the private key is used to  
 sign and the public key to encrypt. I propose to swap keys, i.e.,  to 
 use private/public key pairs.
 
 - 5.1 5 B page 16: i.e. - i.e.,
 
 - a full example should have been wellcome but IMHO it is far too late  
 (and there are a lot of tools able to produce examples if needed :-).
 
 Regards
 
 francis.dup...@fdupont.fr
 
 ___
 Gen-art mailing list
 

Re: [Gen-art] [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

[Sean Turner]

Piyush,

(David's on the to: line because the text in question showed up as a 
result of the gen-art review and it's now in -16)


I've been following this thread trying to figure out what if anything 
needs to be changed to address your concerns in -17.  (Note the thread 
forked later, but I'm addressing the times issue in another thread.)


The sentence in questions was added to address the gen-art review is the 
following (it's in a note paragraph and there's actually more to it):


  The revoked status is still optional in this context in
  order to maintain backwards compatibility with deployments
  of RFC 2560.

1) The first bit I'd like to discuss is this part of your concern:

  And it gives the impression that best course of action
  for 2560bis responders is to start issuing revoked for
  not-issued, which is far from the originally stated
  goal to provide a way for CAs to be able to return
  revoked for such serial numbers.

and:

  I believe that Stefan is trying to convey that requiring
  servers to return revoked in this context will make them
  non-compliant with 2560 and 5019 as opposed to breaking
  interoperability with legacy clients.

I honestly don't see how you get to your impression, because the 2119 
language about when a responder might used revoked for not-issued is:


 This state MAY also be returned if the associated
 CA has no record of ever having issued a certificate with the
 certificate serial number in the request, using any current or
 previous issuing key (referred to as a non-issued certificate in
 this document).

MAY being the operable word here.  That's clear to implementers because 
if you read 2119 for MAY it says:  This word, or the adjective 
OPTIONAL, mean that an item is truly optional.  One vendor may choose 
to include the item because a particular marketplace requires it or 
because the vendor feels that it enhances the product while another 
vendor may omit the same item. ...


For me this seems clear because the 2119 language trumps any note.

Even Stefan's response to David a couple of days earlier than when you 
posted this concerns includes:


  In theory we could possibly say that responding revoked
  is optional, but if you choose between revoked and unknown
  then you SHOULD favour revoked over unknown. But such nested
  requirements just feels bad and impossible to test compliance
  against. I'd much rather just leave it optional.

I'm not sure what else could be added to alliveate your concern on this 
point.  Maybe this one got over taken by events?


2) The second bit of your concern is that this is not an accurate 
characterization of the WG's rationale for the choices made.  This 
concern is easier to evaluate and I agree that it is important to 
capture the actual rationale.  I think you've suggested that the following:


  maintain backwards compatibility with deployments of RFC 2560

be replaced with:

  maintain compliance with RFC 2560 and RFC 5019

Using the word compliance might set of an entirely new debate. 
Servers/clients can claim compliance if they want to but I'm not sure 
that the primary goal was for a document to claim compliance with 
another set of RFCs.  These drafts for interoperability and that would 
lead me to compatibility and not conformance.


spt

On 4/3/13 1:38 PM, Piyush Jain wrote:

No, it does not make any sense at all.  An error code is unsigned and can

be

easily inserted into the communication by an attacker.


[Piyush] Funny that you make this argument. How does returning a signed
revoked address this? Attacker can still replace signed revoked with an
UNSIGNED TRY_LATER.


These kinds of argument are based on two very flawed premises:

  (1) the premise that there exist only two possible states for a CA:
   (a) safe and pristine
   (b) full and thorough compromise of each and everything

[Piyush] NIST has addressed RA compromise and CA key compromise separately
so this is not true.
And you have not listed what other breaches you are trying to address
offering revoked for non-issued as the silver bullet for all those unknown
security breaches.
  You tendency to allude to vague problems to justify a particular solution,
couple with a reluctance to engage in a discussion regarding the security
implications continues to amuse me. List the other states and have a
discussion around how this solution solves those problems.

  (2) that a huge PKI (100k+ entities) can be nuked and
  re-personalized after a CA compromise at close to zero cost and
  within the blink of an eye


and both premises exhibit a throrough cluelessness about security, risk

management and the real world.


Let's get this right.
Only possible benefit of revoked for non-issued exists when there are CA
SIGNED certificates floating in the wild and CA has no clue that it has
issued it and therefore cannot revoke it.

Now, to say that clients are secure and CA can continue to operate if it
issues revoked OCSP response for such 

Re: [Gen-art] [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

[Sean Turner]

On 4/8/13 5:59 PM, Piyush Jain wrote:

Sean,

Thanks for your comments.
There are two points that I would like to cover separately. The first point
is a response to your comments below. The second point is a broader
objection to revoked for issued.

1) The text says - The revoked status is still optional in this context in
order to maintain backwards compatibility with deployments of RFC 2560.
This implies that making revoked status REQUIRED will break
interoperability between newer and older implementations. This is INCORRECT.


Using the word compliance might set of an entirely new debate.
Servers/clients can claim compliance if they want to but I'm not sure that

the

primary goal was for a document to claim compliance with another set of
RFCs.
These drafts for interoperability and that would lead me to
compatibility and not conformance.

That is fair. I was just pointing at the intent of the author. If you make
revoked status REQUIRED it does not break compatibility of newer
implementations with older implementations, however it does break
conformance of older implementations with RFC 5019 and 2560.

2) Returning revoked for non-issued adds confusion without addressing any
real problem. Allowing CAs to return revoked for non-issued is a goal that
is vague and meaningless, given that CAs indicate issuance by signing the
certificate in question with their private key. If you question this basic
premise of x.509 that issuance is determined by signature, you should
question the signature on signed response as well. Who is to say that the
responder certificate that was used to sign a good response was issued by
the CA?

Henry nicely articulated the whole issue with this draft in his post
(attached). I second his view on not moving this draft forward.


I went back and looked at the WG poll about this issue that you and lot 
of other people participated in 
(https://www.ietf.org/mail-archive/web/pkix/current/msg31906.html).  The 
WG's rough consensus was to allow revoked to be used for non-issued 
certificates with the caveat thrown in by Paul Hoffman that the meaning 
of revoked be clear about what it now means.  I've not seen anything 
that would make me want to throw this draft back to the WG to revisit 
that consensus.


spt


-Piyush

-Original Message-
From: Sean Turner [mailto:turn...@ieca.com]
Sent: Monday, April 08, 2013 1:23 PM
To: Piyush Jain
Cc: ambar...@gmail.com; slava.galpe...@gmail.com;
cad...@eecs.uottawa.ca; 'Stefan Santesson'; 'Black, David'; sts@aaa-
sec.com; p...@ietf.org; gen-art@ietf.org
Subject: Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

Piyush,

(David's on the to: line because the text in question showed up as a

result

of the gen-art review and it's now in -16)

I've been following this thread trying to figure out what if anything

needs to

be changed to address your concerns in -17.  (Note the thread forked

later,

but I'm addressing the times issue in another thread.)

The sentence in questions was added to address the gen-art review is the
following (it's in a note paragraph and there's actually more to it):

The revoked status is still optional in this context in
order to maintain backwards compatibility with deployments
of RFC 2560.

1) The first bit I'd like to discuss is this part of your concern:

And it gives the impression that best course of action
for 2560bis responders is to start issuing revoked for
not-issued, which is far from the originally stated
goal to provide a way for CAs to be able to return
revoked for such serial numbers.

and:

I believe that Stefan is trying to convey that requiring
servers to return revoked in this context will make them
non-compliant with 2560 and 5019 as opposed to breaking
interoperability with legacy clients.

I honestly don't see how you get to your impression, because the 2119
language about when a responder might used revoked for not-issued is:

   This state MAY also be returned if the associated
   CA has no record of ever having issued a certificate with the
   certificate serial number in the request, using any current or
   previous issuing key (referred to as a non-issued certificate in
   this document).

MAY being the operable word here.  That's clear to implementers because if
you read 2119 for MAY it says:  This word, or the adjective OPTIONAL,
mean that an item is truly optional.  One vendor may choose to include the
item because a particular marketplace requires it or because the vendor

feels

that it enhances the product while another vendor may omit the same item.
...

For me this seems clear because the 2119 language trumps any note.

Even Stefan's response to David a couple of days earlier than when you
posted this concerns includes:

In theory we could possibly say that responding revoked
is optional, but if you choose between revoked and unknown
then you SHOULD favour revoked over unknown. But such nested
requirements

Re: [Gen-art] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

[Sean Turner]

On 3/25/13 10:21 PM, Stefan Santesson wrote:

Hi David,



Nits:

idnits 2.12.15 said:

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
 have content which was first submitted before 10 November 2008.  If
you
 have contacted all the original authors and they are all willing to
grant
 the BCP78 rights to the IETF Trust, then this is fine, and you can
ignore
 this comment.  If not, you may need to add the pre-RFC5378
disclaimer.
 (See the Legal Provisions document at
 http://trustee.ietf.org/license-info for more information.)

This looks like it's ok because all the authors of RFC 2560 are also
authors of
this draft, but it should be double-checked.



I defer this one to Sean. I think he has this one under control.


I actually contacted all but one of the authors of RFC 2560.  The ones I 
did get in contact with indicated it was fine to publishing under the 
new rules.  The one I did not contact is deceased.   I decided it would 
be in poor taste to contact the widower on this issue.  Based on 
discussions with people who knew the author very well and the minimal 
changes in the draft, I'm comfortable progressing the document with the 
deceased authors name on it and without the disclaimer.


spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-emu-chbind

[Sean Turner]

Sam,

I'm happy with your suggestions: do a post-telechat update if there are 
no other pre-telechat comments.  If you get other comments, then feel 
free to fire off an update if you have time before the telechat.


spt

On 4/12/12 10:36 AM, Sam Hartman wrote:

Thanks for the review.
There are a number of very useful comments here and I'd like to have an
opportunity to submit a new draft to address them.
I think it would be fine to do that post-telechat  if there are no other
pre-telechat comments.
I'd also be fine to delay and do a pre-telechat update depending on what
Sean wants.
I won't be able to have any time to work on this until the week of April
23.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

[Sean Turner]

On issue 2, Russ has already entered his ballot on the base spec so I'll 
pick this one up.


spt

On 4/10/12 8:25 PM, Mike Jones wrote:

Hi Alexey,

About your issue 1:  The OAuth Core spec, where scope is primarily defined, includes 
the sentence The [scope] strings are defined by the authorization server (see 
http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3.3).  I could add that clarification to 
the Bearer spec as well to make it clear that the scope values are context-dependent, if that would 
address your concern.

About your issue 2:  Investigating the OAuth Errors Registry a bit further (see 
http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-11.4.1) while I'd like to be able to 
register the OAuth Bearer errors in this registry, what I believe to be a defect in the errors 
registry text currently prevents this.  Specifically, the registry enumerates only three 
Error usage location values:  authorization code grant error response, implicit grant 
error response, and token error response.  To be able to use this registry, it would also have to 
have a fourth usage location:  resource access error response.  If you'd like to file 
an issue against the OAuth Core spec to get this additional usage location added to the registry, 
then I'd be glad to use it.  I believe that this would be significantly preferable to adding a 
separate OAuth Bearer errors registry that's exactly like the general-purpose one, only separate 
from it.

Best wishes,
-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Alexey Melnikov
Sent: Tuesday, April 10, 2012 7:03 AM
To: draft-ietf-oauth-v2-bearer@tools.ietf.org
Cc: General Area Review Team; oa...@ietf.org; The IESG
Subject: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please 
see the FAQ athttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments you may 
receive.
Document: draft-ietf-oauth-v2-bearer-18.txt
Reviewer: Alexey Melnikov
Review Date: 10 April 2012
IETF LC End Date: 7 Feb 2012
IESG Telechat date: 12 April 2012

Summary: Nearly ready to be published as Proposed Standard, with a couple of 
things that should be addressed or at least discussed.

Thank you for addressing most of my other issues. However there are a couple 
remaining which I think are important.

Major Issues:

1).
 The scope attribute is a space-delimited list of scope values
 indicating the required scope of the access token for accessing the
 requested resource.  In some cases, the scope value will be used
 when requesting a new access token with sufficient scope of access to
 utilize the protected resource.  The scope attribute MUST NOT
 appear more than once.  The scope value is intended for
 programmatic use and is not meant to be displayed to end users.

I don't think this provide enough information about what this is, how it is to 
be used and which values are allowed. As this is not meant to be displayed to 
end users, then you need to say what values are allowed and which entity can 
allocate them. Is there a registry for these tokens, e.g. an IANA registry?

The editor provided explanation in email, however this was not reflected in any 
version of the draft.

2). Section 3.1.  Error Codes

I've suggested to use an IANA registry for this field. Apparently there is already a 
registry created 
byhttp://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-11.4.
However this document doesn't register values defined in section 3.1 with IANA 
and doesn't point to draft-ietf-oauth-v2-23 for the registry.
I find this to be very confusing.

Minor issues: none

Nits: none

___
OAuth mailing list
oa...@ietf.org
https://www.ietf.org/mailman/listinfo/oauth




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-gellens-mime-bucket-bis-06.txt

[Sean Turner]

Pete,

I thought we'd settled on updated the ones that are already published so 
that implementers will more easily be able to find the parameter.


spt

On 7/28/11 4:44 PM, David Singer wrote:

Gentlemen

thank you for your review and comments; a new version (-07) has been uploaded, 
in response to (minor) comments from Miguel and Robert.  Absent any further 
comment, I think we are good to go.



On Jul 28, 2011, at 13:41 , internet-dra...@ietf.org wrote:


New version (-07) has been submitted for draft-gellens-mime-bucket-bis-07.txt.
http://www.ietf.org/internet-drafts/draft-gellens-mime-bucket-bis-07.txt


Diff from previous version:
http://tools.ietf.org/rfcdiff?url2=draft-gellens-mime-bucket-bis-07

IETF Secretariat.




David Singer
Multimedia and Software Standards, Apple Inc.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-art Lc review of draft-turner-sha0-sha1-seccon-02

[Sean Turner]

On 12/19/10 9:19 AM, Elwyn Davies wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-turner-sha0-sha1-seccon-02.txt
Reviewer: Elwyn Davies
Review Date: 19 December 2010
IETF LC End Date: 3 January 2011
IESG Telechat date: (if known)

Summary: This draft is ready for publication as an Informational RFC.

Editorial/Nits:
s2, para 2:

That is, NIST no longer considers it
appropriate to use SHA-0 for any transitions associated with the use
of cryptography

Is 'transitions' the intended word here?  'Operations' or 'transactions'
seems to be better a choice.


Yet another case of the wrong word being spelled correctly! 
Transactions is definitely better.  I'll fix this.



s3.1: s/absent from published conference paper/absent from the published
conference paper/


Will fix.


Reference [MD2-his] (a draft in progress) is in the references but not
referred to. I don't see any places where it is needed.


Yes this should be removed.

Thanks for the review!

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-turner-md5-seccon-update-07.txt

[Sean Turner]

Francis,

Thanks for your review.  Responses inline.

spt

On 12/10/10 4:45 AM, Francis Dupont wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-turner-md5-seccon-update-07.txt
Reviewer: Francis Dupont
Review Date: 2010-12-06
IETF LC End Date: 2010-12-22
IESG Telechat date: unknown

Summary: Not Ready

Major issues:
  - IANA action is to change a field which doesn't exist


Paul Hoffman suggested that the IANA considerations be changed to 
None.  The hash algorithm textual name registry really ought to be 
updated by the folks who registered it not in this outlier document and 
without some context the values like deprecated (see next issue) 
really doesn't make any sense to stick in a registry.


FYI - the registry was updated in draft-turner-md2-to-historic - and 
there was NO way for you to know that (sorry about the confusion).  I'm 
going to make that IANA consideration None too.



  - there is no consensus if the document should stress not-security uses
   of MD5 are perfectly fine or at the opposite the security label attached
   to MD5 raises practical issues so new uses of MD5 should be strongly
   discouraged or both are out of scope...


Yeah not sure how I'm going to solve this one.  I'll propose some text 
and see what happens.



Minor issues: None

Nits/editorial comments:
  - 2.1 page 2: Psuedo -  Pseudo

  - 2.1 page 3: 1.6 GHz. -  1.6GHz (note: suggestion for removing the space,
   fix for the spurious '.' after an unit)

  - 2.3 page 3: (suggestion) H(IV,M). -  H(IV, M).


Will fix up.


Regards

francis.dup...@fdupont.fr

PS: about 3:

IANA is requested to update the md5 usage entry in the Hash Function
Textual Names registry by replacing COMMON with DEPRECATED.

I understand why the md5 is in lower case (it is the name of the entry)
but I can't find the usage field in the registry at:


As noted about, the registry was updated in another draft 
draft-turner-md2-to-historic.  Making them None ought to solve this 
problem.



http://www.iana.org/assignments/hash-function-text-names/
hash-function-text-names.xhtml

PPS: my proposal for solving the two issues is:
  - give the first one to IANA (IANA has to address it anyway)
   (PS: in fact IANA already raised a question about this point!)
  - use the standard Last Call process for the second

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review for draft-turner-md2-to-historic-05

[Sean Turner]

Kathleen,

Thanks for the review.  I'll fix these up in the next version.

spt

On 11/9/2010 11:42 PM, kathleen.moria...@emc.com wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-turner-md2-to-historic
Reviewer: Kathleen Moriarty
Review Date: November 9, 2010
IETF LC End Date: November 9, 2010
IESG Telechat date: (if known)

Summary:  This draft is basically ready for publication, but has nits that 
should be fixed before publication.
The intent of this draft is to retire the MD2 message digest algorithm and 
providing the justification.  This draft also requests that RFC 1319 be moved 
to historic.

Major issues:

Minor issues:

Nits/editorial comments:
Section 4: Impact of Moving MD2 to Historic
The first bullet in the subsection Regarding PS RFCs: starts with Further, 
however it is the first bullet so I recommend changing it to read:
MD2 support in TLS was dropped in TLS 1.1

Section 7: Recommendation
I recommend breaking the first paragraph into two sentences as follows:

Despite MD2 seeing some deployment on the Internet, this
specification recommends obsoleting MD2.  MD2 is not a
reasonable candidate for further standardization and should be
deprecated in favor of one or more existing hash algorithms (e.g.,
SHA-256 [SHS]).


I apologize for the slow turn around on this review.  Work has been hectic!

Thank you,
Kathleen





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-moriarty-post-inch-rid-11

[Sean Turner]

I did too.

spt

Peter Saint-Andre wrote:

Thanks, I've cleared.

On 7/6/10 11:06 AM, moriarty_kathl...@emc.com wrote:

Hello,

I posted a new version that should resolve all outstanding comments.
Please let me know if any further changes are suggested/required.

https://datatracker.ietf.org/doc/draft-moriarty-post-inch-rid/

Thank you,
Kathleen


Kathleen M. Moriarty, CISSP | Information Security Services|
617-851-5807 | moriarty_kathl...@emc.com  | EMC 




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-hoffman-tls-master-secret-input-01

[Sean Turner]

Dorothy Gellert wrote:

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-hoffman-tls-master-secret-input-01
Reviewer: Dorothy Gellert
Review Date: June-30-2010
IETF LC End Date:  Unknown
IESG Telechat date: July-01-2010

Summary: This document is almost ready for publication as Experimental Standard.

Major issues: None.

Minor issues:  Note the gen art review has listed this as
Experimental.  However the draft indicates the intended status is
Standards track.  Please confirm!


It is headed to experimental.


Nits/editorial comments: Section 2, paragraph 2 duplicates the last
paragraph in the Introduction.
 Is it possible to provide an example of an extension with master secret?
Can you explain why the extension order is important?  Is this a
security issue, if extension order is not maintained?

Best Regards,
Doroth


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-turner-application-pkcs10-media-type-04.txt

[Sean Turner]

Miguel A. Garcia wrote:

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-turner-application-pkcs10-media-type-04.txt
Reviewer: Miguel Garcia miguel.a.gar...@ericsson.com
Review Date: 30-April-2010
IETF LC End Date: 10-May-2010

Summary: The document is almost ready for publication as an 
Informational RFC (see comments below).



Minor issues:
I would like to discuss with the author on sentence that is a bit 
controversial to me.


On Section 2, the sentence reads:

   The
   application/pkcs10 media type MUST be used to transfer a PKCS #10
   certification request.

Allow me turn the sentence into an equivalent, but easier to understand, 
active voice:


A PKCS #10 certification request MUST use the application/pkcs10 media 
type.


And here is my problem. This Internet-Draft is about the 
application/pkcs10 media type, so you cannot write a requirement for a 
PKCS #10 certification request, which is specified in RFC 2986, to 
mandate the usage of the application/pcks10 media type. In other words, 
I believe the sentence is technically correct, but this is not the 
document where it should be written.


So, did the author write this sentence intentionally or has further 
background for its existence?


That sentence was taken from RFC 2311 (i.e., SMIMEv2) section 3.7.  I 
suspect (it was before my time) that it was there to specify how to 
request a certificate from a CA.  This was before PKIX standardized 
their different options.


I see your point about it belonging in RFC 2986, but this document 
updates RFC 2986 so it will be part of that document.  I will 
incorporate your suggested rewording (active is better than passive). 
Does this address your concern?



Nits/editorial comments:

- In Section 3 (IANA), please identify the registry where IANA has to 
operate, which I believe is the Application Media Types registry.


You are correct.  I will add this.

- Question. In Section 3.1 (registration of the application/pkcs10 media 
type), there is a reference in Published specifications to RFC 2986. 
If I were reading the IANA registry and open RFC 2986, I wouldn't find 
any reference to this media type. Therefore, I conclude that the 
Published Specifications should refer only to this Internet-Draft and 
not to RFC 2986.


You are correct.  I was pointing to RFC 2986 for the contents of the 
that document, but I don't need to do that.



- Expand DER at first usage (second paragraph in Section 2.1).


Fixed.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-turner-asymmetrickeyformat-05

[Sean Turner]

Roni,

Thanks for your review.  Comments inline.

spt

Roni Even wrote:

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 version of the draft.

Document: draft-turner-asymmetrickeyformat-05

Reviewer: Roni Even

Review Date: 2010-4-18

IESG Telechat date: 2010-4-22

Summary: This draft is ready for publication as a Proposed Standard. I have
some nits

Nits/editorial comments:

1.  In section 7 what you are registering is a media subtype and not a
media type. The media type is application. So defines a new media type
should be defines a new media subtype and Registration of media type
should be Registration of media subtype.


I'll add this in.


2.  The document defines new object identifiers like
id-ct-KP-aKeyPackage and AsymmetricKeyPackageModuleV1.  Where is the list of
these identifiers kept and how do you update this list in order to guarantee
the uniqueness of these identifiers.


I got the OIDs for the content types and asn.1 module out of two arcs. 
Both OIDs are unique.  Technically, we'd never update an OID.  Once it's 
registered it's registered.  If we need a new OID, then we don't 
necessarily have to go back to the same arc - but I'm sure we could. 
The module OID I got from the SMIME Arc, which is administered by Russ 
Housley and it's been delegated from IANA to SMIME.  The other I got out 
of a DoD arc.   I should add the following the IANA considerations 
sections to make this clear:


This document makes use of object identifiers to identify a CMS content 
and the ASN.1 module found in Appendix A.  The CMS content type OID is 
registered in a DoD arc.  The ASN.1 module OID is registered in an arc 
delegated by IANA to the SMIME Working Group.  No further action by IANA 
is necessary for this document or any anticipated updates.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-turner-asymmetrickeyformat-05

[Sean Turner]

Roni Even wrote:

Hi,
I will provide an example
This draft defines

   AsymmetricKeyPackageModuleV1 
 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
   smime(16) modules(0) id-mod-asymmetricKeyPkgV1(50) } 


RFC 5652 defines

CryptographicMessageSyntax2004
 { iso(1) member-body(2) us(840) rsadsi(113549)
   pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24) }

In this case the id-mod-asymmetricKeyPkgV1(50) is not the same as
cms-2004(24) so they are different but how do you know that 50 is not used
by other draft.

Look at Alfred H־nes email. I think that updating the specific registries is
important. I know that they are not maintained by IANA but hopefully someone
is maintain them and need to be notified of these two OIDs allocations.


Ah, I got both OIDs by asking for them.  I only put them in the document 
after I had them registered to ensure we wouldn't have collisions.  The 
earlier versions of the ID had tbd as place holders until I officially 
got them registered.


spt


Thanks
Roni Even


-Original Message-
From: Sean Turner [mailto:turn...@ieca.com]
Sent: Sunday, April 18, 2010 8:37 PM
To: Roni Even
Cc: 'General Area Review Team'; i...@ietf.org; draft-turner-
asymmetrickeyformat@tools.ietf.org
Subject: Re: Gen-ART Telechat review of draft-turner-
asymmetrickeyformat-05

Roni,

Thanks for your review.  Comments inline.

spt

Roni Even wrote:

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 version of the draft.

Document: draft-turner-asymmetrickeyformat-05

Reviewer: Roni Even

Review Date: 2010-4-18

IESG Telechat date: 2010-4-22

Summary: This draft is ready for publication as a Proposed Standard.

I have

some nits

Nits/editorial comments:

1.  In section 7 what you are registering is a media subtype and not

a

media type. The media type is application. So defines a new media

type

should be defines a new media subtype and Registration of media

type

should be Registration of media subtype.

I'll add this in.


2.  The document defines new object identifiers like
id-ct-KP-aKeyPackage and AsymmetricKeyPackageModuleV1.  Where is the

list of

these identifiers kept and how do you update this list in order to

guarantee

the uniqueness of these identifiers.

I got the OIDs for the content types and asn.1 module out of two arcs.
Both OIDs are unique.  Technically, we'd never update an OID.  Once
it's
registered it's registered.  If we need a new OID, then we don't
necessarily have to go back to the same arc - but I'm sure we could.
The module OID I got from the SMIME Arc, which is administered by Russ
Housley and it's been delegated from IANA to SMIME.  The other I got
out
of a DoD arc.   I should add the following the IANA considerations
sections to make this clear:

This document makes use of object identifiers to identify a CMS content
and the ASN.1 module found in Appendix A.  The CMS content type OID is
registered in a DoD arc.  The ASN.1 module OID is registered in an arc
delegated by IANA to the SMIME Working Group.  No further action by
IANA
is necessary for this document or any anticipated updates.




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen Art review of: draft-ietf-mediactrl-sip-control-framework

[Sean Turner]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-mediactrl-sip-control-framework
Reviewer: Sean Turner
Review Date: 2010-03-16
IETF LC End Date: 2010-02-11
IESG Telechat date: (not known)

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.


Sec 4.1: r/The SDP should/The SDP SHOULD

Sec 4.1: r/'Connection Data/Connection Data or r/'Connection 
Data/'Connection Data'


Sec 4.2: r/INVITE request and may/INVITE request and MAY

Sec 5: r/with given a given/with a given

Sec 5: r/User Agents may/User Agents MAY

Sec 6.1: r/All required mandatory and optional/All required, mandatory, 
and optional


Sometimes Content-Type, Content-Length, and Transaction-Timeout are 
between 's and sometimes not.


Sec 6.3: r/It is recommended/It is RECOMMENDED

Sec 6.3.3.2: r/message must be received/message MUST be received

Sec 6.3.4: r/requests may be used/request MAY be used

Sec 7.4: r/The client should not repeat the request./The client SHOULD 
NOT repeat the request.


Sec 8.6: r/This section should/This section SHOULD

Sec 8.7: r/recommended/RECOMMENDED

spt



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-Art re-review of draft-ietf-avt-app-rtp-keepalive-07

[Sean Turner]

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 resolve these comments along with any other comments you may receive.

Document: draft-ietf-avt-app-rtp-keepalive-07.txt
Reviewer: Sean Turner
Review Date: 11 February 2010
IETF LC End Date: 02 June 2009
IESG Telechat date: 18 February 2010

Summary: This document is still ready for publication.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen Art LC review of: draft-turner-ecprivatekey-02.txt

[Sean Turner]

Dan,

I actually dug masquerade out of Williams Stallings' classic network 
security book, but I like impersonate more.


spt

Dan Brown wrote:

Sean, Avshalom,

 

Maybe ”impersonate” is more specific than “masquerade”, as the latter 
also connotes a party where the parties don masks.


 

Also, “impersonate” has some precedence in cryptographic terminology.  
For example, American National Standard X9.63 for example lists an 
attack called “Key Compromise Impersonation” which is when Eve being 
able impersonate Alice to Bob, if Eve has stolen Bob’s private key.


 

Perhaps “misauthenticate” would be most specific, given that 
“authenticate” is used all the time, but I don’t recall ever seeing 
“misauthenticate”.


 


Best regards,

 


Dan

 


*From:* Avshalom Houri [mailto:avsha...@il.ibm.com]
*Sent:* Thursday, January 14, 2010 9:41 AM
*To:* Sean Turner
*Cc:* Dan Brown; General Area Review Team; Tim Polk
*Subject:* Re: Gen Art LC review of: draft-turner-ecprivatekey-02.txt

 


Sean,

I am OK with the changes. I am not familiar with the right terms in this 
field however, masquerades sound to me as only one of the possible 
things that can be done by the person that gets the private key. They 
can also  have access to encrypted material for example. Anyway if you 
think that masquerades is the right term in this field then I am OK with 
it.


-Avshalom




From:Sean Turner turn...@ieca.com
To:Avshalom Houri/Haifa/i...@ibmil
Cc:General Area Review Team gen-art@ietf.org, 
dbr...@certicom.com, Tim Polk tim.p...@nist.gov

Date:14/01/2010 04:33 PM
Subject:Re: Gen Art LC review of: draft-turner-ecprivatekey-02.txt






Avashalom,

Thanks for the review. Responses below.

spt

Avshalom Houri wrote:

 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 resolve these comments along with any other Last Call comments
 you may receive.

 Document: draft-turner-ecprivatekey-02.txt
 Reviewer: Avshalom Houri
 Review Date: 2010-01-14
 IETF LC End Date: 2010-01-14
 IESG Telechat date: (if known)

 Summary: The draft is ready for publication as an informational RFC. See
 nits.

 Major issues: None

 Minor issues:  None

 Nits/editorial comments:

 Lines 142-145
  As specified in [RFC5480], only the namedCurve
  CHOICE, which is an object identifier that fully identifies the
  required values for a particular set of elliptic curve domain
  parameters, is permitted.

 Sentence is hard to read.


How about:

As specified in [RFC5480], only the namedCurve CHOICE is permitted.
namedCurve is an object identifier that fully identifies the required
values for a particular set of elliptic curve domain parameters.


 Lines 145-146
 Though the ASN.1 indicates parameters is OPTIONAL,
 - Though the ASN.1 indicates that the parameter parameters is OPTIONAL,


How about:

Though the ASN.1 indicates that the parameters field is OPTIONAL,


 Line 196
 masquerades

 - Not sure that this is the right term. Probably identity-theft or
 similar should be used.


Masquerade is a generic term that covers one entity pretending to be
another entity.  Identity-theft to me is a little too specific to
signature keys that I think might not entirely fit this because EC keys
aren't just used for identity.  Disclosure of the private key is pretty
catastrophic so maybe I should just list more things that could happen:

Disclosure of the private-key material to another entity can lead to
active and passive attacks including: masquerade, unauthorized
disclosure, and unauthorized modification.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute 
non-public information. Any use of this information by anyone other than 
the intended recipient is prohibited. If you have received this 
transmission in error, please immediately reply to the sender and delete 
this information from your system. Use, dissemination, distribution, or 
reproduction of this transmission by unintended recipients is not 
authorized and may be unlawful.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-jabley-sink-arpa-02

[Sean Turner]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-jabley-sink-arpa-02.txt
Reviewer: Sean Turner
Review Date: 13 January 2010
IETF LC End Date: 18 January 2010
IESG Telechat date: 21 January 2010

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.


During IETF LC, Olafur noted there was a TODO list to address two 
comments from Ted Hardie.  Is a new version going to be posted that 
includes the TODO list before the IESG telechat?


Also noted during IETF LC, the SMTP reference needs to be updated.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-fecframe-dvb-al-fec

[Sean Turner]

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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-fecframe-dvb-al-fec-04.txt
Reviewer: Sean Turner
Review Date: 2010-01-08
IETF LC End Date: 2009-12-14
IESG Telechat date: unknown

Summary: This draft is ready for publication as an Informational Standard.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-giralt-schac-ns-02

[Sean Turner]

Sorry if anyone got this multiple times, but my first attempt didn't 
seem to make it to the list.


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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-giralt-schac-ns-02
Reviewer: Sean Turner
Review Date: 2010-01-03
IETF LC End Date: 2010-01-01*
IESG Telechat date: unknown

* I apologize for missing the LC end date.

Summary: This draft is on the right track but has open issues, described 
in the review.


Issue:

Is there some reason why this ID doesn't have an internationalization 
considerations section?  I would think people outside North American 
might like some characters other than ASCII.


Section 2 Identifier assignment: The text indicates that TERENA will 
define processes to for adding to the list of authorities.  Has this 
process be written yet?  If it has, can a reference be added to it?  If 
not, shouldn't this ID wait for the completion of these processes?  And, 
shouldn't this process be included in the relevant ancillary 
documentation section of the template?


Section 5: Indicates TERENA will set up a registration service.  If 
there's some rules for using this registration service, then it might be 
nice to have them referred to in the relevant ancillary documentation 
section of the template.


Technical:

Section 2 Identifier persistence: Should responsibility may be be 
responsibility MAY be.


Editorial:

Section 1: Spell out TF-EMC2 the first time it is used.

Section 1: r/Trans European Research and Education Network 
Association/Trans-European Research and Education Network Association 
(TERENA)


note the - that the terena.org website uses.

Section 4: Spell out MACE.

Section 5: r/National Research and Education Networks/National Research 
and Education Networks (NRENs)


Section 8.2: [4] Should a reference to the terena.org website be 
included as part of the reference (assuming it's stable)?


Section 8.2: [9] should it point to 
http://www.iana.org/domains/root/db/?  I assume this reference is stable!?


Again, sorry this was late.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Telechat review of draft-turner-deviceowner-attribute-02

[Sean Turner]

Drat!  I'll fix this.

spt

McCann Peter-A001034 wrote:

All my comments were addressed, but I think a new typo was introduced.
The old draft correctly used the term digram to refer to a sequence
of two letters (as in a country code).  The latest revision changed this
to diagram, which I think is incorrect.

-Pete


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-Art re-review of draft-ietf-avt-app-rtp-keepalive-06.txt

[Sean Turner]

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 resolve these comments along with any other comments you may receive.

Document: draft-ietf-avt-app-rtp-keepalive-06.txt
Reviewer: Sean Turner
Review Date: 15 November 2009
IETF LC End Date: 02 June 2009
IESG Telechat date: unknown

Summary: This document is ready for publication.

All of my comments on the -05 draft were addressed in the -06 draft.

spt

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-Art re-review of draft-ietf-behave-turn-uri-04.txt

[Sean Turner]

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 resolve 
these comments along with any other comments you may receive.


Document: draft-ietf-behave-turn-uri-04.txt
Reviewer: Sean Turner
Review Date: 2009-11-15
IETF LC End Date: 2009-10-29
IESG Telechat date: N/A

Summary: This draft is ready for publication.

This version addresses all of the comments I made on version -03.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-Art re-review of draft-ietf-bmwg-ipsec-meth

[Sean Turner]

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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-bmwg-ipsec-meth-06.txt
Reviewer: Sean Turner
Review Date: 2009-11-15
IETF LC End Date: N/A
IESG Telechat date: 2009-10-22

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.


None of my comments on draft -05 were addressed in draft -06.  They were 
as follows:


Comments:

The NITS tool is complaining about 16 unused references and 10 obsolete 
references.  I'd also add that [FIPS.186-1.1998] isn't actually used as 
a reference.


Nits:

Sec 4: r/in RFC 2119.  RFC 2119/in [RFC2119].  [RFC2119]
Secs 8.1-11.3: r:/Topology /Topology:
Sec 8.1: r/If all packet are/If all packets are
Sec 8.1: r/format should reflect/format SHOULD reflect
Sec 10.1: r/Reporting Format/Reporting Format:
Sec 13.1: r/(timestamp_B).The/(timestamp_B). The

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-Art review of draft-lha-gssapi-delegate-policy-04.txt

[Sean Turner]

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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-lha-gssapi-delegate-policy-04.txt
Reviewer: Sean Turner
Review Date: 2009-11-15
IETF LC End Date: 2009-12-08
IESG Telechat date: unknown

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication


Comments: This draft is basically ready for publication, but has nits 
that should be fixed before publication.


Nits:

Spell out CIFS on first occurance.  It's not in the RFC Editor's 
abbreviations list 
(http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt).


Sec 1: r/It would is desirable/It is desirable

Sec 2: r/If the deleg_policy_req_flag is set, then delegation should be 
performed if recommended by central policy./If the deleg_policy_req_flag 
is set, then delegation SHOULD be performed if recommended by central 
policy.


Sec 5: r/the MUST/they MUST

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GEN-Art re-review of draft-ietf-bmwg-ipsec-meth

[Sean Turner]

My bad.  I must still be jet lagged.

There are normally GEN-Art and SEC-DIR reviews.  Sometimes there's also 
an OPS-DIR review.  To see what IESG members had to say: 
https://datatracker.ietf.org/idtracker/ballot/3192/


spt

Merike Kaeo wrote:
Yes, I was waiting to make sure all relevant comments had been given 
before spending the day incorporating.  I hadn't gotten notification 
that all were but since there were no more emails with any comments for 
last 3 weeks it's safe to assume that no more are coming.


Just for future reference, as a draft author when folks go through the 
IESG comment process, is there a way for me to tell that all folks who 
are supposed to comment have commented?  If I missed an email somewhere 
or needed to look at status somewhere, sincere apologies.


- merike

On Nov 15, 2009, at 5:51 AM, Al Morton wrote:


At 08:08 AM 11/15/2009, Sean Turner wrote:

...
None of my comments on draft -05 were addressed in draft -06.  They 
were as follows:

Sean,  your comments on -05 were received on 10/17.
Version -06 has not been produced yet, and
draft -05 was deferred before the previous telechat.

Al
bmwg chair




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] GEN-ART review of draft-ietf-behave-turn-uri-03.txt

[Sean Turner]

Marc Petit-Huguenin wrote:

Hi Sean,

Thanks for the review.  See my comments below.

Sean Turner wrote:

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-behave-turn-uri-03.txt
Reviewer: Sean Turner
Review Date: 2009-10-17
IETF LC End Date: 2009-10-29
IESG Telechat date: N/A

Summary: This draft is basically ready for  publication, but has nits
that should be fixed before publication

Question: I see that in Section 4 you stop and error if turns/udp is
selected.  Did you investigate using DTLS?


TURN currently does not support DTLS (or SCTP or HTTP - I wrote an unpublished
I-D for TURN over HTTP/HTTPS).  I assumed that the same I-D that would describe
TURN over DTLS or any other transport would also modify the rules in the
turn-uri RFC to support it.


I figured there had to be an easy answer.


Minor Comment:

Sec 4, 3rd paragraph Should the should not be should not in the
following:


Do you mean SHOULD NOT?  If so, then yes.  Applied.


Yes I meant SHOULD NOT.  Note that in Sec 4 #3: there's a lower case must:

for the SRV service name defined in scheme must be used for contacting 
the TURN server.



Servers blacklisted as described in section 6.4 of
[I-D.ietf-behave-turn] should not be used for the specified duration
even if returned by a subsequent resolution.

Nit:

Sec 4 #1: r/If host is an IP address then it/ If host is an IP
address, then it



Applied.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-ART review of draft-ietf-bmwg-ipsec-meth-05.txt

[Sean Turner]

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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-bmwg-ipsec-meth-05.txt
Reviewer: Sean Turner
Review Date: 2009-10-17
IETF LC End Date: N/A
IESG Telechat date: 2009-10-22

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication


Comments:

The NITS tool is complaining about 16 unused references and 10 obsolete 
references.  I'd also add that [FIPS.186-1.1998] isn't actually used as 
a reference.


Nits:

Sec 4: r/in RFC 2119.  RFC 2119/in [RFC2119].  [RFC2119]
Secs 8.1-11.3: r:/Topology /Topology:
Sec 8.1: r/If all packet are/If all packets are
Sec 8.1: r/format should reflect/format SHOULD reflect
Sec 10.1: r/Reporting Format/Reporting Format:
Sec 13.1: r/(timestamp_B).The/(timestamp_B). The
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-Art review of draft-ietf-dhc-relay-id-suboption-07

[Sean Turner]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-dhc-relay-id-suboption-07
Reviewer: Sean Turner
Review Date: 2009-10-06
IETF LC End Date: 2009-10-16
IESG Telechat date: N/A

Summary: This draft is on the right track but has open issues, described
in the review

Major #1 It's not clear to me whether both relay identifier types MUST
be supported or whether implementations are free to pick which one(s)
they support?  If you add one of the following (or something similar) in
Section 5 then my concern is addressed:

Implementations MUST support both RELAY_IDENTIFIER_DUID and
RELAY_IDENTIFIER_ASCII.

Implementations MUST support RELAY_IDENTIFIER_DUID and [SHOULD or MAY]
support RELAY_IDENTIFIER_ASCII.

Implementations MUST support RELAY_IDENTIFIER_ASCII and [SHOULD or MAY]
support RELAY_IDENTIFIER_DUID.

Major #2  In the security considerations it says look to RFC 3046 and
RFC 4030 for security considerations and then says SHOULD use the relay
agent authentication option from RFC 4030.  RFC 3046 is targeted at
network infrastructures that are trusted and secure and RFC 4030
allows the relay agent to be part of this trusted and secure network.
If an implementation doesn't use the relay agent authentication option,
then the relay agent can't be part of the trusted and secure network.
 This makes me think that the relay agent authentication option from
RFC 4030 ought to be a MUST not a SHOULD?

spt

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-Art review of draft-ietf-ccamp-mpls-graceful-shutdown

[Sean Turner]

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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-ccamp-mpls-graceful-shutdown
Reviewer: Sean Turner
Review Date: 2009-10-01
IETF LC End Date: 2009-10-05
IESG Telechat date: N/A

Summary: This document is ready for publication as an Information RFC.

Comments: None.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-ART review of draft-ietf-eai-downgraded-display

[Sean Turner]

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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-eai-downgraded-display-02
Reviewer: Sean Turner
Review Date: 2009-09-21
IETF LC End Date: 2009-09-23
IESG Telechat date: N/A

Summary: This document is ready for publication as an Experimental RFC.

Comments: None.

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-ART review of draft-ietf-mip4-generic-notification-message

[Sean Turner]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-mip4-generic-notification-message-09.txt
Reviewer: Sean Turner
Review Date: 2009-09-07
IETF LC End Date: 2009-09-08
IESG Telechat date: N/A

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.

I have to admit that following along in section 4.3.*, 4.4.*, and 4.5.*
is a little tough for somebody who is not steeped in the mip4 WG.  I
don't think it is avoidable, but I am leaning somewhat on the WG/authors
to ensure it all hangs together (it is the -09 version after all).

4: The follow sentence is awkward: The MN and HA MUST maintain the
following information, the FA also need maintain both HA's and MN's
direction the below information:.  Should it be FA also needs to
maintain both the HA's ...?

4.1 and 4.2: I assume the Type (TBD) will be assigned by IANA, but
should there be an RFC Editor's note added to indicate as much?

4.5.4: r/by The MN-FA/by the MN-FA

5: r/. for/. For

5: r/mechanism also./mechanism.

5: The last sentence before the list has 3 values, but the sentence says
theres are four values reserved.  Is it 3 or 4?

7:

OLD:

The author appreciate the efforts of Ahmad Muhanna in detail reviewing
of this document, lots of text have been contributed by his suggestions.
 The author thank the discussion from Kent Leung, Peng Yang and Peter
McCann et al. in the development of this document.

NEW:

The authors appreciate the efforts of Ahmad Muhanna for his detailed
review of this document and his many contributions to the text of this
document.  The authors also want to thank Kent Leung, Peng Yang, and
Peter McCann et al. for their help developing this document.

8: r:/It require that this message/It requires that these messages
? There are two messages defined correct?

8.1: r/This document require/This document requires

8.1: r/two peer node/two peer nodes

There are a number of places where . if should be replaced by . If
and .  if should be replaced by .  If.

So this might be considered nit picking, but normally when I start a
sentence of with If , right after the comma there's a then 


Cheers,

spt




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-ART review of draft-ietf-pwe3-segmented-pw-13.txt

[Sean Turner]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-pwe3-segmented-pw-13.txt
Reviewer: Sean Turner
Review Date: 2009-08-31
IETF LC End Date: 2009-09-02
IESG Telechat date: N/A

Summary: This draft is basically ready for  publication, but has nits 
that should be fixed before publication.


Nits:

http://www.ietf.org/id-info/checklist.html indicates that should not be 
more than 5 authors.  There's 7 on this one.


Normally, the introduction is section #1.  I'd suggest making Section 3 
Section 1 and Section 1 Section 3.


Sec 7.4.1: Indicates the PW Switching Point description string is 80 
characters long.  Shouldn't it say more about what the character set is?


Sec 8.4.1: Figure shows both AC Up and AC UP.  Should they all be Up?

Sec 16: r/Author's/Authors'

According to the nits checker:

  == Outdated reference: A later version (-11) exists of
 draft-ietf-pwe3-oam-msg-map-10

  == Outdated reference: A later version (-07) exists of
 draft-ietf-pwe3-ms-pw-arch-06

There are a couple of places where  ,  appears and should be changed 
to , 

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review: draft-turner-clearancesponsor-attribute-01.txt

[Sean Turner]

Joel M. Halpern wrote:
On the first resolution, that looks sufficient.  You reference both the 
need for ASN.1, and the need for clearence.


On the second issue, I may have been unclear.
It is not obvious to me that all uses of this attribute must inherently 
be situations in which there is only one sponsor.Thus, the restriction 
to one occurrence of the field seems to be a policy restriction, rather 
than a technical once.
If there is a tehcnical reason why it must occur once, then it would be 
good to say that.  (For example, if receivers could not properly process 
a message with multiple such fields.)  If there is no technical problem 
with multiple occurrences, then even if we can not see why we need it 
now, I don't understand why the document outlaws it.


I believe there will be only one sponsor included in a certificate*.

The clearance sponsor in the certificate vouches for the mapping of the
subject name to the person to the included clearance. The CA's
responsibility is then that the clearance sponsor has been validated,
and that the public key really corresponds to the subject that the
clearance sponsor identifies.  Because the clearance sponsor is included
in the certificate, this vouching has to happen before the certificate
is issued.  The CA needs to get the nod from one source.  We don't want 
to get in to the case were two sources say yes it's her and that's her 
clearance, but voucher A did process X which isn't as thorough as 
voucher B who did process Y.


Another way to think about this is terms of CA vouching for the binding 
of the key and name.  There's only one that can do it because they're 
applying their signature to the certificate.  If another CA also wants 
to vouch then it issues another certificate.


spt

* I was unaware of the extra work necessary to claim that the attribute
could be included in an LDAP directory (i.e., the schema, the transfer
syntax, etc.) so we're targeting this attribute at certificates.


Yours,
Joel

Sean Turner wrote:

Joel,

Thanks for your timely review.

spt

Joel M. Halpern wrote:

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-turner-clearancesponsor-attribute-01.txt
Clearance Sponsor Attribute
Reviewer: Joel M. Halpern
Review Date: 3-August-2009
IETF LC End Date: 14-August-2009
IESG Telechat date: N/A

Summary: This document is almost ready for publication as an 
Informational RFC.


Minor issues:  In trying to balance versatility and specificity, the 
introduction states that the attribute defined in this document may 
be used in X, Y, or locations that support attributes.  Given that 
almost all our protocols support attributes for some meaning of the 
word, I think a somewhat better description is called for.  It may 
just suffice to say locations or protocols that support ASN.1 
definitions of attributes of entities which may conceptually have 
been cleared by (some suitable words).  (Yes, I see that RFC 3281bis 
uses the same terminology.  It seems confusing to me.)


How about I change the intro as follows (with other comments I've
also received mixed in):

OLD:

This document specifies the clearance sponsor attribute.  This attribute
may be included in public key certificates [RFC5280], attribute
certificates [RFC3281bis], directories [X.500]/[RFC4512], or locations
that support attributes.  These attributes may be used in authorization
decisions

NEW:

This document specifies the clearance sponsor attribute. This attribute
may be included in locations or protocols that support ASN.1 attribute
definitions to indicate the entity that sponsored the clearance.  This
attribute is only meaningful when the clearance attribute [RFC3281bis]
is also included.

This attribute may be used in authorization decisions.  For example, a
web server deciding whether to allow a user access could check that the
clearance sponsor present in the user's certificate is on an approved
list. The web server could also check that the included clearance
sponsor is on an approved list to issue the included clearance.

NOTE: This document does not provide LDAP equivalent schema
specification as this attribute is initially targeted at public key
certificates [RFC5280] and attribute certificates [RFC3281bis].  This is
left to a future specification.


Nits/editorial comments:  Is it really true that world-wide 
clearances can always be sponsored by only one entity?  The 
restriction to one value seems to be a policy statement about a 
particular approach, so I wonder if it is correct to capture that in 
the object definition?  Or is this a US Government only definition?  
(It doesn't say that, so I am assuming it has broader applicability 
than that.)


We're not advocating a world-wide clearance.  The model I've dealt

Re: [Gen-art] Gen-ART review of draft-turner-deviceowner-attribute-01

[Sean Turner]

Peter,

Thanks for the review.  Responses inline.

spt

McCann Peter-A001034 wrote:

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
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ). 


Please resolve these comments along with any other Last Call comments
you may receive. 


Document: draft-turner-deviceowner-attribute-01
Reviewer: Pete McCann
Review Date: 2009-08-27
IETF LC End Date: 2009-08-28
IESG Telechat date: unknown 


Summary: Almost Ready

Major issues: None

Minor issues: 

The Abstract and Introduction are worded in a way similar to 
draft-turner-clearancesponsor-attribute-01.txt and the same

re-wording should be applied as in the discussion with Joel.


Agreed.

Nits/editorial comments: 

Please run the ASN.1 thorugh a syntax checker. 


I will.  Also noticed that IDENTIFIED BY should have been ID.


The word IMPLICIT is mis-spelled in the ASN.1 in the appendix.


Fixed.


The choice elements alphaNCountry have a different capitalization
in the appendix (AlphaNCountry).


Somebody else also caught this.  I have made the change to use lower 
case in the module.



The syntax checker that I tried didn't like the [0] after Alpha2Country.
I am not an ASN.1 expert so perhaps this is newer syntax.


It is a later version ('02).  The OSS syntax checker said it passed 
after I made the changes.



It looks like there is a missing close-paren after the NumericCountry
SIZE specification.


numericCountry was just wrong.  The proper size constraints are as follows:

numericCountry INTEGER (0..999),


It looks like there is an exra open-curly before joint-iso-ccitt.


Fixed.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-ietf-pkix-authorityclearanceconstraints-02.txt

[Sean Turner]

Francis Dupont wrote:

 In your previous mail you wrote:

Minor issues: 
 - IMHO a transition paragraph is needed at the end of the Introduction

  in order to introduce technical dependencies:
  * clearance attribute is in fact from 3281bis (this is obvious when
  one reads the ASN.1 module appendix but it should be mentioned as
  soon as possible)
   
   I agree that's why it's in the last sentence of the 1st paragraph in the 
   intro ;)
   
= well, I missed it (:-).


Well I missed your response.  Somebody had to tell me to respond so 
we're  even ;)





 The whole idea is to prepare a first reader (IMHO it is a problem when
 a document needs to be read more than once to get a good idea about
 what it specifies :-).

 - another issue is the multiple values in a Clearance attribute.

  The Clearance attribute syntax of section 2 is in fact for an
 AttributeValue type and doesn't include multiple values (only
 multiple SecurityCategory). Of course the Attribute in AC can
 contains multiple values, so the text often uses the term value
 in a very ambiguous way.
   
   We restrict the number of times clearance can be included in a 
   certificate to one or zero. We also restrict it to be single valued.
   
= this is what I understood but there are some places in the document

where the term value is used about the clearance AttributeValue type,
for instance inside AuthorityClearanceConstraints.

   Are you referring to the Authority Clearance Constraint extension that 
   can include multiple values?
   
= an extension can contain only one value embedded inside an OBJECT

STRING, and it is forbidden (RFC 5280 4.2) to have multiple extensions
with the same OID. So IMHO extensions and multiple values are exclusive.


Okay now I get it.  We'll work on a revision to address this.


 - 3 page 6: I don't understand this statement:
  In 
   addition, each Clearance attribute in the SEQUENCE must not contain 
   more than one value.

  perhaps SEQUENCE should be sequence (of AuthorityClearanceConstraints)?
   
   SEQUENCE refers to the ASN.1 construct for the extension.  We didn't 
   capitalize sequence previously so we'll switch it to lower case.  Note 
   the must ought to be MUST.
   
= but a AuthorityClearanceConstraints contains clearances, no clearance

attributes, so what does mean the more than one value?


The sentence in question is going to get deleted.


 - 4.1.1.2 page 8: can't understand:
   If any of the Clearance attributes in the permitted-clearances 
   contains more than one value
   
   This check makes sure there is only one value in permitted-clearances.
   
= the permitted-value is either all-clearances or a

AuthorityClearanceConstraints, so there is no Clearance attributes
in it, nor a value...


I think this will end up getting deleted too.


 - 4.1.1.5.1 page 9:
  in If the permitted-clearances has special value of all-clearances, exit 
  with success. what about the effective-clearance (unchanged?)
   
   There's no need to set this value as it's the special case where it 
   matches all.
   
= the output is both the effective-clearance (with the - everywhere,

including in 4.1.1.6) and success/failure, so all exists must specify
both.


I don't think we're going to change this one.  effective-clearance has 
no meaning when it's set to all-clearances.



 - 8 page 15: what is id-TBSL?
   
   It stands for To Be Supplied Later.  I guess now would be a good time ;) 
 I need to get an OID from Russ we'll add this in the next version.
   
= until you'll get one IMHO a comment should explain this

(only TBD is recognized :-).


Fair enough.


To fix my main concern about the term value, as ASN.1 is not LISP (:-)
I propose to typecheck all types where the term is used and to keep
it when the type can contain a value (typically contain an attribute),
remove it if it can't or replace it by SecurityCategory (or other?)
if it is what you'd like to mean.


We'll go through these to fix the ones that make sense after we 
incorporate the changes for the value text.



francis.dup...@fdupont.fr

PS: occurences of value:


I delete the ones we got right ;)


3
   The syntax for Authority Clearance Constraints certificate extension 
   contains Clearance values that the CA or the AA asserts.


= correct but IMHO misleading. I propose to remove the word values.


Agreed


3
   In 
   addition, each Clearance attribute in the SEQUENCE must not contain 
   more than one value. 


= incorrect (no attribute, lower case SEQUENCE, upper case must,
no multiple values).


Sentence to be deleted.


4.1.1.2
   If any of the Clearance attributes in the permitted-clearances 
   contains more than one value, set effective-clearance to an empty 
   list, set error code to multiple values in input, and exit with 
   failure. 


= incorrect (no attribute, no multiple value)


Sentence to be deleted.

Re: [Gen-art] review: draft-turner-clearancesponsor-attribute-01.txt

[Sean Turner]

Joel,

Thanks for your timely review.

spt

Joel M. Halpern wrote:

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-turner-clearancesponsor-attribute-01.txt
Clearance Sponsor Attribute
Reviewer: Joel M. Halpern
Review Date: 3-August-2009
IETF LC End Date: 14-August-2009
IESG Telechat date: N/A

Summary: This document is almost ready for publication as an 
Informational RFC.


Minor issues:  In trying to balance versatility and specificity, the 
introduction states that the attribute defined in this document may be 
used in X, Y, or locations that support attributes.  Given that almost 
all our protocols support attributes for some meaning of the word, I 
think a somewhat better description is called for.  It may just suffice 
to say locations or protocols that support ASN.1 definitions of 
attributes of entities which may conceptually have been cleared by (some 
suitable words).  (Yes, I see that RFC 3281bis uses the same 
terminology.  It seems confusing to me.)


How about I change the intro as follows (with other comments I've
also received mixed in):

OLD:

This document specifies the clearance sponsor attribute.  This attribute
may be included in public key certificates [RFC5280], attribute
certificates [RFC3281bis], directories [X.500]/[RFC4512], or locations
that support attributes.  These attributes may be used in authorization
decisions

NEW:

This document specifies the clearance sponsor attribute. This attribute
may be included in locations or protocols that support ASN.1 attribute
definitions to indicate the entity that sponsored the clearance.  This
attribute is only meaningful when the clearance attribute [RFC3281bis]
is also included.

This attribute may be used in authorization decisions.  For example, a
web server deciding whether to allow a user access could check that the
clearance sponsor present in the user's certificate is on an approved
list. The web server could also check that the included clearance
sponsor is on an approved list to issue the included clearance.

NOTE: This document does not provide LDAP equivalent schema
specification as this attribute is initially targeted at public key
certificates [RFC5280] and attribute certificates [RFC3281bis].  This is
left to a future specification.


Nits/editorial comments:  Is it really true that world-wide clearances 
can always be sponsored by only one entity?  The restriction to one 
value seems to be a policy statement about a particular approach, so I 
wonder if it is correct to capture that in the object definition?  Or is 
this a US Government only definition?  (It doesn't say that, so I am 
assuming it has broader applicability than that.)


We're not advocating a world-wide clearance.  The model I've dealt with 
numerous time wrt security policies is that the security policy is 
defined for an organization and that organization has many 
sub-organizations.  When an access control decision is made the decision 
maker sometime wants to know who sponsored the clearance holder.  The 
clearance attribute doesn't indicate who sponsored the clearance holder 
so this attribute was defined to address this need.


It's not just US Government specific.  This model actually holds for
many governments and other organizations that have implemented security
policies.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-ART review of draft-ietf-alto-problem-statement-02.txt

[Sean Turner]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-alto-problem-statement-02.txt
Reviewer: Sean Turner
Review Date: 2008-08-02
IETF LC End Date: 2009-08-04
IESG Telechat date: N/A

Summary: This document is ready for publication as an Informational RFC.

The one question in my mind is whether this should proceed now or remain 
a living document and become final at the end?  Is ALTO going to redo 
this document if they decide to expand their scope?


spt



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Lunch on Thursday

[Sean Turner]

Where is the lunch?

spt

Mary Barnes wrote:


HI all,

I was not successful in finding a place other than the Clarion 
restaurant for lunch. I ate there on Monday and while the kitchen 
doesn't open till noon, they were just able to get us out of there by 
1pm and for the food was quite good in my opinion, just a bit more 
expensive.   So, just head over after your 11:30 session. 


Mary.




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-Art review of draft-solinas-rfc4753bis-00.txt

[Sean Turner]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-solinas-rfc4753bis-00.txt
Reviewer: Sean Turner
Review Date: 2009-07-28
IETF LC End Date: 2009-08-06
IESG Telechat date: N/A

Summary: This draft is ready for publication as an Information RFC.*

* I did not verify the math.

spt


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-Art Review of draft-ietf-sipcore-subnot-etags-02.txt

[Sean Turner]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-sipcore-subnot-etags-02.txt
Reviewer: Sean Turner
Review Date: 2009-06-21
IETF LC End Date: 2009-06-23
IESG Telechat date: 2009-07-02

Summary: This draft is ready for publication as a Proposed Standard.

spt






___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-Art review of draft-ietf-ipsecme-ikev2-redirect-11.txt

[Sean Turner]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-ipsecme-ikev2-redirect-11.txt
Reviewer: Sean Turner
Review Date: 2009-06-21
IETF LC End Date: 2009-06-30
IESG Telechat date: N/A

Summary: This draft is ready for publication as a Proposed Standard.

Nits:

Section 5 (last para) and Section 6 (1st para): Should Informational 
(x3) be all upper case?


Section 8.3 (2nd para): r/3.10 of [2]/3.10 of [2].
 ^
Section 10 (4th para): r/more a certain/more than a certain

Section 10 (last para): r/might not available/might not be available

spt

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC Review of draft-ietf-pce-inter-layer-frwk-10.txt

[Sean Turner]

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 resolve
these comments along with any other Last Call comments you may receive.

Document: draft-ietf-pce-inter-layer-frwk-10.txt
Reviewer: Sean Turner
Review Date: 2009-06-09
IETF LC End Date: 2009-06-16
IESG Telechat date: (not known)

Summary: This draft is basically ready for publication (informational
with no RFC 2119 requirements terminology), but has nits that should be
fixed before publication.

I ran it through ID-nits:
- is a pre-5378 disclaimer needed?
- draft-ietf-pce-brpc has been published as RFC 5441
- draft-ietf-pce-path-key has been published as RFC 5520

In 5.1, there's missing reference:  PCEP [  a href='RFC5440]


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART Review of draft-ietf-geopriv-l7-lcp-ps-09.txt

[Sean Turner]

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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-geopriv-l7-lcp-ps-09.txt
Reviewer: Sean Turner
Review Date: 2009-05-29
IETF LC End Date: 2009-06-09
IESG Telechat date: (not known)

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.


Nits/editorial comments:

Abstract: Spell out 1st occurrence of SIP

1.1: r/This document is structured as follows./This remainder of this 
document is structured as follows.


Figure 1: r/|Customer Premises Network  |/| Customer Premises Network |

3: Spell out 1st occurrence of DSL

3: r/Wimax/WiMAX

3: r/WiMax/WiMAX

3.1: Spell out 1st occurrence of DHCP, NIC, PPPoe, VoIP, LAN, VPN

3.2: Spell out 1st occurrence of IP

Figure 2: There are two Host B boxes.  Should one be B' (i.e., Host B 
moved?)


4  5: r/They do not in any way mean that their is consensus that any of 
these approaches are good or bad or that the IETF is in any recommended 
in this document that any of these be used./They do not in any way mean 
that their is consensus that any of these approaches are good or bad or 
that the IETF is in any way recommending that any of these be used.


4: r/or in access network/or in [the/an?] access network

4: Spell out 1st occurrence of FQDN, DNS, SRV, NAPTR, STUN

4: Is there a reference for how to thwart the noted security issues?

5: Spell out 1st occurrence of MAC, ATM, VCI, VPI, VC, DSLAM, VDSL, CDP, 
 RADIUS,


5: Is there a reference for the TR-069v2 DSL Forum document?

5: Is there a reference for how to thwart the noted security issues 
(e.g., a pointer to link layer protection mechanisms)?


6: Not sure I understand this , to devices that can change attachment 
points with the impact that their IP address is changed, to devices that 
do not change their IP address while roaming.  What's the with the 
impact that their about?


6 VPN: r/LIS used by the client/LIS used by the VPN client

6: Spell out 1st occurrence of NSIS, NATFW, NSLP

6: r/[19] ./[19].
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-geopriv-l7-lcp-ps-09.txt

[Sean Turner]

There's a list of abbreviations you don't have to spell out 
(http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt) that I 
didn't know about so don't bother spelling out (the one's with the *s 
(thanks Spencer)): SIP, DSL, DHCP, LAN, IP, DNS, ATM.


spt

Sean Turner wrote:
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 resolve 
these comments along with any other Last Call comments you may receive.


Document: draft-ietf-geopriv-l7-lcp-ps-09.txt
Reviewer: Sean Turner
Review Date: 2009-05-29
IETF LC End Date: 2009-06-09
IESG Telechat date: (not known)

Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.


Nits/editorial comments:

Abstract: Spell out 1st occurrence of SIP

1.1: r/This document is structured as follows./This remainder of this 
document is structured as follows.


Figure 1: r/|Customer Premises Network  |/| Customer Premises Network |

3: Spell out 1st occurrence of DSL

3: r/Wimax/WiMAX

3: r/WiMax/WiMAX

3.1: Spell out 1st occurrence of DHCP, NIC, PPPoe, VoIP, LAN, VPN

3.2: Spell out 1st occurrence of IP

Figure 2: There are two Host B boxes.  Should one be B' (i.e., Host B 
moved?)


4  5: r/They do not in any way mean that their is consensus that any of 
these approaches are good or bad or that the IETF is in any recommended 
in this document that any of these be used./They do not in any way mean 
that their is consensus that any of these approaches are good or bad or 
that the IETF is in any way recommending that any of these be used.


4: r/or in access network/or in [the/an?] access network

4: Spell out 1st occurrence of FQDN, DNS, SRV, NAPTR, STUN

4: Is there a reference for how to thwart the noted security issues?

5: Spell out 1st occurrence of MAC, ATM, VCI, VPI, VC, DSLAM, VDSL, CDP, 
 RADIUS,


5: Is there a reference for the TR-069v2 DSL Forum document?

5: Is there a reference for how to thwart the noted security issues 
(e.g., a pointer to link layer protection mechanisms)?


6: Not sure I understand this , to devices that can change attachment 
points with the impact that their IP address is changed, to devices that 
do not change their IP address while roaming.  What's the with the 
impact that their about?


6 VPN: r/LIS used by the client/LIS used by the VPN client

6: Spell out 1st occurrence of NSIS, NATFW, NSLP

6: r/[19] ./[19].
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART review of draft-ietf-smime-3278bis-07.txt

[Sean Turner]

Miguel,

Thanks for the review.  Responses inline.

spt

Miguel A. Garcia wrote:

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 version of the draft.

Document: draft-ietf-smime-3278bis-07.txt
Reviewer: Miguel Garcia miguel.a.gar...@ericsson.com
Review Date: 27-May-2009
IETF LC End Date: 28-May-2009

Summary: The document is almost ready for publication as Informational 
RFC. There are a number of minor/nits comments.


Comments:

- In Section 7, I am missing a normative reference to ASN.1. Probably 
this is either [X.680] or the same reference used by 
draft-ietf-smime-new-asn1:


   [ASN1-2002]
  ITU-T, ITU-T Recommendation X.680, X.681, X.682, and
  X.683, ITU-T X.680, X.681, X.682, and X.683, 2002.


I changes 7 to be: The ASN.1 syntax [X.680], [X.681], X.682], [X.683]
used in this document is gathered in this section for reference purposes.

- Similarly, in Section 7.1.1 there should be normative references to 
SHA1-, SHA-224, SHA-256, etc.


The last sentence in 7.1.1 provides the references.  While [CMS-ALG] and
[CMS-SHA2] aren't the algorithm specifications, they do provide
algorithm conventions and then point to the appropriate FIPS.  Is this
acceptable?

- There are a number of notes at the end of Sections 7.1.2 and 7.1.3. 
These notes, contains a normative text (the word OPTIONAL). I believe a 
note should be informative in nature, thus, it should not contain 
RFC-2119 reserved words. Perhaps the text should be promoted outside a 
note.


I removed NOTE: from the last paragraph in 7.1.2 and 7.1.3.

- Section 7.1.3, the text mentions ECDSA with SHA-1, ECDSA with SHA-224, 
etc... Is there a reference to add here? The same question is applicable 
to Sections 7.1.4, 7.1.5, etc. Even Section 8. I believe all these 
should be normative references.


The last sentence in 7.1.3, 7.1.5, and 7.1.6 provides the references for
the algorithms.  While references aren't algorithm specifications, they
do provide conventions and then point to the appropriate FIPS/RFC.  Is
this acceptable?

References definitely missing from 7.1.4.

For section 8, I've got to ask if I need to sprinkle the
references after each algorithm OID/name if they're already in section 7?

- Honestly, I didn't understand the IANA Considerations section. I don't 
undersetand if IANA needs to take an action or not, and if it needs to 
do it, which is the registry they should act upon and which values they 
should assign. This should be clarified.


I had this wrong.  The Arc isn't delegated from IANA it's delegated from
RSA.  I clarified this, the # of OIDs we needed, and who does the
registrations (note that Russ Housley has acted as the SMIME WG 
Registrar).  It now says:


This document makes extensive use of object identifiers to register 
originator public key types and algorithms. The algorithm object 
identifiers are registered in the ANSI X9.62, ANSI X9.63, NIST, RSA, and 
SECG arcs. Additionally, object identifiers are used to identify the 
ASN.1 modules found in Appendix A (there are two). These are defined by 
the SMIME WG Registrar in an arc delegated by RSA to the SMIME Working 
Group: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 
smime(16) modules(0).  No action by IANA is necessary for this document 
or any anticipated updates.


Clearer?
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART review of draft-ietf-avt-app-rtp-keepalive-05.txt

[Sean Turner]

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-avt-app-rtp-keepalive-05.txt
Reviewer: Sean Turner
Review Date: 19 May 2009
IETF LC End Date: 02 June 2009
IESG Telechat date: unknown

Summary: This draft has serious issues, described in the review, and 
needs to be rethought.


NOTE: If I'm off base on the BCP track comment, then I'd change my 
summary to: This draft is basically ready for publication, but has nits 
that should be fixed before publication.


ISSUES:

It's not clear to me why this ID is intended status is BCP.  What was 
the rationale for BCP?  According to RFC 2026, BCPs standardize 
practices and the results of community deliberations for common 
guidelines for policies and operations as well as the operation of the 
IETF itself.  RFC 2026 doesn't say that BCPs about protocols need to be 
in an RFC, but it seems odd to me that the protocol this ID recommends 
is in the RFC editor's queue.  To me, this ID reads like a 
requirements/rationale document for why draft-ietf-avt-rtp-and-rtcp-mux 
ought to be used over the other available mechanisms with some 
exceptions procedures.  Can this document be merged in to 
draft-ietf-avt-rtp-and-rtcp-mux as an appendix or should the intended 
status be different?


In each Section 4.* recommendation, RFC 2119
requirements terminology is used but the words are lower case and the
words used don't match the requirements terminology used in Section
5.  For example, 4.1 says should not for Transport Packet of 0-byte
but section 5 says NOT RECOMMENDED.  Was this done on purpose?  Can we 
delete the recommendation parts of Section 4.* (as they are really 
covered in Section 5), can we use different words in the recommendations 
paragraphs in 4.1 (e.g., ought instead of should), or can we use the 
same words in Section 4.* that are used in Section 5?


Section 7: 1st sentence: An application supporting this
specification must transmit either or An application supporting this
specification MUST transmit either?

NITS:

Section 1: r/their refreshment/keeping them refreshed

Section 4.1: r/(e.g.  UDP packet, DCCP packet ...)/(e.g.  UDP
packet, DCCP packet).

Section 5: You offer explanations in Section 5 why to use or not use
4.1, 4.2, 4.3, 4.4, and 4.6 but curiously not 4.5.  Was this omitted for
a reason?  Note: if the recommendations parts of 4.* are removed you
need to add something about 4.5 in Section 5.

Section 6.1: r/does not allow to use different payloads within a
same RTP session/Real-time text payload format [RFC4103] does not allow
different payloads within the same RTP session

spt
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Review of draft-ietf-pkix-3281update-04

[Sean Turner]

Pete,

I'll expand the acronym and fix the spelling during AUTH48.

spt

McCann Peter-A001034 wrote:

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 resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-pkix-3281update-04
Reviewer: Pete McCann
Review Date: 10 April 2009
IETF LC End Date: 10 April 2009
IESG Telechat date: unknown 


Summary: Ready for publication as a Proposed Standard

Major issues: 



Minor issues:

Section 4.2.8:
   this field SHOULD NOT be used by conforming CAs
I assume CA is Certificate Authority that issued the AC issuer's PKC,
but this acronym isn't expanded in the terminology section.


Nits/editorial comments:

Section 7.1:
   content type carried withing the ciphertext.
SHOULD BE:
   content type carried within the ciphertext.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art