[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Summary of issues from RTP
>----------
>From: Michael C. Richardson[SMTP:mcr@sandelman.ottawa.on.ca]
>Sent: Tuesday, March 17, 1998 11:01 PM
>To: ipsec@tis.com
>Subject: Summary of issues from RTP
>
>
> 3. IP address in CERTs. Some people expected strings, other expected
> 4 octets in ipAddress. If string, then is it: CN vs Unstructured or
> subjectAltName.
It is never a string when encoded in subjectAltName, if it is then their
CA has incorrectly encoded the value. See X.509 (which points to
RFC-791), or PKIX part 1. I don't think clarification is needed (see
below).
I believe consensus was that if IP Addresses (or dns name or rfc822)
were going to be added to an X.509 certificate then they should go into
the subjectAltName extension (that is after all what it is for). This
is consistent with work done in the PKIX WG.
>
> 6. Some vendors used old isakmp-08 certificate request format, but the data
> attrbute used in the payload was incorrectly formatted (or missing).
> {ed note: isakmp-09 was not publically available for the interop}
Then was it really the old format? :)
>Bye.
>----
>Greg Carter, Entrust Technologies
>greg.carter@entrust.com
>From
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-06.txt
"When the subjectAltName extension contains a iPAddress, the address
shall be stored in the octet string in "network byte order," as
specified in RFC791. The least significant bit (LSB) of each octet is
the LSB of the corresponding byte in the network address. For IP
Version 4, as specified in RFC 791, the octet string must contain
exactly four octets. For IP Version 6, as specified in RFC 1883, the
octet string must contain exactly sixteen octets."
>
>