Skip to main content

The PKCS #11 URI Scheme
draft-pechanec-pkcs11uri-21

Revision differences

Document history

Date Rev. By Action
2015-04-22
21 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-04-13
21 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-03-30
21 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-03-02
21 Suresh Krishnan Request for Telechat review by GENART Completed: Ready. Reviewer: Suresh Krishnan.
2015-02-17
21 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-02-17
21 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2015-02-17
21 (System) IANA Action state changed to In Progress from Waiting on Authors
2015-02-17
21 (System) IANA Action state changed to Waiting on Authors from On Hold
2015-02-17
21 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-02-17
21 (System) RFC Editor state changed to EDIT
2015-02-17
21 (System) Announcement was received by RFC Editor
2015-02-16
21 (System) IANA Action state changed to On Hold from In Progress
2015-02-16
21 (System) IANA Action state changed to In Progress from Waiting on Authors
2015-02-16
21 (System) IANA Action state changed to Waiting on Authors
2015-02-13
21 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2015-02-13
21 Cindy Morgan IESG has approved the document
2015-02-13
21 Cindy Morgan Closed "Approve" ballot
2015-02-13
21 Cindy Morgan Ballot approval text was generated
2015-02-13
21 Cindy Morgan Ballot writeup was changed
2015-02-13
21 Jan Pechanec New version available: draft-pechanec-pkcs11uri-21.txt
2015-02-12
20 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to Yes from Discuss
2015-02-10
20 Pete Resnick
[Ballot comment]
I think what you have in 3.3 is reasonable, but I think the reader might get lost about which encoding to do. I …
[Ballot comment]
I think what you have in 3.3 is reasonable, but I think the reader might get lost about which encoding to do. I think you could clarify it a bit by simply repeating the bit about the "id" attribute in both places. Here's my suggestion:

OLD
  The PKCS#11 URI is a sequence of attribute value pairs separated by a
  semicolon that form a one level path component, optionally followed
  by a query.  In accordance with Section 2.5 of [RFC3986], the textual
  data SHOULD first be encoded as octets according to the UTF-8
  character encoding [RFC3629]; then only those octets that do not
  correspond to characters in the unreserved set or to permitted
  characters from the reserved set should be percent-encoded.  The only
  PKCS#11 URI attribute defined in this document which MAY contain non-
  textual data is the "id" attribute, as stated later in this section.
  When working with UTF-8 strings with characters outside the US-ASCII
  character sets, see important caveats in Section 3.5 and Section 6.
NEW
  The PKCS#11 URI is a sequence of attribute value pairs separated by a
  semicolon that form a one level path component, optionally followed
  by a query.  These attribute value pairs and query components (except
  for the value of the "id" attribute defined later in this section)
  are composed of entirely of textual data and therefore SHOULD all
  first be encoded as octets according to the UTF-8 character encoding
  [RFC3629], in accordance with Section 2.5 of [RFC3986]; then only
  those octets that do not correspond to characters in the unreserved
  set or to permitted characters from the reserved set should be
  percent-encoded.  (Because the value of the "id" attribute can
  contain non-textual data, it SHOULD NOT be encoded as UTF-8, but
  instead the entire value of the "id" component SHOULD be
  percent-encoded.) See important caveats in Section 3.5 and Section 6
  regarding working with UTF-8 strings containing characters outside
  the US-ASCII character set.

Then, below:

OLD
  The whole value of the "id" attribute SHOULD be percent-encoded since
  the corresponding PKCS#11 "CKA_ID" object attribute can contain
  arbitrary binary data.
NEW
  As stated earlier in this section, because the value of the "id"
  attribute can contain non-textual data, because the corresponding
  PKCS#11 "CKA_ID" object attribute can contain arbitrary binary data,
  the whole value of the "id" attribute SHOULD be percent-encoded.

It's a bit wordier, but the reader is far less likely to miss it when implementing. Entirely up to you whether to make the change; the specification as you have it is correct. Mine is only (hopefully) a clarification.

Thanks for addressing my other comments.
2015-02-10
20 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss
2015-02-05
20 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-02-05
20 Jan Pechanec IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-02-05
20 Jan Pechanec New version available: draft-pechanec-pkcs11uri-20.txt
2015-02-05
19 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2015-02-05
19 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-02-05
19 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-02-05
19 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-02-05
19 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-02-04
19 Kathleen Moriarty [Ballot comment]
Thanks for answering my questions on the PKCS#11 reference.
2015-02-04
19 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2015-02-04
19 Stephen Farrell
2015-02-04
19 Richard Barnes
[Ballot discuss]
(1) Section 3.3: Please define the PKCS#11 semantics of the various values of "pk11-type".  I assume that they map to CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, CKO_CERTIFICATE, …
[Ballot discuss]
(1) Section 3.3: Please define the PKCS#11 semantics of the various values of "pk11-type".  I assume that they map to CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, CKO_CERTIFICATE, CKO_SECRET_KEY, and CKO_DATA, but it would be better to be explicit.

(2) Section 3.4: The description of how to use pin-source here makes me uncomfortable.  It should be possible for an implementation to tell from the value of the parameter whether it can use it or not.  I would propose restricting this attribute to a URI or a "|command".  The local path option can be accommodated with a "file:" URI, and the vendor specific thing can be addressed with vendor specific query attributes.
2015-02-04
19 Richard Barnes
[Ballot comment]
I appreciate the spirit of this draft, and I think I might actually have an immediate use for it (configuring a CA).  In …
[Ballot comment]
I appreciate the spirit of this draft, and I think I might actually have an immediate use for it (configuring a CA).  In particular, the text on security of "pin-value" is brief but good.  There are several points, however, where this spec is unnecessarily restrictive or complex.

Section 3.3: "However, the PKCS#11 URI notation does not impose such limitations..."
It seems like what you're trying to do here is defer to PKCS#11.  I would suggest being a little stronger here, e.g., "The syntax of the PKCS#11 URI does not impose such limitations.  However if the consumer of a URI encounters values that would not be accepted by PKCS#11, it MUST consider the URI invalid."

Section 3.3: "depricated"

Section 3.3: "object ... "CKA_LABEL""
Why not use "label" for the attribute name here?

Section  3.3: "duplicate (vendor) attributes MAY be present"
Please clarify whether attributes defined in this specification MAY be duplicated.  It seems like it could be useful for some of them to be repeated.  For example, module-name / module-path could be used to enable a consumer to search multiple libraries for the desired token / object.

Section 3.4: "If a URI contains both "pin-source" and "pin-value" query attributes the URI SHOULD be refused as invalid."
Why does a URI with both "pin-source" and "pin-value" have to be invalid?  It seems like a consumer could try the provided PIN, and if that's invalid, try to use the PIN from "pin-source".

Section 3.4: "the URI consumer MAY refuse to accept either of the attributes"
Rejecting the URI seems unnecessarily intolerant.  Do you mean that implementations MAY ignore these attributes and fetch the module from elsewhere?  That seems like the more charitable thing to do.

Section 3.4: "a URI MUST NOT contain multiple module attributes of the same name."
As above, this seems unnecessarily strict.
2015-02-04
19 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2015-02-04
19 Pete Resnick
[Ballot discuss]
3.3:

  In accordance with Section 2.5 of [RFC3986], the data
  SHOULD first be encoded as octets according to the …
[Ballot discuss]
3.3:

  In accordance with Section 2.5 of [RFC3986], the data
  SHOULD first be encoded as octets according to the UTF-8 character
  encoding [RFC3629]; then only those octets that do not correspond to
  characters in the unreserved set or to permitted characters from the
  reserved set should be percent-encoded.  This specification suggests
  one allowable exception to that rule for the "id" attribute, as
  stated later in this section.
 
and later:

  The whole value of the "id" attribute SHOULD be percent-encoded since
  it is supposed to be handled as arbitrary binary data.

There's something weird here. If "id" is (or can be) arbitrary binary data, then encoding it "as octets according to the UTF-8 character encoding" and then percent encoding it is going to be a really bad idea. Seems to me that if it's arbitrary binary, you should encode the "id" in BASE64 or something first, or at least be clear in the above that only *textual* data is first encoded in UTF-8, and then percent-encode, except for "id" for which you should percent-encode everything. Is there any other non-textual data that might appear in this URI?

Further down:

  Note that if a URI does carry
  characters outside of the US-ASCII character set a conversion to an
  Internationalized Resource Identifier (IRI) defined in [RFC3987] may
  be considered.

As mentioned on the IETF list, please strike this sentence. The use of IRIs as protocol elements is recipe for disaster. I think we came to the conclusion long ago that if you are using something as a protocol element, it had better be a URI, and you had better percent-encode anything that was non-US-ASCII. Normalization is discussed quite reasonably in 3986; 3987 is unlikely to add anything useful, and 3987 is currently in a state of limbo anyway: We're waiting to see what W3C ends up recommending for HTML5, and the IETF is likely to end up referencing that in the long run and not 3987.

6. What is "form-insensitive Unicode string comparison"? I'm not familiar with that term.
2015-02-04
19 Pete Resnick
[Ballot comment]
3.4:

  An application MAY always ask for a PIN by any means it decides to.

Heh. That's not a protocol option. s/MAY/can. …
[Ballot comment]
3.4:

  An application MAY always ask for a PIN by any means it decides to.

Heh. That's not a protocol option. s/MAY/can. And it's probably the same later, but it may just be backwards:

OLD
  A consumer of PKCS#11 URIs MAY modify default settings for accessing
  a PKCS#11 provider or providers by accepting query component
  attributes "module-name" and "module-path"."
NEW
  A consumer of PKCS#11 URIs MAY accept query component attributes
  "module-name" and "module-path" in order to modify default settings
  for accessing a PKCS#11 provider or providers.

3.5:

  o  the consumer MUST know whether the URI is to identify PKCS#11
      storage object(s), token(s), slot(s), or Cryptoki producer(s).

s/MUST/needs to/ or simply re-work the sentence. I don't know how to implement a "know".

      The consumer SHOULD consider...

s/SHOULD/can/g  I don't know how to implement a "consider".
2015-02-04
19 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick
2015-02-04
19 Kathleen Moriarty
[Ballot discuss]
Hi,

Sorry I didn't think about this sooner, but the reference for PKCS#11 should be a pointer to the OASIS version as RSA …
[Ballot discuss]
Hi,

Sorry I didn't think about this sooner, but the reference for PKCS#11 should be a pointer to the OASIS version as RSA gave it to them March 2013.  I think the current final version is similar or just about the same as what RSA contributed from the TC committee page and they are close to publishing an update.  Here is a link to the committee page:
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=pkcs11

and the published version 2.30:
https://www.oasis-open.org/committees/document.php?document_id=48427

2.40 should be ready soon:
http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/

This is just a discuss as a placeholder in case a liaison statement is needed.  I have no objections to the draft being published.
2015-02-04
19 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2015-02-04
19 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-02-04
19 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-02-03
19 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2015-02-02
19 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-01-29
19 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2015-01-28
19 Jean Mahoney Request for Telechat review by GENART is assigned to Suresh Krishnan
2015-01-28
19 Jean Mahoney Request for Telechat review by GENART is assigned to Suresh Krishnan
2015-01-26
19 Barry Leiba
[Ballot comment]
In Section 4:

  An empty PKCS#11 URI might be useful to PKCS#11 consumers.  See
  Section 3.5 for more information on semantics …
[Ballot comment]
In Section 4:

  An empty PKCS#11 URI might be useful to PKCS#11 consumers.  See
  Section 3.5 for more information on semantics of such a URI.

I see nothing in Section 3.5 that gives any information about semantics of the URI "pkcs11:".  Can you quote it, so I can find it?
2015-01-26
19 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-01-26
19 Stephen Farrell Placed on agenda for telechat - 2015-02-05
2015-01-26
19 Stephen Farrell IESG state changed to IESG Evaluation from Waiting for Writeup
2015-01-26
19 Stephen Farrell Changed consensus to Yes from Unknown
2015-01-26
19 Stephen Farrell Ballot has been issued
2015-01-26
19 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2015-01-26
19 Stephen Farrell Created "Approve" ballot
2015-01-26
19 Stephen Farrell Ballot writeup was changed
2015-01-21
19 Pearl Liang IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2015-01-15
19 Jan Pechanec New version available: draft-pechanec-pkcs11uri-19.txt
2015-01-12
18 Jan Pechanec New version available: draft-pechanec-pkcs11uri-18.txt
2015-01-02
17 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Derek Atkins.
2014-12-31
17 Jan Pechanec IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2014-12-31
17 Jan Pechanec New version available: draft-pechanec-pkcs11uri-17.txt
2014-12-31
16 (System) IESG state changed to Waiting for Writeup from In Last Call
2014-12-22
16 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2014-12-22
16 Pearl Liang
IESG/Authors:

IANA has reviewed draft-pechanec-pkcs11uri-16.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as …
IESG/Authors:

IANA has reviewed draft-pechanec-pkcs11uri-16.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has a Note about the requested IANA action in this document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which needs to be completed.

The "pkcs11" URI scheme in the provisional tURI regsitry, located at:

http://www.iana.org/assignments/uri-schemes

is to be moved to the permanent URI scheme registry, also located at:

http://www.iana.org/assignments/uri-schemes

The registration template for the URI scheme is accessible on http://www.iana.org/assignments/uri-schemes.

IANA Note: As this document requests an action in an Expert Review (see
RFC 5226) registry, we will initiate the required Expert Review via
a separate request. Expert review will need to be completed before your
document can be approved for publication as an RFC.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.
2014-12-17
16 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Sarah Banks.
2014-12-05
16 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2014-12-05
16 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2014-12-04
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derek Atkins
2014-12-04
16 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derek Atkins
2014-12-04
16 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sarah Banks
2014-12-04
16 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Sarah Banks
2014-12-01
16 Cindy Morgan IANA Review state changed to IANA - Review Needed
2014-12-01
16 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The PKCS#11 URI Scheme) to Proposed …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The PKCS#11 URI Scheme) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'The PKCS#11 URI Scheme'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo specifies a PKCS#11 Uniform Resource Identifier (URI)
  Scheme for identifying PKCS#11 objects stored in PKCS#11 tokens, for
  identifying PKCS#11 tokens themselves, or for identifying PKCS#11
  libraries.  The URI is based on how PKCS#11 objects, tokens, and
  libraries are identified in the PKCS#11 Cryptographic Token Interface
  Standard.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-pechanec-pkcs11uri/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-pechanec-pkcs11uri/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-12-01
16 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-12-01
16 Stephen Farrell Last call was requested
2014-12-01
16 Stephen Farrell Last call announcement was generated
2014-12-01
16 Stephen Farrell Ballot approval text was generated
2014-12-01
16 Stephen Farrell Ballot writeup was generated
2014-12-01
16 Stephen Farrell IESG state changed to Last Call Requested from AD Evaluation
2014-12-01
16 Stephen Farrell IESG state changed to AD Evaluation from Publication Requested
2014-11-05
16 Amy Vezza
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.

There are already a number of applications that use the PKCS#11 URI scheme as
outlined in the draft.

No.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary

This draft defines a URI scheme for PKCS#11 objects, tokens, and libraries.

Working Group Summary

A PKCS#11 related draft, such as this, does not have a related WG now that the
PXIX WG has concluded.

Document Quality

There are several implementations of the specification.

The draft has been well vetted on the SAAG and URI-review lists.

The final request for review on 10/14/14 found no comments, good or bad.

Shepherd: Shawn Emery
Area Director (Security): Stephen Farrell

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The shepherd has reviewed multiple revisions of this draft since over a year
ago.  The shepherd believes that this revision (16) of the draft is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.  The draft has been reviewed by the security area and URI experts.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Yes.  The draft has had review from the URI-Review members.  SAAG members have
also reviewed the draft.  IANA has allocated a provisional registry for the
PKCS#11 URI.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns from the shepherd of this draft.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it?

Consensus is strong for this draft.  There have been several implementations
of the specified scheme and has been sent out for multiple reviews by the
affected communities with no dissenting opinions or concerns.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There is only one warning, which is a false-positive on IPv4 address formatting.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The draft has been reviewed multiple times on the URI-Review list.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

A provisional registry in IANA already exists based on this draft.  The intent
is to transition this to a permanent URI scheme registry when the draft becomes
an RFC.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The PKCS#11 URI scheme was reviewed by URI-Review members multiple times.

ABNF was checked and found two errors.  Changes to fix ABNF:

OLD:

  pk11-module-name    = "module-name" = *pk11-qchar
  pk11-module-path    = "module-path" = *pk11-qchar

NEW:

  pk11-module-name    = "module-name" "=" *pk11-qchar
  pk11-module-path    = "module-path" "=" *pk11-qchar

2014-11-05
16 Amy Vezza Notification list changed to Darren.Moffat@Oracle.COM, draft-pechanec-pkcs11uri.all@tools.ietf.org, Jan.Pechanec@Oracle.COM, "Shawn Emery" <shawn.emery@oracle.com> from Darren.Moffat@Oracle.COM, draft-pechanec-pkcs11uri.all@tools.ietf.org, Jan.Pechanec@Oracle.COM
2014-11-05
16 Amy Vezza Document shepherd changed to Shawn Emery
2014-11-05
16 Amy Vezza Intended Status changed to Proposed Standard
2014-11-05
16 Amy Vezza IESG process started in state Publication Requested
2014-11-05
16 Amy Vezza Stream changed to IETF from None
2014-10-13
16 Jan Pechanec New version available: draft-pechanec-pkcs11uri-16.txt
2014-09-25
15 Jan Pechanec New version available: draft-pechanec-pkcs11uri-15.txt
2014-07-21
14 Jan Pechanec New version available: draft-pechanec-pkcs11uri-14.txt
2013-09-29
13 Jan Pechanec New version available: draft-pechanec-pkcs11uri-13.txt
2013-07-29
12 Jan Pechanec New version available: draft-pechanec-pkcs11uri-12.txt
2013-07-09
11 Jan Pechanec New version available: draft-pechanec-pkcs11uri-11.txt
2013-05-14
10 Jan Pechanec New version available: draft-pechanec-pkcs11uri-10.txt
2013-03-21
09 Jan Pechanec New version available: draft-pechanec-pkcs11uri-09.txt
2013-01-26
08 Jan Pechanec New version available: draft-pechanec-pkcs11uri-08.txt
2012-12-25
07 Jan Pechanec New version available: draft-pechanec-pkcs11uri-07.txt
2012-02-28
06 Jan Pechanec New version available: draft-pechanec-pkcs11uri-06.txt
2012-02-09
05 (System) Document has expired
2011-08-08
05 (System) New version available: draft-pechanec-pkcs11uri-05.txt
2011-05-02
04 (System) New version available: draft-pechanec-pkcs11uri-04.txt
2010-11-08
03 (System) New version available: draft-pechanec-pkcs11uri-03.txt
2010-08-20
02 (System) New version available: draft-pechanec-pkcs11uri-02.txt
2010-03-22
01 (System) New version available: draft-pechanec-pkcs11uri-01.txt
2010-03-01
00 (System) New version available: draft-pechanec-pkcs11uri-00.txt