自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

X.509証明書の識別名などで使われるMulti-valued RDNとjsrsasignのサポートについて

久々にちょっとPKI関連ネタです。いわゆるデジタル証明書(X.509証明書)には、主体者名(Subject Name)や発行者名(Issuer Name)に識別名(DN: Distinguished Name)を使います。例えば、

CN=yourname@example.com,O=example,C=JP
のようなものです。カンマで区切った一つ一つを相対識別名(RDN: Relative Distinguished Name)と呼んでいます。
O=example
一般的には相対識別名(RDN)は、「一つの」属性タイプと属性値のペア(AttributeTypeAndValue) より構成されます。
属性タイプ=属性値
O=example
ただ、「一般的には」と書いた通り、RDNについて複数のAttributeTypeAndValueを持つことも可能です。これをMulti-valued RDNと呼んでおり、プラス"+"記号でつないで以下のように表現します。
属性タイプ1=属性値1+属性タイプ2=属性値2...
CN=User1+serialNumber=123
Googleとかで「Multi-valued RDN」で検索するとわかると思うんですが、英語では結構あるのに、日本語で触れている記事って、自分のブログ以外みつからないみたいなんですよね。 今日は、拙作の暗号ライブラリ jsrsasign や OpenSSL を使いながら、証明書識別名のMulti-valued RDNや、識別名について掘り下げてみたいます。

エントリと識別名

LDAPや、その元となっているX.500ディレクトリサービスでは「エントリ」のツリー構造により情報を管理し、例えば会社、部門、社員は以下のように管理することができます。
図1
LDAPでは、あるエントリを特定するために「○×商事」の「総務部」の「佐藤二朗」さんという特定の仕方をします。エントリの名前、「総務部」や「佐藤二朗」という値は、属性タイプという型をつけることができ、組織名(O: Organization Name)、部署名(OU: Organizational Unit Name)、一般名(CN: Common Name)などのタイプがあります。
図2
例えば、営業の鈴木さんを特定するときに一番上までのエントリを辿って、以下のように表現します。これを「識別名(DN: Distinguished Name)」と呼びます。これにより他の部署のSuzukiさんとも区別できます。

CN=Suzuki,OU=Sales,O=MaruBatsu
識別名のうち、「OU=Sales」のようにエントリの丸の中を相対識別名(RDN: Relative Distinguished Name)と呼びます。

また、このエントリのツリー構造をDIT(Directory Information Tree)と呼びます。

Muti-valued RDNとは?なぜ必要か?

上記で説明した識別名(DN)で、同じ営業部に鈴木花子さんが二人いたらどうしましょう。一般名に区別するための数字を追加したり、追加の値として、社員番号やメールアドレスで区別することもでき、エントリを追加しても良いのですが、どれもイマイチ。
図3
そこで、一つのエントリに複数の値をつけて識別することもできます。これを Multi-valued RDNと呼んでいます。
図4
同性同名の人は多分いるでしょうから、社員番号やメールアドレスなど他の一意なものと組み合わせて管理するのはスマートな管理方法だと思いますし、一部の商用のディレクトリサーバー製品では、利用者数ベースでライセンス課金するために、エントリ数を使うものもありますので、Multi-valued RDNを使うことによってコスト削減を狙うこともできます。ただ、Multi-valued RDNは、すべての製品で使えるというものでもないので(例えば、とある製品のスマートカードとか802.1X認証とかで後になって問題になったことがありましたよね、、、)本当に使ってしまってよいかどうかは、アプリケーションと相談して決める必要があるでしょう。

識別名の文字列表現

識別名の文字列表現にはざっくり2つの表現があります。

CN=Matsuda Kenji,OU=Sales,O=MaruBatsu
/O=MaruBatsu/OU=Sales/CN=Matsuda Kenji
DITのツリー構造の下から順にカンマ","でつないだ方法と、上から順にスラッシュ"/"でつなぐ方法です。

カンマで逆順につなぐ方法はRFC 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Namesや後継の4514で規定されています。LDAPのアプリケーションソフトウェアでは一般的に使われている方法です。

もう一方の、先頭にスラッシュを付け、スラッシュで正順でつなぐ方法はOpenSSL onelineフォーマットと呼ばれ、OpenSSLで標準的に使われるとともに、OpenSSL系のウェブサーバーであるApache HTTP Server、nginx、lighttpdなどの設定などで使われる方法です。

Multi-valued RDNの場合には、どちらの形式でも値をプラス"+"記号でつないで表現します。

CN=Matsuda Kenji+emailAddress=matsu@mb.com,OU=Sales,O=MaruBatsu
/O=MaruBatsu/OU=Sales/CN=Matsuda Kenji+emailAddress=matsu@mb.com
プラスで繋がれた値の表示順序については、特に決まりは無いと認識しており、以下のMulti-valued RDNでCNとemailAddressのどちらを先にしても良いはずです。これがどのようにASN.1でエンコードされるかは後で述べます。
CN=Matsuda Kenji+emailAddress=matsu@mb.com
emailAddress=matsu@mb.com+CN=Matsuda Kenji

次にCNやOUなどの属性タイプの文字列表現ですが、どのように表記しなければならいといった厳格な標準はなく、実装もバラバラであることがわかっています。8年前にXAdES長期署名に関連して、識別名の中の属性タイプの表記の実装状況について調査しており、その時にまとめた表を再掲します。
RFC2253テスト1属性タイプ名のテスト
X.509証明書プロファイルを定めたRFC 5280の4.1.2.4節 発行者名(Issuer)では、識別名の属性タイプとして対応しなければならない(MUST)リストと、対応すべき(SHOULD)属性タイプのリストが掲載されており、表中ではMUSTを黄緑、SHOULDを黄色、その他、証明書で実際に使われることのある属性タイプのリストを白とし、.NETや各種Javaベースの暗号ライブラリでどのように属性タイプが表記されるかをテストしました。表を見ればわかるとおり、結果はかなりバラバラです。また、S/MIMEのために使用される事があり、実際の証明書でもかなり含まれているemailAddressの属性タイプも、標準では実装を求めていないために対応にばらつきが出ているように思います。

今、見直してみると当時はなかったEV証明書用の以下の属性タイプも、今ならテストすべきだったかなぁと思います。

  • jurisdictionOfIncorporationL - 法人登録管轄地(市町村)
  • jurisdictionOfIncorporationSP - 法人登録管轄地(都道府県)
  • jurisdictionOfIncorporationC - 法人登録管轄地(国)

また、 カンマつなぎの識別名表記であるRFC 2253とその後継のRFC 4584の違いについて8年前の記事 でまとめており、仕様の改定によって、より識別名表記が一意になる方向に修正されていますが、 仕様の中で「RFC 4514は識別名文字列は一意にならない(=正規化しない)」という 事が明記されており、識別名文字列は、様々な表現が許されており、 単純な文字列比較では同じであるかどうかを判断できない事に注意しなければなりません。

識別名のASN.1定義と構造

次に、識別名が、ASN.1 DERエンコーディングにより、どのようにバイト列にエンコードされるのかを、 説明したいと思います。まず最初に、識別名のASN.1定義を紹介しましょう。 RFC 5280 4.1.2.4 Issuerより

// X.500名、識別名(DN)はRDNの並び(SEQUENCE) Name ::= CHOICE { rdnSequence RDNSequence } RDNSequence ::= SEQUENCE OF RelativeDistinguishedName // RDNは、AttributeTypeAndValue 1つ以上のSET // つまり、複数AttributeTypeAndValueがあってもよい。 // これが複数あれば Multi-valued RDN RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue // 属性タイプと属性値のペア AttributeTypeAndValue ::= SEQUENCE { type AttributeType, value AttributeValue } AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY // 属性値はANYと定義していながらも、DirectoryStringで // 定義されたいずれかの文字タイプを使用する DirectoryString ::= CHOICE { teletexString TeletexString (SIZE (1..MAX)), printableString PrintableString (SIZE (1..MAX)), universalString UniversalString (SIZE (1..MAX)), utf8String UTF8String (SIZE (1..MAX)), bmpString BMPString (SIZE (1..MAX)) }
つまり、
  • 識別名(DN)は、相対識別名(RDN)の並び(SEQUENCE OF)であり
  • 相対識別名(RDN)は、属性タイプと値(AttributeTypeAndValue)の集合(SET OF)であり
  • 属性タイプと値(AttributeTypeAndValue)は、属性タイプと値の並び(SEQUENCE)である
という事です。SEQUENCEとSETは構造型と呼ばれるASN.1プリミティブですが、
  • SEQUENCEは配列のようなもので、順序関係のある並びを表す際に使います。
  • SETは集合のようなもので、構成要素の中には特に順序関係はない場合に使います。
ついでに、SEQUENCEやSETと、SEQUENCE OF 〜、SET OF 〜の違いですが、
  • 単にSEQUENCEやSETとなっている場合には、構成要素のASN.1クラスが異なる場合に 使います。上の例ではAttributeTypeAndValueがそれに当たります。
  • SEQUENCE OF、SET OFとした場合、構成要素のASN.1クラスが同じ型の場合に 使います。上の例では、NameやRDNがそれに当たります。

それでは、例として以下の識別名をASN.1 DERエンコーディングしてみましょう。

CN=aaa,O=TEST,C=JP
RFC 2253の場合には、逆順でRDNが並ぶので、以下のようにエンコードされます。
302A SEQUENCE(30) OF -- DN 310B SET(31) OF -- RDN[1] 3009 SEQUENCE(30) -- AttributeTypeAndValue 0603550406 ObjectIdentifier(06) countryName 13024A50 PrintableString(13) "JP" 310D SET(31) OF -- RDN[2] 300B SEQUENCE(30) -- AttributeTypeAndValue 060355040A ObjectIdentifier(06) organizationName 0C0454455354 UTF8String(0C) "TEST" 310C SET(31) OF -- RDN[3] 300A SEQUENCE(30) -- AttributeTypeAndValue 0603550403 ObjectIdentifier(06) commonName 0C03616161 UTF8String(0C) "aaa"
ASN.1データはデータ型を表すタグ、バイト長、値データより構成され、上の例の最後の行では、0CがUTF8String型、03がバイト長(=3)、616161(=aaa)が値を表しています。

さて、次にMulti-valued RDNの場合にはどのようにエンコードされるのか、下の例を元に見てみましょう。ここでは、CN=aaaとCN=aの2つのAttributeTypeAndValueが使用されています。

CN=aaa+CN=a,O=TEST,C=JP
これをASN.1 DERエンコーディングすると以下のようになります。最後のRDNに注目してください。CN=aとCN=aaaと二つのAttributeTypeAndValuesがあることが確認できます。また、また、CN=aとCN=aaaでは、必ずCN=aが先に来ることにも注目です。
3034 DN 310B RDN[1] C=JP 3009 0603550406 13024A50 310D RDN[2] O=TEST 300B 060355040A 0C0454455354 3116 RDN[3] CN=aaa+CN=a SEQUENCE(30)が2つある 3008 ATV[1] CN=a CN=aの方が先に来ている 0603550403 0C0161 300A ATV[2] CN=aaa 0603550403 0C03616161
このRDN中のCN=a、CN=aaaの順序関係にはASN.1 DERとBERのちょっとした違いが関係があります。DERはBERのサブセットでなんですが、BERでは複数の表現が許されるのに対し、DERでは必ず一意な表現になります。その違いを表にまとめました。
ASN.1 DERASN.1 BER
概要ASN.1の一意なエンコード規則ASN.1のエンコード規則。DERのスーパーセットでDERであればBER
共通の特徴通信の世界では長い歴史のある、CPUや整数型のサイズに制限されない、巨大なデータも扱える、任意の構造化データを扱えるデータ表現。XML, JSONに比べコンパクト。
用途証明書、CRL、OCSP、RFC3161タイムスタンプS/MIMEデータ、CMS署名・暗号化データ、PKCS#12
比較必ず表現は一意。超巨大なデータでも長さが予めわかっていないといけないので、ストリーム処理など不向き複数の表現がある。超大きなデータでも取り扱い可能
SET要素のバイト列で昇順ソートするソートしなくて良い
BOOLEANTRUEのみ使え、FALSEは省略するようクラス定義TRUE、FALSEが使える
不定長表現長さ表現は一意で、予めデータサイズがわかっていないといけない。長さ表現で不定長表現が使え、長さを8000とした場合それは開始記号で0000が続くまで一つの要素であり、大きなデータも扱いやすい。
以上のような違いがあり、SETの違いによりMulti-valued RDNのSET OFの順序が決まっているわけです。

SETの要素は、各要素をASN.1エンコードしたときの昇順の辞書順でソートされ、ざっくり言えば、

  • 要素の短い物程先
  • 同じ長さなら属性タイプの長さが短い方が先
ということになります。例でみてみましょう。
3008 0603550403 0C0161 CN=a 300A 0603550403 0C03616161 CN=aaa ^^ 全体の長さLが08, 0Aの順になるので同じ属性タイプ長なら属性値の短い方が先 C,O,OU,CNなど主要な属性タイプはOIDの値が2.5.4.xになるので同一属性タイプ長
全体の長さが同じ時、
^^ 全体の長さは同じなら 3011 0603550403 0C0A6162636465666768696A CN=abcdefghij 3011 060B2B0601040182373C020103 0C024A50 jurisdictionOfIncorporateC=JP ^^ 属性タイプの値の短い方が先

OpenSSLのMulti-valued RDN対応

OpenSSLはMULTI-valued RDNに対応しており、"-multivalue-rdn"をつけるだけです。 例えば、既存の秘密鍵でワンライナーでMulti-valued RDNの自己署名証明書を作りたい時

openssl genrsa 2048 > a.prv
openssl req -new -key a.prv -x509 -subj /C=JP/O=Test/OU=b+CN=a -out c.cer -multivalue-rdn
Multi-valued RDNの証明書発行要求を作りたいとき
openssl req -new -key a.prv -subj /C=JP/O=Test/OU=b+CN=a -out c.csr -multivalue-rdn
となります。

jsrsasignのMulti-valued RDN対応

jsrsasignは、私が趣味で作ったPure JavaScriptによる暗号ライブラリでして、2010年ぐらいからボチボチ暇を見つけては昨日を追加しており、最初はRSA署名だけだったものが、ASN.1や証明書やタイムスタンプやJOSEなんか、自分が「欲しいな」と思った時に増築を繰り返しており、PKIやASN.1やJOSE(JWS,JWT,JWK)関係でちょっと試したいなと思った時に重宝しています。

ウェブブラウザ上でも、Nodeでも使え、APIドキュメントやサンプルも充実させているので、結構ユーザは世界中にいたり、最近はSONYや横河(や勝手にうちの会社(^^;)のハードウェア商品でも使われていることが発覚したり、Nodeのnpmパッケージは月間10万弱のダウンロードがあるようで、ホントありがたい話です。

JavaScriptの暗号ライブラリのAPIとしては、W3C Web Crypto APIなどあるんですが、モバイルブラウザでサポートしていないケースがあったり、古い暗号が使えなかったり、ちょっと書こうと思っても何行も書かなければいけなかったり、面倒くさいんですよね。そこで、jsrsasignでは、「なるべく少ない行数でやりたい事ができる」っていうのを目標にしていて、例えば鍵なんかは秘密鍵でも公開鍵でもPKCS#5でもPKCS#8でもJSON Web KeyでもなんでもKEYUTIL.getKeyに渡してしまえば適当に処理します。また、PCでもスマホでもNodeでも、多少古い環境でもJavaScriptさえ動けば使えるようになっています。また、APIドキュメントやチュートリアルの資料もできる限り潤沢に用意したつもりです。

割と最新の話まで入っている英語の入門スライドがあったり、
slidee
またちょっと古いですが、2013年にJNSAのWGでお話したjsrsasignとjsjwsが別の開発ラインだった時の入門スライド があるのでよかったら参考にしてください。
slidej

ドキュメント類は拙い英語のものしかなくて申し訳ないですが、問題とかあれば、Issueには日本語で入れて頂いて構わないので入れて頂ければと思います。

で、jsrsasignをMulti-valued RDN対応させたり、カンマ繋ぎDN対応したいなと思っていて、ようやく6.2.2をリリースした最近になってから対応させました。 例えば、Multi-valued RDNの識別名がどのようにASN.1 DERエンコードされるのかなんて話は、次のように確認できます。

% node > var X509Name = require("jsrsasign").KJUR.asn1.x509.X500Name; > new X509Name({str: "/C=JP/O=T1+CN=kjur"}).getEncodedHex(); '3027310b3009060355040613024a5031183009060355040a0c025431300b06035504030c046b6a7572'
あとは、証明書発行要求(CSR)を作ったり、
var rs = require("jsrsasign"); var kp = rs.KEYUTIL.generateKeypair("RSA", 2048); pem = rs.KJUR.asn1.csr.CSRUtil.newCSRPEM({ subject: {ldapstr: 'OU=T1+CN=example.com,O=Test,C=US'}, ext: [ {subjectAltName: {array: [{dns: 'example.net'}]} ], sbjpubkey: pubKeyPEM, sigalg: "SHA256withRSA", sbjprvkey: prvKeyPEM });
証明書を発行したりする時にもMulti-valued RDNが使えます。
var pem = KJUR.asn1.x509.X509Util.newCertPEM({ serial: {int: 4}, sigalg: {name: 'SHA1withRSA', paramempty: true}, issuer: {str: '/C=US/O=a'}, notbefore: {str: '130504235959Z'}, notafter: {str: '140504235959Z'}, subject: {ldapstr: 'OU=kjur+CN=kjur,O=b,C=US'}, sbjpubkey: kp.pubKeyObj, ext: [ {basicConstraints: {cA: true, critical: true}}, {keyUsage: {bin: '11'}}, ], cakey: kp.pubKeyObj });
割と融通が利くので、よかったら使ってやってください。

おわりに

というわけで長々、Multi-valued RDNや識別名(DN)のことでダラダラ書いてしまいました。ごめんなさい。誰かの参考になれば良いかな、と思います。

追記(2016.12.19)

あっ、誤解されないように書いておきますと、私としては、Multi-valued RDNを広めたいとか、使うべきだとか言うつもりは毛頭ありません。相互運用性が高い方向でインフラ設計するのが原則であり、使わなくて済むなら使わない方がいいでしょう。ただ、受け取ったとしても、びっくりしないでね、と、、、、w

関連記事

バルセロナでプリペイドSIMの購入(2016年11月版)

バルセロナでプリペイドSIMを購入された、先人の方のありがたい情報を参考に、私も使ってみましたので、記録として残しておきます。よかったら参考にしてください。

土曜夜着だったので空港で購入

今回は家族でバルセロナに旅行に行きましたが、旅行中の連絡用にプリペイドSIMを2枚買おうと思っていました。土曜の午前発で夜の19:30頃空港着でしたので、街に出て探してSIMを買うというのも疲れそうで、バルセロナでは翌日の日曜は、ショッピングモール以外ほとんどの店が閉まっているらしく、空港でvodafoneのSIMを買ってしまうことにしました。


vodafone-es
(vodafone esサイトより)

いろんな記事でも紹介しているように、ルフトハンザでバルセロナ・エルプラット国際空港のターミナル1に到着し、税関を抜けるとすぐ左手にCRYSTALの看板が見えますのでそこで売っています。(ピンクの店全景, エリアマップ) 混んでいることがあるように書いていましたが、私が行った土曜の20:30頃には誰もいませんでした。紹介されていた、店に並んでるSIMを指差して「これください」ってな感じでvodafoneのプリペイドSIMを2枚を購入しました。
image

  • 60分の通話料
  • 1GBのデータ通信
  • SMSも通話料の範囲で無制限で利用可能(だけどなぜか使えなかった(後述))
  • こみこみで15ユーロ
ぶっきらぼうにSIMを渡して終わりにしようとされましたが、あらかじめiPhone SEとAndroidスマホを英語表示にしておいたので、「設定してください」とお願いし、動作確認もなくただSIMを挿すまではしてくれました。iPhone SE用のnano SIMだと追加料金を5ユーロ取られるような情報もありましたが、特に追加はありませんでした。 店の前で、自分で起動と通話の確認だけはして、2台の間で通話ができることは確認しました。

他のプリペイドSIMも幾つかあるようですが、空港ですぐ使えるという気軽さと、初期費用も少ないという事から、1週間以内の滞在ならvodafoneでいいのでは?と思います。

  • vodafone (60分通話、1GBデータ利用料込で15ユーロ) 料金は若干高めだそう
  • Movistar (10ユーロ分の利用料込で15ユーロ)
  • Orange (通話0.18ユーロ/分、1GBデータ利用料込で10ユーロ)
  • Orange Tu Mundo (14ユーロ分の利用料込で28ユーロ)

とりあえずパッケージとSIMとメモっておく事


q1small
パッケージの表面はこんなの。
q2
縦横比がおかしいですが、裏面の「N. Tel.」の所にSIMの電話番号が書いてあります。スペインでは61で始まる9桁の番号(61xxxxxxx)です。下で拡大しましょう。
q3
SIMカードのサイズは、通常SIM、Micro SIM、Nano SIMのサイズに切り取って使えます。古い情報サイトにはnano SIMだと追加料金を取るようなことを書いているところもありましたが、特に追加料金は必要ありませんでした。ここで、「PIN」の4桁の数字はSIMロックの解除PINコードで、ケータイ再起動のたびに入力が必要ですので書き取っておきます。また、「PUK」はSIMロック解除コードを4回以上間違えた場合の解除コードですので、これも書き取っておきます。
q5
メモを取っておくべき数字をまとめておくと

  • Tel. - 電話番号(61xxxxxxx 9桁)
  • PIN - SIMロック解除PIN(xxxx 4桁)
  • PUK(Personal Unblocking Key) - PINロック解除コード(xxxxxxxx 8桁) 通常は不要
購入したvodafoneのSIMは多分、帰りに経由するドイツでも(日本でも?)使えるように思いますが、SIMロック解除PINを記録するのを忘れてしまったために、ドイツで試すことができなかったです。写メにも取っておくとさらに良いように思います。中には別のカードも入っています。Google大先生に聞いて調べてみて、ざっくり意訳するとこんな感じ:
q4

Esta tarjeta va protegida con dos codigos que encontraras impresos en tu tarjeta: Codigo PIN, que debes marcar una vez introducida en tu dispositivo y cada vez que lo enciendas. Y un codigo de desbloqueo PUK, que deberas marcar, unicamente, en caso de bloqueo del codigo PIN. En caso de perdida, puedes consultarlos en vodafone.es/pin o llamando gratis al 1150 desde cualquier operador nacional. Para tu seguridad, te recomendamos cambiar el codigo PIN por uno nuevo que te sea mas facil de recordar.

このSIMカードはここに印刷されている2つのコードで保護されています。 PINコード、これは、一度使用したデバイスで電源を入れる度にコード入力する必要があります。 PUKロック解除コードはPINコード(の入力誤りで)ロックされた場合に入力する必要があります。 失敗した場合には、フリーダイアルで1150により いずれかの国のオペレータに問い合わせるか、 vodafone.es/pinで確認することができます。 セキュリティ向上のため、覚えやすい新しいPINに変更することをお勧めします。

iPhone SEのデータ通信で早速ハマる

今回の旅行では、SIMフリーで接続する用に次の2台を持ってきました。(iPhone SEの選定については別の機会に)

  • iPhone SE (SIMフリー)
  • Polaroid Pigu 3G (SIMフリー)
Polaroid Piguについては難なくデータ通信でき、Google Mapも使えたのですが、iPhone SEの方がどうもデータ通信ができません。また、SMSも両方送ることができません。ホテルまでの移動のタクシーでいろいろ設定を見てみましたが、途中であきらめホテルでWifi繋いでゆっくり調べることにしました。

iPhone SEのデータ通信

落ち着いてAPN設定など見てみると日本で設定確認のためにインストールしたiijmio用の「IIJmio モバイルサービス APN設定プロファイル」が悪さをしていたようで、iijmioのAPN設定が使われているようでした。手動でvodafone ESのものに変更し無事データ通信もできるようになりました。APN設定はiPhoneSEとPiguとで、ネットで探した別の設定をしていたようですが、どちらも問題なく繋げていたようです。[参考1][参考2]

iPhoneSEPigu
オペレータvodafone ESvodafone ES
APNap.vodafone.esairtelwap.es
Uservodafonewap@wap
Passvodafonewap125

どちらもSMSはできず

データ通信には成功し、とりあえずの旅行での連絡や調べ物やメールは無事できるようになったんですが、結局、iPhone SEでもPiguでもSMSができるようにはなりませんでした。SMSは通話に含まれるとかいてあったので問題無いはずなのですが、結局できるようにならなかったのは謎のままです。ご存知の方は、教えていただけるとうれしいです。送信失敗したエラーメッセージとして次のSMSが送られてきました。

El Mensaje Multimedia no se ha enviado a todos los destinatarios porque no dispone de suficiente saldo en su tarjeta. Recargue e intentelo de nuevo mas tarde

彼らはあなたのカードに充分な残高を持っていないため、マルチメディアメッセージがすべての受信者に送信されませんでした。リロードした後に再度お試しください。

現在の使用量も確認できず

現在の使用量はMi Vodafoneで確認するそうなのですが、結局アカウントがうまく作れず、使用量の確認までは辿りつけませんでした。また、iOS版のMi Vodafoneアプリは、日本に設定されたiTunesアカウントからはダウンロードできません。Android版は試し損ないました。

ドイツ(ミュンヘン)での利用も確認できず

このプリペイドSIMはドイツでもローミングで使えるはずなのですが、ミュンヘンで乗り換えの際使おうと思ったら、SIMロックのPINコードを書いた紙がスーツケースに入ってしまっており、また、コードの写メも取っておらず、SIMを使うことができませんでした。とほほ。

日本からのプリペイドSIMの利用

このSIMカードは普通にローミングでつなぐことができそうな雰囲気でアンテナも立ちます。日本でつなぐと以下のようなSMSが送られてきました。

VF info: Bienvenido a Japon. Llama a Espana y recibe llamadas por 3,03E/min + 1,69E de establecimiento. Envia SMS a 1,21E. MMS a 3,03E y recibelos por 2,42E. Precios con IVA.+info: vodafone.es

ボーダフォンより:日本へようこそ。スペインには、通話3.03ユーロ/分+接続1.69ユーロが必要です。1.21ユーロでSMSが送信できます。MMS送信は3.03ユーロ、受信は2.42ユーロかかります。費用には付加価値税が含まれます。: vodafone.es

その他のSMSメッセージ

その他、ちょいちょいSMSメッセージが(送ることはできないのに)送られてきており、旅行中は忙しいし、パソコンも持っていかなかったので、いちいち調べる気もしなかったんですが、日本に戻って落ち着いたので、参考まで意訳してみました。

VFInfo:!Bienvenido a Vodafone!Gracias por confiar en nosotros,estamos a tu disposicion en www.vodafone.es,marcando gratis *123# tecla llamada y tienda Vodafone.

ボーダフォンへようこそ!ご利用ありがとうございます、無料のダイヤル* 123#や、ボーダフォンストア www.vodafone.es でご自由にお使いいただけます???

VF Info Tarifa: Ya tienes 1,5GB y 60min llamadas a Espana o Internacionales a paises dentro de beneficio hasta 10/12/2016. +info: m.vodafone.es o *565#

すでにスペインで2016年12月10日まで対象国の国際電話に60分とデータ通信1.5ギガバイトがご利用になれます。m.vodafone.esまたは* 565#にお問い合わせください。

VF Info: Personaliza el mensaje de bienvenida de tu contestador gratis en el 2211xx. Tu clave de acceso es 8xxx, si quieres cambiarla llama gratis al 2211xx

留守番電話のウェルカムメッセージを変更したい場合、無料通話で2211xxにおかけください。あなたのパスワードは8xxxです。

61712xxxx ha hecho 1 llamada el dia 12/11/2016 a las 22:55 h. Pulsa para devolver la llamada.

電話番号61712xxxxより、2016年11月12日 22:55にお電話がありました。おかけになる場合には<呼出>ボタンを押してください。

参考にした記事

以下の記事を参考にしてSIMを購入できました。ありがとうございました。

ヨーロッパでPokemon Goに最適?なSIMフリースマホ

いろいろな訳あって、バルセロナに家族旅行したのですが、家族内での連絡用にプリペイドSIMを使ってみたいなと思いました。ついでにPokemon GOでヨーロッパでしか捕まらないというバリヤードをゲットしたいな、、、と。

家にはSIMフリーとして、

  • Nexus 7 2003 (LTE)
  • Polaroid Pigu (3G)
があったんですが、NexusはPokemon GOがインストールすらできないし、持ち運ぶにはデカイので、何か安い Android スマホを買うかなと安易に思っていました。

欧州でLTE使いたければ対応バンドに注意

欧州のキャリアのLTEのバンドは3、7、20が多く、これら3つをサポートしている予備機のSIMフリースマホ(でPokemon GOができるもの(^^;)が欲しいわけで、国内では別途メインで使っているやつがあるのでなるべく値段は抑えたいわけです。

ところが、格安SIMフリースマホはこの記事をよく読むとPokemon GOには向いてなさそうで、黙ってiPhoneを使っとけみたいな話になっています。また、格安SIMフリースマホは欧州の3、7、20の3つに対応しているものは少なく、Androidでは7万以上の高級機でないとサポートしていないようです。

そう考えると、iPhone SEはお得度が高く、SIMフリーで、欧州LTEバンドにも対応して、Pokemon GOの使用も問題がなく、コンパクトで旅行用のスマホとしては最適という気がして結局コレを買ってしまいました。2016年9月にiPhone SEは1万円ぐらい値下げされ、16GBモデル44,800円、64GBモデル49,800円ととてもお得になっています。大した価格差じゃないので64GBが良さそうですね。日本で販売されるモデルはA1723ですが、LTE対応バンドが非常に多いので海外利用で安心感あります。

欧州LTEバンドの対応状況を関係しそうなものだけざっと調べてみました。

製品モデル概算価格対応バンド数B3B7B20
iPhone SE A1723(北米日本) 64GB49,80019
Nexus 7 2013 LTE北米日本版7××
Nexus 7 2013 LTE欧州版7×
Nexus 5X5万
Nexus 6P 64GB8万
Xperia XZ7.6万20
ZenFone 2 Laser ZE601KL13××
ZenFone 2 Laser ZE500KL9××
ZenFone Max 16GB2.6万9××
ZenFone Zoom 64GB5.5万16×
FREETEL Priori 3S 16GB1.6万5×
FREETEL SAMURAI REI 32GB2.1万6

というわけで、予定よりもちょっと高くつきましたが、無事バリヤードも3匹ゲットできてiPhone SEにして非常に満足しています(^^;
image

バルセロナのプリペイドSIM購入については、近々なんか書きます。

SSL Pulseの統計情報でみるSSL/TLSの引越しについて

2014年11月頃から、SSLに関する統計情報を公開しているサイトSSL Pulseのデータから推移情報をブログで公開してきました。隔月で更新するようなことを言ってて、2015年12月から更新が無い状態になっており、「コラ〜〜!サボってんじゃね〜〜」的なことを思われたかたもいらっしゃるかもしれません。すみません。すみません。すみません。

新しいサイト

SSL Pulse Trends(SSL Pulseデータの推移) https://kjur.github.io/www/sslpulsetrend/index_j.htmlというサイトを作りました。今後の毎月の更新はこちらでやっていきます。

サイトを移行した経緯など、、、

前は、エクセルなど駆使してグラフ描いてたんですが、そりゃもう、結構手間がかってたんですよ。自分も興味があって毎月すぐ知りたいんだけど、とても、毎月はできないなと、、、ざっくりとした流れはこんな感じ:

  • 今月のデータファイル(JSON)をwgetでダウンロードする
  • データの推移をTSV形式になるように変換するツールを実行する。グラフに必要なデータ列もこの時作る。
  • TSVファイルをUTF-16にする(Mac Excel対策)
  • Excelで読み込み
  • データを細かい整形(日付フォーマットや表ヘッダなど)
  • 必要なグラフを作る
  • グラフをEMF(拡張メタファイル)でエクスポートする
  • PowerPointに吹き出し等を貼り付け(位置調整)
  • PowerPointの画面を画像キャプチャし、ブログへ
まず、第一の鬼門なんですが、自分は自宅ではMac Book Airを使ってまして、Mac用のExcel(前の2011も今のやつも)は、文字化けしないようにCSVやTSVファイルを読み込むのが骨が折れるんですよ。一応ファイルの入力候補としては普通のUTF-8でも大丈夫そうに見えるんだけど、うまくいかず。結局うまくいったのはメモ帳アプリでUTF-16に変換してから読み込ませるという方法です。Googleとかで"Mac Excel TSV 文字化け"みたいなキーワードで検索すれば、方法が出てくるでしょう。
07

そして、一つ一つグラフを作っていくわけです。
01
で、Excelのグラフの凡例ではちょっと見づらいのでパワポで吹き出しをつけます。
39
どうです?結構面倒くさそうでしょう?

で、新しいサイトでは

とにかくExcelでグラフをつくるのはやめにしたく、JavaScriptベースでグラフを描けないもんかと、調べてみました。最初は、ccchartなんかがデザインも良いかなぁと考えていたんですが、思っていたデザインにするのは、至難の技であると知り、D3.jsという有名なライブラリも見たんですが、一つのフツーのグラフ書くのに多くのコードを書かねばならず断念。D3.jsを簡単に使うためのラッパーがあるそうで、それを幾つか見て、rickshawで何とか許せるグラフが描けたのでそれを使うことにしました。

本当は、SSL Pulseに置いてあるJSON形式のデータファイルをそのまま、表示の度に取り込んで加工してからグラフ表示しようとしたんですが、諸々CORSの壁に阻まれ断念。動的にダウンロードする必要もなくなり、スタティックな解析データをNodeで作って、SOURCEタグで普通にデータ取り込むことになりました。

ブログでたまたまSSL Pulseについて書くだけなら、特別な断りをいれなくてもいいかと思ったんですが、定常的に今後は英語でもページを公開するとなると、SSL Pulseの作者のIvan Ristićさんに仁義というか確認取っといたほうがいいかなと思いました。IvanさんはSSL/TLSの技術解説書の中では最高に良いと思うBulletproof SSL and TLSの著者であり、SSLの設定評価サイトであるssllabsの開発などもしています。

Bulletproof SSL and TLS
Ivan Ristic
Lightning Source Inc
2014-08

最初は、TwitterのDMで連絡取ろうとしたんですが、当然ながら私のフォローして頂いてるわけではないのでDMが送れず、メールアドレスもどこにも記載されていなので、連絡がつきませんでした。そこで、いつもJavaScriptの暗号/PKIライブラリでは情報交換などさせて頂き大変お世話になっているRyan Hurstさんに頼み込み、連絡とってくれないかと伝えました。Ryanさんは「Kenjiを紹介するよ。彼は、すげーJavaScriptの暗号/JWT/X.509ライブラリの作者だ。」と私からのお願い事項のメールを転送してくれました。2日ぐらい待ってて、「う〜〜ん」こりゃレス無しかなぁとも思ってたんですが、返事が来まして「SSL Labsは自由なコンテンツライセンスになってて、君の場合でも全く問題ないとわかると思うよ。同じようなこと(=データ推移情報)をやりたいと思ってたんだけど、時間がなくてね〜〜。」との事でした。よかった、よかった。これで安心して定常的に公開できそうです。

Rickshawの使い方は概ねこんな感じです。

<div id="chart_container"><div id="grade_chart"></div></div> <script> var graph = new Rickshaw.Graph({ element: グラフを描くキャンバスが挿入されるDIVのDOM, width: グラフ幅, height: グラフ高, renderer: グラフ形式(棒グラフとか折れ線グラフとか), series: [{"color": グラフデータ色, "name": データ名(TLS1.2とかSHA256withRSAとかデータ名), "data": [{x: 値, y: 値}, {x: 値, y: 値} ...]}, : (複数のデータがあれば続く) ] }); graph.render(); </script>
同じ形式のグラフ描くのに、同じようなコード書くのも面倒なので、さらにラッパーを作りました。
RickshawUtilGraph(グラフ描くDOM IDの共通ヘッド(グラフや凡例、XY軸など), グラフの共通テンプレート, データ(グラフデータ、データ名) [,オプションでグラフ形式を変えたい場合のパラメータ] [,オプションでグラフ色変えたい場合のパラメータ]);
これでようやく、SSL Pulseの更新があっても、make 一発でグラフデータを作れるので、毎月の更新も負担にならなくなりました。

というわけで、まだ素っ気ないページですが日本語ページ公開にこぎつけました。今までなかった評価グレード(A-F)の分布推移のグラフはNPNのHTTP/2サポートプロトコルの推移のグラフも付け加わっています。
42
しばらくしたら英語ページの作成にとりかかりたいと思います。

今後とも、よろしくお願いします。

関連記事

SSL Pulseの統計情報で見るSSL/TLS (2015年12月版)

いやぁ、年の瀬ですねぇ。最近、SSL/TLS関連の調査に全く時間が取れてないっす。 SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 10月に引き続き2015年12月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましょう。 今月は、なかなかデータ公開が早かったっぽいですが、気づくのに遅れました。

脆弱性対応の推移


201512-a1vuln

SSL/TLSプロトコルの推移


201512-a2proto

SSLサーバー証明書の鍵長、署名アルゴリズムの推移


201512-a3crt

新しい技術のサポートの推移


201512-a4adv
SPDYが下がっています。HTTP/2への移行が始まっています。実はSSL PulseでHTTP/2の対応状況も4ヶ月前あたりから取れるようになっているので、そろそろ可視化したいと思っています。

鍵交換の最低鍵長


201512-a5kx

DH(E)鍵交換の最低鍵長


201512-a6dh
DH鍵交換のサポート率は、ほぼ横ばいであるのに対して、

ECDH鍵交換の最低鍵長


201512-a7ecdh
ECDH(E)への対応は進んでいることがわかります。

おわりに

年末進行で、そんなに呑みに行っている気もしませんが、なんか仕事が山積みですorz コメント少なめですみません。今月はこの辺で。

関連記事

最新記事
Categories
Archives
記事Google検索

本ブログ内をGoogle検索
Twitter
Yahoo!アクセス解析
Travel Advisor
QRコード
QRコード

  • ライブドアブログ