Identity-Based Encryption Architecture and Supporting Data Structures
RFC 5408

[Ballot comment]
My DISCUSS previously pointed out problems with the lack of clear requirements for HTTP.  Because no mention is made of a requirement to support all of HTTP, and individual features aren't mentioned, it is likely that the first implementations will dictate the subset of interoperable features.  E.g. if the first implementations use redirects, then redirects will become an interoperable HTTP feature in this application; if the first implementations do not, then redirects will be unusable.

Since this is now Informational, I am not holding the document for this concern.

IANA 2nd Last Call comments:

ACTION 1:

Upon approval, IANA will register the following media types at
http://www.iana.org/assignments/media-types/application/:

application/ibe-pp-data
application/ibe-key-request+xml
application/ibe-pkg-reply+xml


ACTION 2:

Upon approval, IANA will add the following to the XML ns
registry at http://www.iana.org/assignments/xml-registry/ns.html:

urn:ietf:params:xml:ns:ibe

Registrant Contact:

Luther Martin
Voltage Security
1070 Arastradero Rd Suite 100
Palo Alto CA 94304

Phone: +1 650 543 1280
Email: martin@voltage.com

XML:
BEGIN







algorithmOID


ibeIdentityInfo



ibeAuthData







bodyTags


END


We understand the above to be the only IANA actions for this
document.

[Ballot discuss]
[picking up Sam's discuss]

How does a key server know whether a user is authorized to use a
particular identity address?  One solution is to do as Chris suggests
and to use 2821 addresses.  Another solution might be to require that
the PKG is built into the internal email infrastructure somehow and
can determine whether a given email address would be delivered to a
given mail box  and require the same authentication for that mailbox.

I find the use of application/octet-stream and the use of xhtml
completely inappropriate in sections 3 and 4.

According to the protocol public parameters are needed to decrypt the
message.  How does this work when you try to decrypt a historic
message?  What if the public parameters have changed?  (Note that this
document requires both senders and recipients to fetch public
parameters) How does this interact with the requirement in section 3
that public parameters not be used outside their validity time?


How is interoperability achieved if implementations "MAY REQUIRE"
certain extensions to function?  Shouldn't we require that
implementations have a mode that works with no extensions?

How do you know what district to use for a given email address?  How
do you know where to find the parameters?  How do you authenticate
that a given public parameters server is allowed to speak for a given
district?

[Ballot discuss]
These things are all small and can likely be easily resolved.

Section 4.3: I assume the ibe:algorithmOID needs to be base64 encoded - I don't think it says this

In section 4.5, I got confused by value="responseCode" in the XML. I could not decide if the responseCode would be replaced by 100, or by KEY_FOLLOWS. I can seen in a later example what it needs to be but if you could find a way to make this clear in a normative sort of way, I think it would eliminate any implementers being confused on this.

In section 4.7, this seems under specified. Once you get the enrollment URI, then what?

In section 7, XML section. I don't think this is the XML you want. Check out some of the other examples at http://www.iana.org/assignments/xml-registry/ns.html

[Ballot discuss]
I support Chris, Lisa and Cullen's discusses.

How does a key server know whether a user is authorized to use a
particular identity address?  One solution is to do as Chris suggests
and to use 2821 addresses.  Another solution might be to require that
the PKG is built into the internal email infrastructure somehow and
can determine whether a given email address would be delivered to a
given mail box  and require the same authentication for that mailbox.

I find the use of application/octet-stream and the use of xhtml
completely inappropriate in sections 3 and 4.

According to the protocol public parameters are needed to decrypt the
message.  How does this work when you try to decrypt a historic
message?  What if the public parameters have changed?  (Note that this
document requires both senders and recipients to fetch public
parameters) How does this interact with the requirement in section 3
that public parameters not be used outside their validity time?


How is interoperability achieved if implementations "MAY REQUIRE"
certain extensions to function?  Shouldn't we require that
implementations have a mode that works with no extensions?




How do you know what district to use for a given email address?  How
do you know where to find the parameters?  How do you authenticate
that a given public parameters server is allowed to speak for a given
district?

[Ballot discuss]
The email address used for identity should be a minimal-form RFC 2821
address with the domain name mapped to lower case, not an RFC 2822
address.  RFC 2822 allows arbitrary comments and folding whitespace in
the address.  Both forms allow quoting and mixed-case domain names.

A discussion of whether ACE-encoded or UTF-8 encoded domain names are
used in the canonical format is needed (refer to IDN).

The "GeneralizedTime" ASN.1 syntax element permits "local time",
a time without any zone referent so it doesn't interoperate.  It should
be mandatory to either include a UTC offset or use UTC.  See RFC 3339
section 4.4 for further discussion.

This document needs to discuss the issues raised by BCP #56.  In
particular, the fact this protocol masquerades as a regular XHTML
post + XHTML response with the actual protocol buried inside the XHTML
is a design I consider to be exceptionally dangerous and harmful to
the Internet as it encourages firewalls and other middle-boxes to
parse deep into the application protocol exchange and likely cause
severe damage.  The lower down the protocol stack you can distinguish
this protocol from browser-use-of-HTTP the better, IMHO.  A separate
port is my preferred design, but I can live with a separate media type
or new method.

ASN.1, XML and XHTML have security considerations this inherits, please
reference them.

I support Lisa's discuss.

[Ballot discuss]
I support Chris, Lisa and Cullen's discusses.

How does a key server know whether a user is authorized to use a
particular identity address?  One solution is to do as Chris suggests
and to use 2821 addresses.  Another solution might be to require that
the PKG is built into the internal email infrastructure somehow and
can determine whether a given email address would be delivered to a
given mail box  and require the same authentication for that mailbox.

I find the use of application/octet-stream and the use of xhtml
completely inappropriate in sections 3 and 4.

According to the protocol public parameters are needed to decrypt the
message.  How does this work when you try to decrypt a historic
message?  What if the public parameters have changed?  (Note that this
document requires both senders and recipients to fetch public
parameters) How does this interact with the requirement in section 3
that public parameters not be used outside their validity time?


How is interoperability achieved if implementations "MAY REQUIRE"
certain extensions to function?  Shouldn't we require that
implementations have a mode that works with no extensions?

There is no criticality indicator for extensions.  What should an
implement do if it receives unknown extensions?



How do you know what district to use for a given email address?  How
do you know where to find the parameters?  How do you authenticate
that a given public parameters server is allowed to speak for a given
district?


This specification has a different authentication infrastructure than
IMAP, POP and SMTP (the email protocols).  Has the S/MIME working
group discussed their choice not to support the same authentication as
email with the apps area?  Why is this the correct direction for the
Internet?

This document needs to be last called again; it has an informational
reference to the IBE crypto algorithms that is a down reference.  That
down reference was not noted in the last call per RFC 3967.

[Ballot discuss]
I support Chris, Lisa and Cullen's discusses.

How does a key server know whether a user is authorized to user a
particular identity address?  One solution is to do as Chris suggests
and to use 2821 addresses.  Another solution might be to require that
the PKG is built into the internal email infrastructure somehow and
can determine whether a given email address would be delivered to a
given mail box  and require the same authentication for that mailbox.

I find the use of application/octet-stream and the use of xhtml
completely inappropriate in sections 3 and 4.

According to the protocol public parameters are needed to decrypt the
message.  How does this work when you try to decrypt a historic
message?  What if the public parameters have changed?  (Note that this
document requires both senders and recipients to fetch public
parameters) How does this interact with the requirement in section 3
that public parameters not be used outside their validity time?


How is interoperability achieved if implementations "MAY REQUIRE"
certain extensions to function?  Shouldn't we require that
implementations have a mode that works with no extensions?

There is no criticality indicator for extensions.  What should an
implement do if it receives unknown extensions?



How do you know what district to use for a given email address?  How
do you know where to find the parameters?  How do you authenticate
that a given public parameters server is allowed to speak for a given
district?


This specification has a different authentication infrastructure than
IMAP, POP and SMTP (the email protocols).  Has the S/MIME working
group discussed their choice not to support the same authentication as
email with the apps area?  Why is this the correct direction for the
Internet?

[Ballot discuss]
The email address used for identity should be a minimal-form RFC 2821
address with the domain name mapped to lower case, not an RFC 2822
address.  RFC 2822 allows arbitrary comments and folding whitespace in
the address.  Both forms allow quoting and mixed-case domain names.

A discussion of whether ACE-encoded or UTF-8 encoded domain names are
used in the canonical format is needed (refer to IDN).

The "GeneralizedTime" ASN.1 syntax element permits "local time",
a time without any zone referent so it doesn't interoperate.  It should
be mandatory to either include a UTC offset or use UTC.  See RFC 3339
section 4.4 for further discussion.

The protocol's use of TLS section is incomplete.  Correctly applying TLS
to an application protocol requires discussion of all sorts of things
including: which mandatory-to-implement cipher suite is used by that
protocol (if not the same as TLS base spec's DSA+3DES), if subjectAlt
name of dnsName is recommended, what sort of configuration knobs with
authentication is needed, etc.  See RFC 4513 for a good example.

This document needs to discuss the issues raised by BCP #56.  In
particular, the fact this protocol masquerades as a regular XHTML
post + XHTML response with the actual protocol buried inside the XHTML
is a design I consider to be exceptionally dangerous and harmful to
the Internet as it encourages firewalls and other middle-boxes to
parse deep into the application protocol exchange and likely cause
severe damage.  The lower down the protocol stack you can distinguish
this protocol from browser-use-of-HTTP the better, IMHO.  A separate
port is my preferred design, but I can live with a separate media type
or new method.

ASN.1 has serious security considerations that have resulted
in many real-world vulnerabilities in security software.  Specifically,
the nested lengths in ASN.1 can be inconsistent so ASN.1 parsers must
be prepared for such inconsistencies that might result in buffer
overflows or lengths that would cause a DOS if allocated.  This document
fails to discuss or reference ASN.1 security considerations.

XML also has security considerations, as does XHTML.

I support Lisa's discuss.

[Ballot discuss]
This specification indicates the use of HTTP GET and POST without clarifying what level of HTTP support is required of clients and servers.  (Can servers expect to use 100 or 300 level responses and have clients handle them?  Can clients use conditional request headers and have servers handle them?  there's another dozen issues like this.)

The use of three-digit response codes within HTTP responses, that are different from HTTP status codes, is confusing. 
        100  KEY_FOLLOWS
        101  RESERVED
        201  FOLLOW_ENROLL_URI
        300  SYSTEM_ERROR
        301  INVALID_REQUEST
        303  CLIENT_OBSOLETE
        304  AUTHORIZATION DENIED

What HTTP status code should be used in the first line of the response, when the body contains an IBE error, is not clear.

There are no examples of error responses.

[Ballot discuss]
The title of this document concerns me.  The document provides some
  overview of IBE, and then it defines some data structures.  These
  data structures are important to apply IBE to CMS or other protocol
  environments.  These data structures are the reason that the document
  is on the standards track.  The title of the document should reflect
  the reason that these data structures are needed, and it should
  highlight the use of trusted third party servers.

[Ballot comment]
The XML would be clearer with a RelaxNG schema. I really encourage people to consider adding some schema.

A full example test message would really help implementers get this right.

[Ballot discuss]
These things are all small and can likely be easily resolved. It may just be my lack on understanding.

Section 4.3: I assume the ibe:algorithmOID needs to be base64 encoded - I don't think it says this

In section 4.5, I got confused by value="responseCode" in the XML. I could not decide if the responseCode would be replaced by 100, or by KEY_FOLLOWS. I can seen in a later example what it needs to be but if you could find a way to make this clear in a normative sort of way, I think it would eliminate any implementers being confused on this.

In section 4.7, I don't really see how this works. Once you get the enrollment URI, then what?

In section 7, XML section. I don't think this is the XML you want. Check out some of the other examples at http://www.iana.org/assignments/xml-registry/ns.html

Revised IANA comments:

Upon approval of this document, the IANA will make the following
assignments in the "NS" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID |URI |Registration template |Reference
ibe urn:ietf:params:xml:ns:ibe | ibe | [RFC-ietf-smime-ibearch-06.txt]

Registration template:

        URI:

        urn:ietf:params:xml:ns:ibe

        Registrant Contact:

          Luther Martin
          Voltage Security
          1070 Arastradero Rd Suite 100
          Palo Alto CA 94304
           
          Phone: +1 650 543 1280
          Email: martin@voltage.com 
       
        XML:
        BEGIN
       
           
             
           
           
           
             
                algorithmOID 
             
             
              ibeIdentityInfo 
             
           
           
       
       
       
           
           
              bodyTags
           
       
        END


We understand the above to be the only IANA Actions for this
document.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "NS" registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID |URI |Registration template |Reference
ibe urn:ietf:params:xml:ns:ibe | ibe | [RFC-smime-ibearch-05]

As the document does not include a registration template, IANA
proposes the following text:

Registration request for the IBE namespace

URI: urn:ietf:params:xml:ns:ibe

Specification: [RFC-smime-ibearch-05]

Registrant Contact:

IETF
SMIME Working Group


XML: none

We understand the above to be the only IANA Actions for this
document.

If the proposed template is incorrect, please let us know.

raft-ietf-smime-ibearch-05 is ready for IETF-wide last call. Below find the
Document Shepherd writeup.

Answering questions 1.a-1.h in RFC 4858:

1.a - Blake Ramsdell is the Shepherd. He's personally reviewed the document
      and knows it is ready for IESG publication.

1.b - This document has been reviewed deeply by at least one WG member.

1.c - There is no need for broader review.

1.d - There are no specific concerns that the AD and/or IESG should be aware
      of.

1.e - The WG was relatively quiet about this document.

1.f - There has been no threat of an appeal.

1.g - The nits have been addressed.

1.h - The document splits it references.

1.i - The document has an IANA consideration and it is consistent with the
      main body. A reservation is requested in the IETF XML registry.

1.j - The reviewer has NOT personally verified the XML IANA registration or
      the ASN.1. I know that there was at least one reviewer of the ASN.1 in
      the WG.

1.k - Write-up is as follows:

Technical Summary

This document describes the security architecture required to implement
identity-based encryption, a public-key encryption technology that uses a
user's identity to generate their public key.

Working Group Summary

There was very little public discussion about this draft. During WG last call
comments were raised and addressed, and after last call some nits were
addressed.

Document Quality

I know that there is at least one implementation by Voltage of this protocol.
I am not aware of other vendor plans for implementation.

Personnel

Blake Ramsdell  is the document Shepherd. Tim Polk
is the responsible Security Area AD.

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com