Subject: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05

From: Alexey Melnikov <[email-masked]>
Date: Sat, 14 Jan 2012 20:45:41 +0000

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-mile-rfc6046-bis-05
Reviewer: Alexey Melnikov
Review Date: 2012–01–14
IETF LC End Date: 2012-01-17
IESG Telechat date: 2012-01-19

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

Major issues:

In Section 3:

    The RID callback MUST contain a zero-length entity body
    and a 'RID-Callback-Token' entity header

[Minor issue] "header" --> "header field" (header is the collection of 
all header fields).

    , itself containing a unique
    token generated by the receiving RID system.

I am missing ABNF for the new header field.

    RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
    authentication for transport confidentiality, identification, and

Do you mean that a RID client must use X.509 certificates?

    authentication, as in [RFC2818].

I find the whole sentence to be confusing. Note that the rules of RFC 
6125 for certificate verification are stricter than in RFC 2818 and this 
sentence can be read as conflicting with the paragraph below which 
requires use of RFC 6125. What are you trying to say here?

    RID systems MUST provide for the verification of the identity of a
    RID system peer presenting a valid and trusted certificate, by
    verifying the fully-qualified domain name and service name from the
    DNS SRV record, if available, against that stored in the certificate,

I am confused: this is the first time DNS SRV records are mentioned
(BTW, they need a Normative Reference). Earlier text seem to suggest 
that DNS SRV are not used to locate protocol endpoints. If RID is using 
DNS SRV, then information about how it is used is missing from the document.

    as in Section 6 of [RFC6125].

RFC 6125 allows for various options and this paragraph doesn't seem to 
cover all of them. I suggest you check Section 13.7.1.2.1 of RFC 6120 
for an example of what should be specified (ignore XmppAddr identifier 
type, as it is very XMPP specific). For X.509 SANs which are disallowed, 
you should say so.

Minor issues: (ones issue listed above)

Nits/editorial comments: None

---

From: Brian Trammell <[email-masked]>
Date: Tue, 17 Jan 2012 11:16:47 +0100

Hi, Alexey,

Thanks for the review; questions and comments thereon inline...

On Jan 14, 2012, at 9:45 PM, Alexey Melnikov 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.
> 
> Summary: This draft is almost ready for publication as a Proposed Standard RFC.
> 
> 
> Major issues:
> 
> In Section 3:
> 
> [Minor issue] "header" --> "header field" (header is the collection of all header fields).
> 

Seems a little superfluous... it's an opaque string, but I suppose we should point out it doesn't contain \r or \n... Will add.

> Do you mean that a RID client must use X.509 certificates?

Well, each RID system (HTTP client or server) is identified by an X.509 certificate (hence "mutual"); how can I make this clearer?

> I find the whole sentence to be confusing. Note that the rules of RFC 6125 for certificate verification are stricter than in RFC 2818 and this sentence can be read as conflicting with the paragraph below which requires use of RFC 6125. What are you trying to say here?

The intention here is "Use current best practices as would be supported by off-the-shelf HTTP/1.1 and TLS 1.1 implementations to provide mutual authentication." "Current best practices", however, seems to be something of a moving target.

I cite 2818 as it is the current binding between HTTP/1.1 and TLS. I cite 6125 solely for certificate verification. 

> (BTW, they need a Normative Reference). Earlier text seem to suggest that DNS SRV are not used to locate protocol endpoints. If RID is using DNS SRV, then information about how it is used is missing from the document.

It doesn't. Was trying to point out here that SRV must be matched if (for deployment-specific reasons) it was present. This is simply a poor attempt at citing 6125.

> RFC 6125 allows for various options and this paragraph doesn't seem to cover all of them. I suggest you check Section 13.7.1.2.1 of RFC 6120 for an example of what should be specified (ignore XmppAddr identifier type, as it is very XMPP specific). For X.509 SANs which are disallowed, you should say so.

Will do. (6125 is missing something here, a guide for using it in other specs...)

Best regards,

Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Jan 2012 14:38:18 +0000

On 17/01/2012 10:16, Brian Trammell 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>.
>>
> Seems a little superfluous... it's an opaque string, but I suppose we should point out it doesn't contain \r or \n...
Saying it is an opaque string is Ok, but you don't even specify which 
characters are allowed in it.
>   Will add.
Thanks.
> I cite 2818 as it is the current binding between HTTP/1.1 and TLS. I cite 6125 solely for certificate verification.
How about something like this:

OLD:

NEW:
   RID systems MUST use HTTP over TLS as specified in [RFC2818], with 
the exception
   of server TLS identity verification which is detailed below.
   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   X.509 authentication. TLS provides for transport confidentiality,
   identification, and authentication.
> It doesn't. Was trying to point out here that SRV must be matched if (for deployment-specific reasons) it was present. This is simply a poor attempt at citing 6125.
SRV-ID are really only applicable to protocols which are using DNS SRV. 
So I would have prohibited them... But if you want to keep using them, 
you need to specify what is the service name you would expect in them.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 18 Jan 2012 17:16:20 +0100

On Jan 18, 2012, at 3:38 PM, Alexey Melnikov wrote:

> Saying it is an opaque string is Ok, but you don't even specify which characters are allowed in it.
>>  Will add.
> Thanks.

Hm. Good point; also didn't mention a maximum length. Fixed in -07, defined as 1*255(VCHAR).

>  RID systems MUST use HTTP over TLS as specified in [RFC2818], with the exception

Ah. Okay, now I understand the issue... 

>  identification, and authentication.

The language has changed in -07 to the following; would this be acceptable?

   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   authentication for confidentiality, identification, and
   authentication, as in [RFC2818], when transporting RID messages over
   HTTPS.  RID systems MUST use mutual authentication; that is, both RID
   systems acting as HTTPS clients and RID systems acting as HTTPS
   servers MUST be identified by an X.509 certificate [RFC5280].  Mutual
   authentication requires full path validation on each certificate, as
   defined in [RFC5280].

> SRV-ID are really only applicable to protocols which are using DNS SRV. So I would have prohibited them... But if you want to keep using them, you need to specify what is the service name you would expect in them.

Indeed. We don't, so, removed. Thanks for the clarification.

Actually, since the binding between RID and a PKI is better defined in rfc6045-bis, 6046-bis now refers to it, as follows:

   Each RID system SHOULD authenticate its peers via a PKI as detailed
   in Section 9.3 of [I-D.ietf-mile-rfc6045-bis].

Would this address the concern?

Many thanks, best regards,

Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Jan 2012 17:43:58 +0000

Hi Brian,

> Hm. Good point; also didn't mention a maximum length. Fixed in -07, defined as 1*255(VCHAR).
I think this issue is resolved.
> Ah. Okay, now I understand the issue...
This is only one of them...
>     authentication, as in [RFC2818],
Part of the issue with this text is that reads as if "mutual 
authentication" results in "confidentiality, identification and 
authentication". TLS does, that is why I split the sentence into 
multiple. Also RFC 2818 is a wrong reference because it doesn't even 
mention confidentiality.
I am hoping this is not nitpicking, but I think using simpler sentences 
clearer.
> when transporting RID messages over
>     HTTPS.
The rest looks good to me:
> RID systems MUST use mutual authentication; that is, both RID
Let me check.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 18 Jan 2012 18:01:40 +0000

>> On Jan 18, 2012, at 3:38 PM, Alexey Melnikov wrote:
  [...]
>>>>> (BTW, they need a Normative Reference). Earlier text seem to 
>>>>> suggest that DNS SRV are not used to locate protocol endpoints. If 
>>>>> RID is using DNS SRV, then information about how it is used is 
>>>>> missing from the document.
>>>> It doesn't. Was trying to point out here that SRV must be matched 
>>>> if (for deployment-specific reasons) it was present. This is simply 
>>>> a poor attempt at citing 6125.
>>> SRV-ID are really only applicable to protocols which are using DNS 
>>> SRV. So I would have prohibited them... But if you want to keep 
>>> using them, you need to specify what is the service name you would 
>>> expect in them.
>> Actually, since the binding between RID and a PKI is better defined 
>> in rfc6045-bis, 6046-bis now refers to it, as follows:
>>

So the text in rfc6045bis seems to suggest that all server certificates 
will be verified based on some prior arrangement. Is my understanding 
correct?

>>>>> RFC 6125 allows for various options and this paragraph doesn't 
>>>>> seem to cover all of them. I suggest you check Section 13.7.1.2.1 
>>>>> of RFC 6120 for an example of what should be specified (ignore 
>>>>> XmppAddr identifier type, as it is very XMPP specific). For X.509 
>>>>> SANs which are disallowed, you should say so.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jan 2012 10:45:34 +0100

Hi Alexey,

Thanks for helping me work through these... one more round on open issues, inline below:

On Jan 18, 2012, at 6:43 PM, Alexey Melnikov wrote:

> Part of the issue with this text is that reads as if "mutual authentication" results in "confidentiality, identification and authentication". TLS does, that is why I split the sentence into multiple. Also RFC 2818 is a wrong reference because it doesn't even mention confidentiality.
> I am hoping this is not nitpicking, but I think using simpler sentences clearer.

Absolutely.

>>    authentication requires full path validation on each certificate, as

So, how about the following:

   RID systems MUST use TLS version 1.1 [RFC4346] or higher for
   confidentiality, identification, and authentication, as in 
   Section 2 of [RFC2818]. RID systems MUST use mutual authentication; 
   that is, both RID systems acting as HTTPS clients and RID systems 
   acting as HTTPS servers MUST be identified by an X.509 certificate 
   [RFC5280].  Mutual authentication requires full path validation on 
   each certificate, as defined in [RFC5280].

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jan 2012 10:48:19 +0100

On Jan 18, 2012, at 7:01 PM, Alexey Melnikov wrote:

> So the text in rfc6045bis seems to suggest that all server certificates will be verified based on some prior arrangement. Is my understanding correct?

Yes; in essence, a RID consortium is "closed".

Cheers,

Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Jan 2012 12:07:41 +0000

Hi Brian,
>     Section 2 of [RFC2818].
I am Ok with your latest proposal, but if you want to make me 
super-happy ;-), I suggest you make "as in Section 2 ..." a separate 
sentence (E.g. "Use of HTTP over TLS is specified in Section 2...", or 
at least insert the word "specified" after "as".
> RID systems MUST use mutual authentication;
Thanks for working with me on this.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jan 2012 13:45:58 +0100

On Jan 19, 2012, at 1:07 PM, Alexey Melnikov wrote:

> I am Ok with your latest proposal, but if you want to make me super-happy ;-), I suggest you make "as in Section 2 ..." a separate sentence (E.g. "Use of HTTP over TLS is specified in Section 2...", or at least insert the word "specified" after "as".

Hi, Alexey,

I can do that:

    <t>RID systems MUST use TLS version 1.1 <xref target="RFC4346"/> or higher
    for confidentiality, identification, and authentication, when sending RID
    messages over HTTPS. HTTPS is specified in Section 2 of <xref
    target="RFC2818"/>. RID systems MUST use mutual authentication; that is,
    both RID systems acting as HTTPS clients and RID systems acting as HTTPS
    servers MUST be identified by an <xref target="RFC5280">X.509
    certificate</xref>. Mutual authentication requires full path validation on
    each certificate, as defined in <xref target="RFC5280"/>.</t>

Cheers,

Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Jan 2012 13:07:14 +0000

On 19/01/2012 12:45, Brian Trammell wrote:
>      <t>RID systems MUST use TLS version 1.1<xref target="RFC4346"/>  or higher
>      messages over HTTPS. HTTPS is specified in Section 2 of<xref
>      servers MUST be identified by an<xref target="RFC5280">X.509
>      each certificate, as defined in<xref target="RFC5280"/>.</t>
Perfect, thanks :-).

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Jan 2012 17:32:01 +0000

Hi Brian,

> Yes; in essence, a RID consortium is "closed".
I think that this approach is unwise, because this wouldn't scale. But 
if nobody else see a problem with this, I will let it go.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Jan 2012 12:34:35 -0700

On 1/19/12 10:32 AM, Alexey Melnikov wrote:
>>> So the text in rfc6045bis seems to suggest that all server
>>> certificates will be verified based on some prior arrangement. Is my
>>> understanding correct?

I have a problem with it.

Version -05 said:

   Each RID consortium SHOULD use a trusted public key infrastructure
   (PKI) to manage identities for RID systems participating in TLS
   connections.  At minimum, each RID system MUST trust a set of X.509
   Issuer identities ("Certificate Authorities") [RFC5280] to directly
   authenticate RID system peers with which it is willing to exchange
   information, and/or a specific white list of X.509 Subject identities
   of RID system peers.

In version -06, that was replaced with:

As far as I can see, a RID system is not the same as a RID consortium.
Even if every RID system is a member of such a consortium, it seems like
a bad idea to leave the authentication rules up to the consortium,
without providing any sort of guidance. Version -05 at least pointed to
RFC 6125. Since 6046bis is the HTTPS/TLS binding only, it might be more
appropriate to point to RFC 2818 here instead of RFC 6125, but I think
we need to say *something* about how authentication works (matching of
endpoint identities and such) instead of hoping that consortia get the
security right.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jan 2012 23:05:45 +0100

Hi, Peter, Alexey, all,

> endpoint identities and such) instead of hoping that consortia get the

Okay; how about the following (including Alexey's comments from the previous review, and pointing more specifically to 6125)

    <t>RID systems MUST verify the identity of their peers against that stored
    in the certificate presented, as in section 6 of <xref target="rfc6125"/>.
    As RID systems are identified not by URI and RID does not use DNS SRV
    records, they are identified solely by their DNS Domain Names; see Section
    6.4 of <xref target="rfc6125"/>. General information on the use of PKI
    with RID systems is detailed in Section 9.3 of <xref
    target="I-D.ietf-mile-rfc6045-bis"/>.</t>

Cheers,

Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Jan 2012 13:19:22 +0000

Hi Brian,
>      in the certificate presented, as in section 6 of<xref target="rfc6125"/>.
>      6.4 of<xref target="rfc6125"/>.
(I think you are saying that [using RFC 6125 terminology] DNS-IDs are 
supported, but SRV-IDs or URI-IDs aren't.)

This is better, but I think you need to say a bit more. Are CN-IDs 
allowed? Are wildcards allowed?

Another example of the document that describes
http://tools.ietf.org/html/draft-melnikov-email-tls-certs-00

> General information on the use of PKI
>      with RID systems is detailed in Section 9.3 of<xref

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Jan 2012 15:22:36 +0100

Hi, Alexey,

one more round (hopefully) :) ...

On Jan 23, 2012, at 2:19 PM, Alexey Melnikov wrote:

> (I think you are saying that [using RFC 6125 terminology] DNS-IDs are supported, but SRV-IDs or URI-IDs aren't.)

I can say that directly then.

> This is better, but I think you need to say a bit more. Are CN-IDs allowed? Are wildcards allowed?

Here, I'm a little unclear on the implications this has for implementation: is it reasonable to assume that all implementations that support TLS 1.1 should not require CN-IDs for backward compatibility?

> http://tools.ietf.org/html/draft-melnikov-email-tls-certs-00

Thanks for the example. Here's what I've come up with for now...

    <t>RID systems MUST verify the identity of their peers against that stored
    in the certificate presented. All RID systems MUST be identified by a
    certificate containing a <xref target="RFC5280">DNS-ID identifier</xref>
    as in section 6.4 of <xref target="RFC6125"/>. Certificates identifying
    RID systems MAY additionally contain a CN-ID identifier, to allow backward
    compatibility with older PKI implementations. Wildcards MUST NOT appear in
    the DNS-ID or CN-ID of a certificate identifying a RID system. Additional
    general information on the use of PKI with RID systems is detailed in
    Section 9.3 of <xref target="I-D.ietf-mile-rfc6045-bis"/>.</t>

(The text about CN-IDs would be removed if the assumption that TLS 1.1 implies no need for CN-ID, as above)

Thanks,

Brian

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Jan 2012 15:32:55 +0000

Hi Brian,
> I can say that directly then.
That would be good, thanks.

> Here, I'm a little unclear on the implications this has for implementation: is it reasonable to assume that all implementations that support TLS 1.1 should not require CN-IDs for backward compatibi…

There is no direct correlation. But you should keep away from CN-IDs in 
new protocols, if you can. RFC 6125 goes into details why CN-ID don't 
necessarily work.
In reality though, you might have to support CN-IDs if you are using 
existing Certificate Authorities, as opposed to creating your own ones.

>      certificate containing a<xref target="RFC5280">DNS-ID identifier</xref>
>      as in section 6.4 of<xref target="RFC6125"/>. Certificates identifying
>      Section 9.3 of<xref target="I-D.ietf-mile-rfc6045-bis"/>.</t>
>
This looks Ok (with or without CN-ID). I am a bit undecided about CN-ID.

---

From: Brian Trammell <[email-masked]>
Date: Mon, 23 Jan 2012 17:12:08 +0100

Hi, Alexey,

I can take the CN-ID question to the MILE WG on this. In any case, is it clear enough from this language that CN-ID is a "compatibility-only" feature?

Cheers,

Brian

On Jan 23, 2012, at 4:32 PM, Alexey Melnikov wrote:

> There is no direct correlation. But you should keep away from CN-IDs in new protocols, if you can. RFC 6125 goes into details why CN-ID don't necessarily work.
> In reality though, you might have to support CN-IDs if you are using existing Certificate Authorities, as opposed to creating your own ones.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Jan 2012 16:17:12 +0000

Hi Brian,
> I can take the CN-ID question to the MILE WG on this.
Sounds like a good idea.
> In any case, is it clear enough from this language that CN-ID is a "compatibility-only" feature?
I think your text is clear enough.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 24 Jan 2012 10:25:18 +0100

Hi, Alexey,

So far only one voice on the WG list, stating no need for CN-ID. However, on thinking about it a bit further, if you happen to have an older PKI built out, and you're still using it, you've probably got a large investment in it, and it probably makes sense to allow you to use it for RID too...

So, I'd suggest the following language to grudgingly allow such a thing:

The use of CN-ID identifiers in certificates identifying RID systems
is NOT RECOMMENDED, and CN-ID identifiers MUST be ignored by PKI
implementations which can use DNS-ID identifiers. However, CN-ID 
identifiers MAY be used when the RID consortium to which the system 
belongs uses an older, existing PKI implementation. 

Thoughts?

Thanks for all your help, and cheers,

Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Jan 2012 09:45:30 -0700

> belongs uses an older, existing PKI implementation. 

Brian, first of all, thanks for working with us on this topic. As you
can see from the length of RFC 6125 (which didn't start out that big!),
there's more complexity here than meets the eye.

I think the mix of "NOT RECOMMENDED, MUST be ignored by some, but MAY be
used by others" might be a bit confusing to those who implement and
deploy RID. Also, RFC 6125 makes a distinction between cert generation
and cert checking, which gets obscured by the word "use". Thus I might
make the following suggestion:

   The inclusion of Common Names (CN-IDs) in certificates identifying
   RID systems is NOT RECOMMENDED.  A PKI implementation that
   understands DNS-IDs SHOULD ignore CN-IDs when checking server
   certificates. However, because many existing PKI implementations
   still include CN-IDs when generating certificates, RID consortiums
   might want to continue supporting them during certificate checking.

This removes the normative force from the text about existing PKI
implementations, while still encouraging use of DNS-IDs.

Let us know what you think.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 24 Jan 2012 16:59:37 +0000

On 24/01/2012 16:45, Peter Saint-Andre wrote:
>     certificates.
I thought RFC 6125 has a rule saying that CN-IDs are ignored in presence 
of DNS-IDs? I would just rather reference RFC 6125, or at least be clear 
that this is defined there (using "as specified in RFC 6125").

The rest of your proposal looks fine.
> However, because many existing PKI implementations

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 24 Jan 2012 10:10:22 -0700

On 1/24/12 9:59 AM, Alexey Melnikov wrote:
>>> So far only one voice on the WG list, stating no need for CN-ID.
>>> However, on thinking about it a bit further, if you happen to have an
>>> older PKI built out, and you're still using it, you've probably got a
>>> large investment in it, and it probably makes sense to allow you to
>>> use it for RID too...
>>>

Yes, so you're right: just reference the rules from RFC 6125.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: <[email-masked]>
Date: Tue, 24 Jan 2012 12:59:55 -0500

I agree, the guidance in RFC6125 Section 2.4 is pretty clear and should just be referenced if we go this route.  I do have a question out to a practitioner to see if we need to allow anything other than DNS-IDs.  She did say support is good in CAs, maybe it is OK to require DNS-IDs.  She will be posting to MILE later today.  Are there any CAs that do not support this yet?  RFC6125 says this is to support older CAs, but has this changed?  RFC6125 was only published in March, so it may still be important.  

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Tuesday, January 24, 2012 12:00 PM
To: Peter Saint-Andre
Cc: [email-masked]; Moriarty, Kathleen; The IESG; Brian Trammell
Subject: Re: [Gen-art] Gen-ART last call review of draft-ietf-mile-rfc6046-bis-05

> Let us know what you think.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Brian Trammell <[email-masked]>
Date: Tue, 24 Jan 2012 20:17:23 +0100

Hi, Peter, Alexey, all,

Thanks for the suggestion on fixing the ambiguity in "use" -- that was bothering me a bit, too...

Okay, so how about straight NOT RECOMMENDED, which would make the whole paragraph:

    <t>RID systems MUST verify the identity of their peers against that stored
    in the certificate presented. All RID systems MUST be identified by a
    certificate containing a <xref target="RFC5280">DNS-ID identifier</xref>
    as in section 6.4 of <xref target="RFC6125"/>. The inclusion of Common
    Names (CN-IDs) in certificates identifying RID systems is NOT RECOMMENDED.
    Wildcards MUST NOT appear in the DNS-ID or CN-ID of a certificate
    identifying a RID system. Additional general information on the use of PKI
    with RID systems is detailed in Section 9.3 of <xref
    target="I-D.ietf-mile-rfc6045-bis"/>.</t>

And we let people who really, really need to support CN-ID read between the lines. Thoughts?

Cheers,

Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 25 Jan 2012 16:17:58 -0700

For greater clarity, I'd change "as in section 6.4" to "as defined in
section 6.4" -- "as in" sounds like section 6.4 is one possible way
you'd define the term. :)

Thanks!

Peter

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 26 Jan 2012 19:03:03 +0000

Hi Brian,
>      as in section 6.4 of<xref target="RFC6125"/>. The inclusion of Common
Your text basically says that DNS-ID are mandatory to include and use. 
RFC 6125 requires for DNS-ID to take precedence over CN-ID, if both are 
present. I don't think this leave any space for older PKI systems that 
only include CN-IDs. If you want to allow for them, I think you need to 
make the requirement on having DNS-ID a SHOULD (for example. Other ways 
might be possible.)

But otherwise I am Ok with your text.