Skip to main content

X.509 Certificate General-Purpose Extended Key Usage (EKU) for Document Signing
draft-ietf-lamps-documentsigning-eku-06

Yes

Roman Danyliw
Éric Vyncke

No Objection

Alvaro Retana
Andrew Alston
John Scudder
Robert Wilton
Warren Kumari
Zaheduzzaman Sarker

Note: This ballot was opened for revision 04 and is now closed.

Paul Wouters
Yes
Comment (2022-08-23 for -05)
# Security AD comments for {draft-ietf-lamps-documentsigning-eku-04}
CC @paulwouters

## Comments:

### humans

   The term "Document Signing" in this document refers to digitally
   signing contents that are consumed by people.  To be more precise,
   contents are intended to be shown to a person with printable or
   displayable form by means of services or software, rather than
   processed by machines.

Is there a reason to only include human readers and not machines? Why not
leave it to users to decide how to use this?

### key usage vs KU

   The EKU extension can be used in conjunction with the key usage extension

Would it make sense to call that the KU extension, or key usage (KU) extension

### Section 4 humans again

   The signed contents of Internet-Drafts are primarily intended to be
   consumed by people.

### RFCs is people?

What is this "signed contents of Internet-Drafts" ? Should that be "signed
contents of Documents" ?

### single example?

   When a single application has the capability to process various data
   formats, the software may choose to make the excluded and permitted
   decisions separately in accordance with the format it is handling
   (e.g. text, pdf, etc).

Why is this text in the document? It seems kinda out of scope.

### Section 6 allows squatting?

   This general
   document signing KeyPurposeId may be used as a stop-gap for those
   that intend to define their own KeyPurposeId

It seems weird for this document to say "this is for document signing, but hey
go squat on this value for other uses if that's convenient".


## NITS

### Section 1

[RFC5280]  is a broken link

I can't parse: the usage can easily become out of control.

weird use of "-" in:  use. - If the

Paragraph 3 in Section 1 is in its entirety hard to parse.

### Section 3

[RFC5280] is a broken link
Roman Danyliw
Yes
Éric Vyncke
Yes
Alvaro Retana
No Objection
Andrew Alston
No Objection
Erik Kline
No Objection
Comment (2022-08-19 for -04)
# Internet AD comments for {draft-ietf-lamps-documentsigning-eku-04}
CC @ekline

## Comments

### S3,4

* Given that documents may be presented to people "by means of ... software"
  perhaps a slight tweak to the "rather than processed by machines", e.g.:

    - "rather than processed primarily by machines", or
    - "rather than processed principally by machines"

## Nits

### S4

* s/instead of single/instead of a single/

* s/proresses/processes/ I think?
John Scudder
No Objection
Lars Eggert
No Objection
Comment (2022-08-23 for -05)
# GEN AD review of draft-ietf-lamps-documentsigning-eku-05

CC @larseggert

Thanks to Dale Worley for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/1T23l8-kN8pEMqnQvh1ir3MsGVw).

## Comments

### Section 4, paragraph 1
```
     The signed contents of Internet-Drafts are primarily intended to be
```
Did you mean "documents" here instead of "Internet-Drafts"?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 3
```
-    owner but by another vendor, the vender who own the KeyPurposeIds may
-                                         ^
-    not able to control use, or even do not know about the use. - If the
-                                                                -
+    owner but by another vendor, the vendor who own the KeyPurposeIds may
+                                         ^
```

#### Section 4, paragraph 5
```
-       party software proresses each restriction on "Excluded
-                         ^
+       party software processes each restriction on "Excluded
+                         ^
```

### Grammar/style

#### Section 4, paragraph 8
```
the format it is handling (e.g. text, pdf, etc). 5. Implications for a Certif
                                      ^^^
```
File types are normally capitalized.

#### Section 4, paragraph 8
```
ormat it is handling (e.g. text, pdf, etc). 5. Implications for a Certificati
                                      ^^^
```
A period is needed after the abbreviation "etc.".

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
Murray Kucherawy
No Objection
Comment (2022-08-25 for -05)
Section 7 as worded is a little confusing, though I managed to figure out what it's trying to say.  I suggest it get a once-over before it goes on to the RFC Editor.  If you need some suggested text, I'd be happy to provide some.
Robert Wilton
No Objection
Warren Kumari
No Objection
Zaheduzzaman Sarker
No Objection