On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote:
> Section 3.1.5 of RFC 4945 states that when generating an ID type of
> ID_DER_ASN1_DN that "implementations MUST populate the contents of
> ID with the Subject field from the end-entity certificate, and MUST
> do so such that a binary com
Hi David,
On Thu, Sep 17, 2009 at 8:03 AM, David Wierbowski wrote:
> Section 3.1.5 of RFC 4945 states that when generating an ID type of
> ID_DER_ASN1_DN that "implementations MUST populate the contents of ID with
> the Subject field from the end-entity certificate, and MUST do so such that
> a b
Section 3.1.5 of RFC 4945 states that when generating an ID type of
ID_DER_ASN1_DN that "implementations MUST populate the contents of ID with
the Subject field from the end-entity certificate, and MUST do so such that
a binary comparison of the two will succeed." Section 3.1.5 is specific to
IK
Marcus,
Thanks for the additional background. I am not an expert on 3GPP. Do
you know if there an IETF liaison to the 3GPP? If so, the right
approach is to have that individual coordinate an action like this
between the SDOs, i.e., when SDO-A wants SDO-B to modify/extend a
protocol to accommo
Section 3.6 of ikev2bis-04 says, "Certificate payloads SHOULD be included
in an exchange if certificates are available to the sender unless the peer
has indicated an ability to retrieve this information from elsewhere using
an HTTP_CERT_LOOKUP_SUPPORTED Notify payload."
Section 3.7 of ikev2bis
Hi Marcus,
reading your 3GPP document, I think you have something else in mind, not
exactly what NEA is planning on doing. NEA posture information may be very
large, containing data about many components of the OS and applications. I
believe what you are looking for is a much more limited set of
Thanks for the initial feedback. I certainly agree with the view that we
shouldn't duplicate the NEA protocols and I couldn't emphasize enough that
the intent of the ID is purely from transport's perspective. I am grateful
that you can view the ID with an open mind.
Perhaps a little background
This is the wrong mailing list for your request. You need to go to the vendor
of the software you are using. This mailing list is for talking about the
protocols themselves, not how to use a particular implementation.
--Paul Hoffman, Director
--VPN Consortium
Greetings again. This message starts the WG Last Call on
draft-ietf-ipsecme-aes-ctr-ikev2-02.txt. Please read the draft and comment on
the list whether or not you think it is ready for standardization. We are
particularly interested in hearing from implementers who have carefully read
the detai
Yaron Sheffer writes:
> - I would have liked to see ESP BEET mode referenced, since it's more widely
> implemented than other docs that we do mention. But as far as I know it is
> not on track to becoming an RFC.
I agree on that, and I think it might also be good to mention other
very widely imple
Yoav Nir writes:
> OK. One more try:
I think this is still bit confusing. How about splitting it to few
subsections, i.e.
2.21. Error Handling
2.21.1 Error Handling in IKE_SA_INIT
2.21.2 Error Handling in IKE_AUTH
2.21.3 Error Handling after IKE SA is Authenticated
2.21.4 Error Handling Outside I
11 matches
Mail list logo
