Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08

[Nikos Mavrogiannopoulos <[e-mail]>]

On 5/10/06, [e-mail] <[e-mail]> wrote:

Hello Pasi,
 Thank you for the comments. I address them below.

> Somewhat substantive comments:
> 1) Section 3.3: The TLS Certificate message defined in RFC4346
>    contains a list of X.509 certificates, while this section allows
>    only a single PGPKey structure. IMHO we should keep this aligned

This was a deliberate change. The rationale behind this change was
that there is no point in sending more than one pgp keys. There is no
notion of certificate chain in openpgp, thus having a list of 
certificates would
confuse on what should be sent.

> 3) Section 3.4: I don't think there is any need to define a new
>    CertificateRequest message (the "certificate_authorities" part
>    doesn't make much sense for OpenPGP, but RFC4346 clarified that
>    it can be empty; and I believe many TLS 1.0 implementations also
>    did this). So I'd suggest rewriting this section as follows:
>    "If the certificate request message is sent, and the negotiated
>    certificate type is OpenPGP, the certificate_authorities list
>    MUST be empty."

I will address this.

> 4) I'd suggest moving whole Section 2 to later in the document
>    (e.g., after Security Considerations), renaming it to "IANA
>    Considerations", and rewriting it something like this:
>    "This document defines a new TLS extension, "cert_type", assigned
>    a value of TBD-BY-IANA (the value 7 is suggested) from the TLS
>    ExtensionType registry defined in [RFC4366].
>    This document establishes a new registry, to be maintained by
>    IANA, for TLS certificate types. Initially, the registry contains
>    the values 0 (X.509) and 1 (OpenPGP). Values from the range 2-223
>    are assigned via IETF Consensus [RFC2434]. Values from the range
>    224-255 are reserved for Private Use [RFC2434]."

Will be addressed.
(I just noticed that in http://www.iana.org/numbers.html there is 
nothing
about the TLS extension numbers. Is restristration possible?)

> 5) Section 3.1: "...extension SHOULD be omitted if the client only
>    supports X.509 certificates" and "Servers that only support X.509
>    certificates MAY omit... ": Unnecessary options are a recipe for
>    interoperability problems; unless there are good reasons to keep
>    these, I'd suggest changing these to MUSTs.

I agree for the first one. But the second is only to address the case 
where
the server doesn't support this extension (thus he doesn't add the
extension reply
to his hello). But I'd expect a server that is aware of this extension
to properly
reply with an extension that indicates that he selected the X509
certificate choice.


> 6) Section 4: I'd suggest merging this section (only four lines)
>    with Section 3.1. Also, the text should apply to all ciphersuites
>    using the RSA/DHE_DSS/DHE_RSA key exchange methods, not just
>    those in RFC 2246. (And with this change, the text about
>    exportable ciphersuites is no longer necessary.)

True. I'll update it.

> 9) Sections 3.6..3.8: I'd suggest removing these.
> 10) Section 3.3: "The process of fingerprint generation is described
>    in OpenPGP [2]": I'd suggest adding a more specific pointer:
>    Section 11.2 of [RFC2440].
> 11) Section 6.1: RFC 3546 is obsoleted by RFC 4366.
> 12) Section 6.1: Should include RFC 2119 and RFC 2434 here.
> 13) Section 6.2: Reference [5] is never cited in the text (and
>    IMHO could be removed)

Thanks I'll try to address the comments in a new draft.

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls